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.

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

The Transport Layer Security (TLS) protocol is essential for maintaining secure communications between your system and Adyen. 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.

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.

Supported TLS versions and ciphers

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.

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/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