Important: This integration has been deprecated. Amazon Pay will continue to support this version but it will not be updated with new features. New integrations should use Amazon Pay Checkout.

Introduction to TLS/SSL

Amazon recommends that you always use a secure connection, but your server is required to have a valid TLS/SSL certificate, issued by a trusted Certificate Authority, in these two instances:

Login - During buyer login, there are two options, either a popup window or redirecting the buyer to another web page. Depending on the login type that you choose, one of the following secure connections must be used:
- Popup Login: TLS/SSL is required on the website where the button is embedded.
- Redirect Login: the return URL must redirect the buyer to a secure page.
Note: When testing in a local environment, a TLS/SSL certificate is not required (http://localhost).
IPN messages - IPN (Instant Payment Notification) messages can only be sent to a secure endpoint. Without a valid certificate Amazon can't tell whether the server receiving the IPN messages actually belongs to the merchant or to somebody who is attempting to intercept the data.

What is TLS/SSL?

Transport Security Layer ("TLS") and Secure Sockets Layer ("SSL") are protocols designed to ensure that data can be securely transported between a web server and a browser, using cryptographic algorithms. TLS/SSL ensures that the data transmitted comes from the source it claims to be coming from and that it hasn't been modified or read by a third party during the transmission. For more information about the versions of TLS/SSL that Amazon Pay supports, see TLS/SSL frequently asked questions.

HTTP versus HTTPS

When a URL address begins with the HTTPS protocol, the 'S' stands for secure and indicates that data is being transmitted securely. The difference between HTTP and HTTPS is that in HTTPS the data is transferred on top of TLS/SSL protocols and therefore inherits all of its security.

TLS/SSL certificates

TLS/SSL uses certificates to secure and protect transmitted data. A certificate contains information about the owner of the certificate, like the organization, country, duration of validity, website address, and the certificate ID of the person who certifies (or signs) this information. It also contains the public key and a hash to ensure that the certificate hasn't been tampered with.

Here is a sample certificate:

 
Company Root CA 9
==================
-----BEGIN CERTIFICATE-----
MIIDQTCCAimgITBmyfz5m/jAo54vB4iXxxababbmljZbyjANBgkqhkiG9w0BAQsF
ADA5MQswCQYDVQQGEwJVUzEPMA0GA1UEChMGQW1hem9uMRkwFwYDVQQDExBBbWF6
b24gUm9vdCBDQSAxMB4XDTE1MDUyNjAwMDAwMFoXDTM4MDExNzAwMDAwMFowOTEL
N+gDS63pYaACbvXy8MWy7Vu33PqUXHeeE6V/Uq2V8viTO96LXFvKWlJbYK8U90vv
o/ufQJVtMVT8QtPHRh8jrdkPSHCa2XV4cdFyQzR1bldZwgJcJmApzyMZFo6IQ6XU
5MsI+yMRQ+hDKXJioaldXgjUkK642M4UwtBV8ob2xJNDd2ZhwLnoQdeXeGADbkpy
rqXRfboQnoZsG4q5WTP468Sample
-----END CERTIFICATE-----

Certificate chains

Large global Certificate Authorities (CAs) certify other agencies to issue TLS/SSL certificates, which usually operate at a regional level. If a server's certificate was issued by an intermediate CA, the server must also host the intermediate CA's certificate, which, in turn, can be verified against a trusted root certificate that is stored locally.

Here are the steps for verifying a chain:

Download the certificates from the server.
Check to see if the server certificate matches the website name and is signed by the intermediate certificate.
Check to see if the intermediate certificate is signed by one of the trusted root certificates stored locally.

Intermediate CAs can issue certificates to other intermediate CAs; this means that the certificate chain can be longer than three certificates.

Why are TLS/SSL certificates needed?

Here are some reasons for using a TLS/SSL certificate: