Search

Are you looking for test card numbers?

Would you like to contact support?

Default icon

Implement SCA compliance

Learn how to manage PSD2 SCA compliance for your transactions.

Do your transactions need to be PSD2 SCA compliant? If yes, you need to implement 3D Secure.

PSD2 mandates strong customer authentication for online payments and online banking transactions. This means that before issuing banks authenticate a transaction, the shopper is required to provide two out of three factors:

  • Something only the shopper knows.
  • Something only the shopper possesses.
  • Something the shopper is.

For example, before an issuing bank authenticates and authorises a payment, a shopper is required to supply a one-time authentication code received on their phone (something the shopper possesses), and a password that only the shopper knows (something the shopper knows).

Not all transactions need to undergo SCA. These transactions are classified as possible exemptions, and if the issuing bank approves, may not require SCA. See Possible SCA exemptions.

If you are using our Checkout SDKs, HPP, Plugins, or APIs with 3D Secure 1 integration, you are already PSD2 SCA-compliant and don't need to do anything. You can also support 3D Secure 2 through the same redirect authentication.

To ensure that your transactions meet SCA requirements, we recommend that your integration supports both 3D Secure 1 and 3D Secure 2. To learn more about country-specific information regarding PSD2 SCA compliance, refer to our Support guide.

If you already have an existing 3D Secure 1 integration with us, you can choose to not do anything. However, we also have existing solutions to support 3D Secure 2 authentication natively within your app or payment form. If you decide to implement native 3D Secure 2 authentication in addition to your 3D Secure 1 integration, refer to our 3D Secure implementation options.

Along with 3D Secure, another way to make sure your transactions meet SCA requirements is using local payment methods and international wallets. Depending on your market and use case, using these may result in significantly higher conversion rates.

Next to international wallets like Apple Pay and Google Pay, we see well-performing local payment methods in the EEA across several markets. For example, Bancontact Mobile in Belgium, iDEAL in The Netherlands, MobilePay, Vipps and Swish in the Nordic countries (Norway, Sweden, Denmark, Finland), EPS in Austria, Blik in Poland, and MBWay in Portugal. For more details, visit our payment method overview page.

After you have set up a 3D Secure implementation with Adyen, your options are:

Regardless of the option you choose, note that the general rule for chargeback liability shift applies. If you, Adyen on your behalf, or your acquirer requests an exemption and the request is accepted by the issuer, the liability stays with you. If the exemption is applied by the issuer, the liability shifts to the issuer.

To check if SCA exemptions apply to your transactions, see Possible SCA exemptions.

In addition to managing exemption requests, you can also help increase the probability of achieving an exemption by providing additional information in your payment request. Issuing banks can use these information and may then choose to apply the TRA exemption without the you requesting for it.

Option 1: Default PSD2 compliance handling

If you want to manage PSD2 compliance on your own, skip this section and proceed to handle PSD2 compliance on your own using Dynamic 3D Secure or submit preferences through your API request.

By default, our Authentication Engine will handle the PSD2 SCA compliance for you. We will not trigger 3D Secure for out-of-scope transactions or if the issuing bank does not enforce 3D Secure. Our Authentication Engine will also handle requesting an exemption whenever applicable.

Option 2: Configure rules with Dynamic 3D Secure

Skip this section if you want to use our default compliance handling. If a transaction is eligible for PSD2 SCA, by default Adyen will apply and request the most suitable exemption type on your behalf.

Use Dynamic 3D Secure to define additional conditions for transactions that you want to apply 3D Secure authentication on. For example, you can set conditions to use 3D Secure for transactions that you deem as high risk.

Scenarios Action from Adyen
Transaction meets condition with a Use 3DS: Always rule We will request the issuer to perform 3D Secure 1 or 2 depending on the version supported by the issuer.
Transaction meets condition with a Use 3DS: Prefer no rule We will not request 3D Secure authentication unless the issuing bank requires it to complete the authorization.
Transaction does not meet any of your configured rules Our Authentication Engine will automatically trigger 3D Secure (1 or 2) if a transaction is in scope of PSD2 and SCA is mandated. We expect issuers to soft decline unauthenticated transactions more as the transition period continues in 2020 and 2021. If an exemption is applicable for a transaction, we will manage the exemption request. For more information on how different countries and issuers plan to handle PSD2 SCA compliance, refer to our Support guide.

See Dynamic 3D Secure to learn how you can configure rules.

Option 3: Specify preference in your API request

Skip this section if you want to use our default compliance handling.

If you choose this option, this will override our default PSD2 compliance handling logic, including checking if the transaction is out of scope, determining the most suitable exemption type, and evaluating whether to send the exemption in the authentication or authorisation request.

We recommend you use the API fields only if you have an extensive knowledge of PSD2 SCA regulations and the 3D Secure protocol.

To manage 3D Secure preferences on a per transaction level, submit the following fields in your API request. If you also have Dynamic 3D Secure rules enabled, transaction-level preferences will override rules set in Dynamic 3D Secure.

  • additionalData.executeThreeD: Indicates if you want to perform 3D Secure authentication for the particular transaction or not.

    • true: Perform 3D Secure authentication depending on the version the issuer supports.
    • false: Do not perform 3D Secure authentication. However, note that PSD2 SCA requirements might mandate you to perform 3D Secure anyway so if this is set to false, this increases the chance of getting the authorisation declined.
  • additionalData.scaExemption: Indicates the exemption type that you want to request for the particular transaction. If a value is specified, this will override our exemption logic.

    • lowValue
    • secureCorporate
    • trustedBeneficiary
    • transactionRiskAnalysis: By default, Adyen will determine whether it is possible to apply a TRA exemption on a transaction as per option 1. You also have the option to either apply the Transaction Risk Analysis (TRA) exemption per transaction yourself, or to disable the TRA exemption from being applied. You can configure this in our Customer Area. Navigate to Risk > Risk Settings > General > Perform TRA. If you choose either of these options, you will override Adyen's choice to apply TRA for a transaction or not.
  • threeDS2RequestData.challengeIndicator: Indicates your preference for a challenge for the particular transaction.

    • noPreference: Default if not set.
    • requestNoChallenge
    • requestChallenge
    • requestChallengeAsMandate

If the issuer denies the exemption request, you will receive a soft decline code in the API response indicating that an authentication is required for the transaction. See our generic refusal reasons and raw acquirer responses.

The following table describes sample values:

executeThreeD value scaExemption provided? challengeIndicator provided? Action from Adyen
TRUE No No, by default this is noPreference. Adyen will perform 3D Secure authentication depending on the version the issuer supports.
TRUE Yes, for example transactionRiskAnalysis. No, by default this is noPreference. Adyen will apply and ask for the specified exemption in the authentication request, after the device fingerprint is submitted to the issuer. Card schemes will start supporting this from August or September 2019.
FALSE Yes, for example lowValue. No, by default this is noPreference. Adyen will apply and ask for the specified exemption in an authorisation request. Device fingerprinting will not be performed.
FALSE No No, by default this is noPreference. Adyen will not apply 3D Secure authentication for the transaction.
TRUE No Yes, for example requestNoChallenge Adyen will perform 3D Secure authentication depending on the version the issuer supports. We will relay your challenge preference to the issuer, however, it is up to the issuer to decide if the shopper gets a challenge or not.

Sample request for 3D Secure 2 exemption

{
  "amount":{
    "currency":"EUR",
    "value":1000
  },
  "reference":"YOUR_ORDER_NUMBER",
  "paymentMethod":{
    "type":"scheme",
    "encryptedCardNumber":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "encryptedExpiryMonth":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "encryptedExpiryYear":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "encryptedSecurityCode":"adyenjs_0_1_18$MT6ppy0FAMVMLH...",
    "holderName":"S. Hopper"
  },
  "additionalData" : {
     "allow3DS2" : true,
     "executeThreeD" : true,
     "scaExemption" : "transactionRiskAnalysis"
  },
  "browserInfo":{
    "userAgent":"Mozilla\/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/70.0.3538.110 Safari\/537.36",
    "acceptHeader":"text\/html,application\/xhtml+xml,application\/xml;q=0.9,image\/webp,image\/apng,*\/*;q=0.8",
    "language":"nl-NL",
    "colorDepth":24,
    "screenHeight":723,
    "screenWidth":1536,
    "timeZoneOffset":0,
    "javaEnabled": true
  },
  "shopperIP": "192.0.2.1",
  "channel" : "web",
  "origin" : "https://your-company.com/",
  "returnUrl" : "https://your-company.com/checkout/",
  "merchantAccount":"YOUR_MERCHANT_ACCOUNT"
}

See also