Search

Are you looking for test card numbers?

Would you like to contact support?

Native 3D Secure 2 authentication

Learn how you can natively support 3D Secure 2 in your site or app.

If you are using 3D Secure for PSD2 compliance, read our comprehensive PSD2 SCA guide.

The latest version of 3D Secure brings a new approach to authentication through a wider range of data and biometric authentication, and with an improved online payments experience.

Unlike 3D Secure 1 where the shopper is redirected to another site to verify the payment, in 3D Secure 2 the card issuer performs the authentication within your app or payment form. The shopper's identity may be verified using passive, biometric, and two-factor authentication approach. A transaction may go through a passive frictionless authentication flow or a challenge authentication flow where the issuer requires further interaction with a shopper.

As a general rule, the chargeback liability shifts from you to the issuer if the shopper completes a successful challenge authentication flow. For more information on 3D Secure 2 chargeback liability rules, see 3D Secure liability shift rules.

Native 3DS2 implementation options

Support 3D Secure 2 native authentication on top of your existing online payments integration with us.

Your Adyen integration What you need to do to support 3D Secure 2 native authentication
Online payments API Add 3D Secure 2 Components on your frontend or client and include 3D Secure 2 parameters in your existing API calls.
Quick integration Checkout SDKs

Switch to our Web, iOS, and Android Drop-in solution available from versions 3.0.0 and later.
If you want to continue using the mobile SDKs, you can upgrade to the following versions which support 3D Secure 2:

Plugins for Magento 1 and 2, SFCC, or SAP Commerce (Hybris)

Upgrade to the following plugin versions to support native 3D Secure 2 authentication:

We recommend that you upgrade to the versions above however, if you choose to continue using an older version of our plugins, we will support 3D Secure 2 through a redirect.

HPP 3D Secure 2 will be supported through a redirect. However, we strongly recommend to move your implementation to our online payments API with the 3D Secure 2 Component for a better user experience.
Classic API or CSE Use our helper functions for web and the Classic integration 3D Secure 2 SDKs for mobile.

You also have the option to choose how you want to use 3D Secure 2 with Adyen. In a full 3D Secure 2 integration, we will perform the authentication and proceed with the payment authorisation. If you choose to only perform one part of the process with us, use the following implementations with our online payments API:

  • Full integration: Perform both 3D Secure 2 authentication and payment authorisation with Adyen. 
  • Authentication-only integration: Use Adyen as a standalone 3D Secure 2 provider. Perform only the 3D Secure 2 authentication with us and submit the payment authorisation later.
  • Authorise with 3D Secure 2 MPI data: Use a third-party 3D Secure 2 provider and perform the payment authorisation request with Adyen.

Authentication flows

A transaction can go through either a frictionless or challenge authentication flow depending on the issuer's requirements.

Frictionless flow

In a frictionless flow, the acquirer, issuer, and card scheme exchange all necessary information in the background through passive authentication using the shopper's device fingerprint. In your integration, you will need to get the 3D Secure 2 device fingerprint and if it is validated and approved by the issuer, the transaction is completed without further shopper interaction.

To maximize probability of achieving a frictionless flow, include additional information in your request to help issuers validate the shopper's identity. 

Challenge flow

In a challenge flow, the issuer requires additional shopper interaction, either through biometrics, two-factor authentication, or similar methods based on SCA authentication factors

In a web-based integration, the issuer might immediately require to present a challenge to the shopper or require the challenge after processing the 3D Secure 2 device fingerprint.In an app-based flow, the 3D Secure 2 device fingerprinting process is always performed before a challenge is deemed required. 

3D Secure 2 payment flow

The following diagram illustrates full implementation authentication flows based on result codes:

A 3D Secure authentication flow starts with a payment request. Send a payment request from your server with the required 3D Secure 2 objects indicating that you are ready to support 3D Secure authenticated payments.

You will get a response containing any of the following result codes:

  • Authorised: The payment is successfully completed. If you receive this as a response to your payment request, this could mean that the transaction was either exempted or out-of-scope for 3D Secure 2. 
  • IdentifyShopper: The issuer requires the 3D Secure 2 device fingerprint. 
  • ChallengeShopper: The issuer requires shopper interaction. 
  • RedirectShopper: The issuer does not support 3D Secure 2 and you have the 3D Secure 1 fallback enabled. The transaction needs to be authenticated with 3D Secure 1.
  • Refused/ Error: The transaction was refused or something went wrong. This response includes a refusal reason.

Handle the transaction based on the result code. For example, if you received an IdentifyShopper result code, proceed to get the 3D Secure 2 device fingerprint and then submit the required data to Adyen. The possible responses are:

  • Authorised: This means the authentication was frictionless and the payment was successfully completed.
  • ChallengeShopper: The issuer requires additional shopper interaction. Proceed to the challenge flow.
  • Refused/ Error: The authentication was refused or something went wrong. This response includes a refusal reason.

For more information on result codes and the actions that you need to take, see Result codes.

3D Secure 1 fallback

In case the issuer does not support 3D Secure 2, we will initiate a 3D Secure 1 fallback by default, indicated by a RedirectShopper resultCode response. To handle this scenario, make sure that you have implemented a 3D Secure 1 authentication flow. 

If you do not want to automatically fall back to 3D Secure 1, contact our Support Team. However, note that not having a fallback implementation might negatively affect your authorisation rates since SCA is required for authorisation in some markets. 

For classic API integration, see 3D Secure 2 classic integration.

Next steps