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.
The following integrations are PSD2 SCA compliant. You don't need to do anything further if you're using them:
- Adyen Online Payments client-side libraries: Web Drop-in and Components, Android Drop-in and Components, and iOS Drop-in and Components.
- Adyen plugins: Adobe Commerce (formerly Magento 2), Salesforce Commerce Cloud, Shopware 5 and 6, Prestashop, SAP Commerce (Hybris), and Oracle Commerce Cloud.
- API only with 3D Secure redirect. You can also support 3D Secure 2 using the same redirect authentication.
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.
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 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
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.
We support the following scenarios using the API request:
- Specify per transaction whether to perform 3D Secure.
- 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.
No longer required if you use Checkout API v69 or later.
authenticationData.attemptAuthentication: (Optional) Indicates if you want to perform 3D Secure authentication for the particular transaction. Possible values:
- always: Perform 3D Secure authentication.
- never: Don't perform 3D Secure authentication. If PSD2 SCA regulations require that you must perform authentication, the transaction gets declined.
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.
threeDS2RequestData.threeDSRequestorChallengeInd: Indicates your preference for a challenge for the particular transaction. Possible values:
- 01: No preference. Default if not set.
- 02: No challenge requested.
- 03: Challenge requested (3DS Requestor preference).
- 04: Challenge requested (Mandate).
- 05: No challenge (transactional risk analysis is already performed).
The following table describes sample setting and request values:
|Dynamic 3D Secure setting||scaExemption provided?||threeDSRequestorChallengeInd provided?||Action from Adyen|
|ALWAYS||No.||No.||Adyen performs 3D Secure authentication depending on the version the issuer supports.|
|ALWAYS||Yes, for example transactionRiskAnalysis.||No.||Adyen applies and asks for the specified exemption in the authorization request.|
|PREFERNO||Yes, for example lowValue.||No.||Adyen applies and asks for the specified exemption in an authorisation request. Device fingerprinting isn't performed.|
|PREFERNO||No.||No.||Adyen chooses the path with the highest authorization rate.|
|ALWAYS||No.||Yes, for example 02.||Adyen performs 3D Secure authentication depending on the version the issuer supports. We relay your challenge preference to the issuer. However, the issuer decides if the shopper gets a challenge.|
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
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:
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 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.
transStatusfrom the Authentication-only flow response.
ECIfrom the Authentication-only flow response.