Adyen is no longer developing the Classic API integration
This page is for the Classic API (/authorise) integration, which we no longer accept new integrations with.
We strongly recommend switching to the newer Native 3D Secure 2 on Checkout API integration.
PSD2 compliance
If you are using 3D Secure for PSD2 SCA compliance, get more information from our comprehensive 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 natively on top of your existing classic API integration with us.
| Your Adyen integration | What you need to do to support 3D Secure 2 native authentication |
|---|---|
|
Checkout 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 |
For mobile, upgrade to For Web SDK, no action required. 3D Secure 2 will be supported in all existing versions through a redirect. |
|
Plugins for Magento 1 and 2, PrestaShop, SFCC, or SAP Commerce (Hybris) |
Upgrade to the following plugin versions to support native 3D Secure 2 authentication: Our PrestaShop plugin supports native 3D Secure 2 from version 1.0.0. 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. |
Authentication flows
A 3D Secure 2 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.
Challenge flow
The issuer requires additional shopper interaction for verification, either through biometrics, two-factor authentication, or similar methods based on SCA authentication factors.
In a web-based integration, the issuer might require the challenge right after you submit a payment request or after you send 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 flows
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 has been successfully authorised. 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 payment is routed to the 3D Secure 1 flow, based on issuer performance. 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 device fingerprint and then submit the required data to Adyen. The possible responses after you submit the device fingerprint results are:
- Authorised: This means the authentication was frictionless and the payment has been authorised.
- 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.
Payments routed to 3D Secure 1
It is possible that the authentication falls back to redirecting the shopper to the issuer's site. Therefore, we recommend that your integration also supports the redirect flow.
Implementation options
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:
- Full integration on web, iOS, or Android: Perform both 3D Secure 2 authentication and payment authorisation with Adyen.
- Authentication-only: Perform only the 3D Secure 2 authentication with us and submit the payment authorisation later.
- Authorize with 3D Secure 2 authentication data: Use a third-party 3D Secure 2 provider and perform the payment authorisation request with Adyen.