Integration security guide

Attackers can try to steal card data by exploiting weaknesses in your systems. To protect your data, and that of your customers, make sure that you implement the security measures described on this page.

Secure your accounts

Attackers might try to forge or steal login credentials to gain access to your system environment. Secure all accounts including Customer Area accounts, website accounts, server accounts and accounts for any other third party services you use. Follow these recommendations for any system that requires login credentials:

• Use strong passwords with at least twelve characters. This helps to prevent brute force attacks where attackers check different possible passwords hoping to guess correctly.

• Block the session after an incorrect password is entered repeatedly, for example after five wrong attempts. This prevents attackers using brute force methods from trying different passwords more than a set number of times.

• Give each user their own account and do not allow shared accounts. This means you can trace actions taken by individual users.

• Enable two-factor authentication to prevent unauthorized users from logging in.

• Replace all vendor-supplied usernames and passwords.

• Train staff to be aware of phishing or other social engineering techniques.

See OWASP's authentication cheat sheet for more guidance.

Customer Area accounts

As well as the steps above, make sure you have the following in place for your Customer Area accounts:

• Do not give users more permissions than they need to perform their tasks.

• When creating a user, define trusted IP addresses from which the user can log in.

Secure your online payments integration

Most online attacks are related to security flaws in your checkout or payment pages. The security of your own webpages and apps is your responsibility, as Adyen has limited ability to prevent attacks in environments we do not control. Read more about your responsibilities, and those of Adyen, in our PCI DSS compliance guide.

Back-end systems

• Install recommended security updates for all your systems and software as soon as they are available.

• Follow security recommendations given by your ecommerce or website provider.

• Make sure that you can always check what has happened with your back-end systems, so that you can detect and research any unusual activity. Review any changes to your payment pages and related source code.

• Make sure that your systems maintain secure connections with Adyen, for example by using allowlisting.

Third-party components

If you have vulnerable third-party components in your webpage, attackers might be able steal data in various ways, for example by making your website execute their own code.

Follow these best practices to reduce risks:

• Make sure that your returnUrl cannot be easily tampered with. For example, you should not generate the returnUrl on a system that is publicly accessible. Automatically validate the host part of the URL before including it in your API request. This helps to prevent attackers from changing the destination of a payment redirect to collect a shopper's card data.

• Make sure that client-side resources in your pages, such as JavaScript libraries, CSS, chatbots, and analytics, are loaded from authorized domains.

• If you use Web Drop-in/Components, implement Subresource Integrity hashes.

• To have control of the resources that are loaded on your site, implement Content Security Policy (CSP). This helps prevent attacks such as Cross-Site Scripting and data injection attacks.

Secure coding practices

Follow secure coding practices and assess the security of your systems using established public frameworks and guidelines, such as those from OWASP and NIST.

These resources are a good starting point:

• OWASP top ten security risks and mitigations
• OWASP's cheat sheets
• NIST Secure Software Development Foundation

Secure your in-person payments integration

Security risks with in-person payments are related to the payment terminals: physical tampering, and replacing terminals with tampered terminals.

• Maintain an inventory of active and inactive terminals, and review it regularly. See the point-of-sale documentation for what to do when a payment terminal is lost or stolen.

• Update your terminals to the latest software as soon as possible. We strongly suggest you use automatic updating.

Read the PCI SSC guide on skimming prevention, which explains all forms of skimming, risk profiles, and the impact of skimming. It covers all the points listed below in depth.

Prevent tampering

To keep the data of your customers safe, make sure that malicious actors cannot access your payment terminals.

• Place the terminals in a monitored environment, both during and outside of business hours. Be aware of suspicious activity around the terminal.
• Inspect your payment terminals to make sure they have not been tampered with. You must do this when you receive a new terminal and also at regular intervals after.
• Verify the identity of anyone who requests access to the terminal, for example individuals claiming to be repair or maintenance personnel. Adyen terminal maintenance staff will never arrive without prior arrangement, so check that maintenance is planned.

In-store measures

• Make sure that the location of the payment terminal does not allow the PIN to be observed while the customer is entering it. Pay special attention to reflective surfaces nearby, cameras, or the position of the cashier with respect to the payment terminal.
• Train your staff to instruct customers to hide their PIN while entering it on the payment terminal.

Point to point encryption

If you are using our Point-to-Point Encryption (P2PE) solution, implement all the advice in this section. You must also implement all the requirements in the P2PE Instruction Manual (PIM).

Use the correct TLS configuration

Adyen uses Transport Layer Security (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.

Based on industry best practices, we regularly change our TLS certificates for all of our online services.

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. Make sure that you use the correct TLS version and cipher suite, otherwise it is possible that we cannot receive your API requests.

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.

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).

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 all 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
  • DigiCert Global Root G2
  • DigiCert Global Root G3

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

  • Regular business practice: we send a system message 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 changes.

Test your TLS configuration

To check if you are using a compatible TLS configuration:

1. Send a test request to one of the dedicated endpoints that only accept connections with a correct TLS configuration. These endpoints have tls-check added to the base URL:

   • checkout-tls-check-test.adyen.com
   • pal-tls-check-test.adyen.com
   • cal-tls-check-test.adyen.com
   • bank-tls-check-test.adyen.com
   • kyc-tls-check-test.adyen.com
   • configurationapi-tls-check-test.adyen.com

   Example
   Instead of sending a request to https://checkout-test.adyen.com/checkout/v70/sessions, you send it to https://checkout-tls-check-test.adyen.com/v70/sessions.

2. If the connection is dropped or refused, update to a supported TLS version and cipher suite, and try again.
   If you receive an API response, your TLS configuration is compatible.

Learn more

• NIST Secure Systems and Applications
• OWASP Security Verification Standard
• SANS resources