No momento, esta página não está disponível em português
Online-payment 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.

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:

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

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.

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

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.

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).

Scheme Granted Not granted
Visa - transStatus: I
- ECI: 07
Either:
- Challenge with transStatus: C.
- Failure with transStatus: N, R, U, or A.
Mastercard - transStatus: I
- ECI: 07
Either:
- Challenge with transStatus: C.
- Failure with transStatus: N, R, U, or A.

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