No momento, esta página não está disponível em português
Developer-resource icon

Integration security guide

Best practices to mitigate security risks.

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.

This document should be used only for guidance purposes. It is not a complete list of all security measures you should take and it should not be taken as definitive advice.

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:

  • Don't 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 don't 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 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:

Secure your point-of-sale integration

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

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're 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 and will notify you through system messages if you are using cipher suites or versions that we no longer consider secure.

Make sure that you use the correct TLS version and cipher suite, otherwise it is possible that we can't receive your API requests.

Supported TLS versions and ciphers

TLS version Version support Supported ciphers
TLS 1.2 Only supported for existing merchants using strong ciphers ECDHE-ECDSA-CHACHA20-POLY1305 1
ECDHE-ECDSA-AES128-GCM-SHA256 1
ECDHE-ECDSA-AES256-GCM-SHA384 1
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES128-GCM-SHA256
TLS 1.3 Supported TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

1 ECDSA ciphers are now available on the test environment. They will be available on the live environment from April 2024.

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