Implement SCA compliance

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.

We recommend using our solutions to support 3D Secure 2 authentication natively in your app or payment form. To implement native 3D Secure 2 authentication in addition to your 3D Secure redirect integration, use one of 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:

• Let Adyen handle PSD2 compliance by default.
• Configure rules using Dynamic 3D Secure.
• Submit your preference for each transaction in your API request.

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.

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 this information and may then choose to apply the transaction risk analysis (TRA) exemption without you requesting it.

Option 1: Default PSD2 compliance handling

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

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.

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

Option 3: Specify preference in your API request

We support the following scenarios using the API request:

Perform 3D Secure authentication

• Specify per transaction whether to perform 3D Secure.

Request and/or apply a 3D Secure exemption

• Request an exemption in the authentication flow
  You can request a specific exemption in the authentication flow. The issuer can grant or deny this request.
• Apply the exemption in the authorisation flow
  If the exemption is granted, and you use the authorisation-only flow, you must also apply the exemption.

Perform 3D Secure authentication

Including this parameter overrides any Dynamic 3D Secure rules that you have configured.

Request an exemption in the authentication flow

Request an exemption in the 3D Secure authentication flow and apply the exemption in the authorisation request if you use the authorisation-only flow. Alternatively, Adyen can request exemptions for you.

To request exemption for a transaction during the authentication flow, include additional fields in your payment request.

Possible responses

The /payments response contains a transStatus parameter that tell you if the requested exemption was granted. If you use the authentication-only flow, your integration must be able to handle all the following responses.

When the issuer declines the exemption without failing the transaction, you get a response indicating that an authentication is required for the transaction and the shopper must challenged.

The response differs depending on scheme (Visa or Mastercard) and 3D Secure 2 version (2.2 or 2.1).

Apply the exemption in the authorisation

To apply an exemption in the authorisation-only flow, use the response values from the authentication flow:

• additionalData.scaExemption: Indicates the exemption type that you want to request for the transaction. If you include a value, it overrides Adyen's exemption logic. Possible values:

• 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 have the option to change this default setting in the Customer Area. Doing this will override Adyen's choice to apply TRA for a transaction or not. Navigate to Revenue & risk > Risk Settings > General > Perform TRA. Choose Enable 3rd party/proprietary risk solution TRA to apply the TRA exemption yourself per transaction, or choose Disable to never apply a TRA exemption.

• mpiData.directoryResponse: The transStatus from the Authentication-only flow response.

• mpiData.eci: The ECI from the Authentication-only flow response.

See also