---
title: "Transport Layer Security (TLS)"
description: "Use the correct TLS configuration to protect data during transmission."
url: "https://docs.adyen.com/development-resources/security/sensitive-data/tls"
source_url: "https://docs.adyen.com/development-resources/security/sensitive-data/tls.md"
canonical: "https://docs.adyen.com/development-resources/security/sensitive-data/tls"
last_modified: "2026-06-01T15:33:16+02:00"
language: "en"
---

# Transport Layer Security (TLS)

Use the correct TLS configuration to protect data during transmission.

[View source](/development-resources/security/sensitive-data/tls.md)

The Transport Layer Security (TLS) protocol is essential for maintaining secure communications. Adyen uses TLS and TLS certificates to make sure of the following:

* The connection between your system and our platform is secure.
* You can verify that you are communicating with our platform.

Different TLS versions support different cipher suites (encryption algorithms) to encrypt the data that is transported. In accordance with PCI DSS requirements, Adyen supports specific TLS versions and ciphers that the industry considers as strong.

If you do not use the correct TLS version and cipher suite, it is possible that we cannot receive your API requests.

## Requirements

Before you begin, check if the information on this page applies to you.

| Requirement          | Description                                                          |
| -------------------- | -------------------------------------------------------------------- |
| **Integration type** | The information on this page is relevant for all Adyen integrations. |

## Supported TLS versions and ciphers

Different TLS versions support different cipher suites (encryption algorithms) to encrypt the data that is transported. In accordance with PCI DSS requirements, we support specific TLS versions and ciphers that the industry considers as strong. Cipher suites that are considered strong today may be considered weak in the future. Adyen continuously monitors which versions and cipher suites are used to connect to our platform. If you are using cipher suites or versions that we no longer consider secure, we notify you through [Customer Area notifications](/account/notification-center). Make sure that you use a supported TLS version and cipher suite, otherwise it is possible that we cannot receive your API requests.

| TLS version | Version support                                            | Supported ciphers                                                                                                                                                             |
| ----------- | ---------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| TLS 1.2     | Only supported for existing merchants using strong ciphers | ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 |
| TLS 1.3     | Supported New integrations must use TLS 1.3                | TLS\_AES\_256\_GCM\_SHA384 TLS\_CHACHA20\_POLY1305\_SHA256                                                                                                                    |

Make sure your TLS connections use SNI.

New integrations must use TLS 1.3 with the TLS\_AES\_256\_GCM\_SHA384 or TLS\_CHACHA20\_POLY1305\_SHA256 cipher suite.

If you are currently using TLS 1.2, we encourage you to **update to TLS 1.3** because TLS 1.3 offers significant improvements:

* Stronger encryption algorithms, including support for modern cipher suites like AES-GCM and ChaCha20-Poly1305. This makes data transmissions more resistant to attacks.
* Faster handshake: the performance is improved because establishing a secure connection is a lot faster.
* Forward secrecy: if a private key becomes compromised, encrypted communications and sessions recorded in the past cannot be retrieved and decrypted.
* Removal of outdated and less secure cryptographic algorithms and features.

## Certificate pinning

We strongly recommend that you do not use [certificate pinning](https://www.ssl.com/blogs/what-is-certificate-pinning/).

If you use certificate pinning, your platform only accepts the certificate that you pinned for Adyen. When we change our TLS certificate and present a different certificate during the TLS handshake, your application refuses to connect to our platform, even when the updated TLS certificate is issued by a trusted [Certificate Authority (CA)](https://www.ssl.com/article/what-is-a-certificate-authority-ca/).

Why Adyen does not support certificate pinning of any kind:

* Outside of Adyen's control: your system handles certificate pinning. We do not know if you do it or which certificates you pin.
* Risk of failing connections: when we update our TLS certificate, and your system still expects the previous one, your connection to our platform breaks.

### Certificate changes

When Adyen changes TLS certificates, no issues occur if you do not use certificate pinning. However, some organizations have policies that require certificate pinning, which can cause issues and broken connections with our platform.

If you must use certificate pinning, do the following to reduce the risk of issues.

* Only pin the root certificates: instead of pinning the leaf certificates or the entire certificate chain, you must pin all of the following root certificates:

  * [DigiCert Global Root CA](<https://www.digicert.com/kb/digicert-root-certificates.htm#:~:text=F0:AA:B7-,DigiCert Global Root CA,-Download PEM |>)
  * [DigiCert Global Root G2](<https://www.digicert.com/kb/digicert-root-certificates.htm#:~:text=expired   revoked-,DigiCert Global Root G2,-Download PEM |>)
  * [DigiCert Global Root G3](<https://www.digicert.com/kb/digicert-root-certificates.htm#:~:text=expired   revoked-,DigiCert Global Root G3,-Download PEM |>)

* Keep track of TLS certificate updates: even if you pin all the root certificates, Adyen can add a new Root Certificate Authority (Root CA) to our trust store in the following cases:

  * Regular business practice: we send a [system message](/account/notification-center#service-status-messages) to notify you 30 days before we make the change.
  * Emergency cases: the notice period can be shorter before we make the change.

It is your responsibility to ensure your applications (for example, web or mobile) can handle any certificate changes.

## See also

* [Read more about Transport Layer Security](https://en.wikipedia.org/wiki/Transport_Layer_Security)
