Verify card payments with 3D Secure 2 using your classic API integration.
Compared to the first version of 3D Secure, 3D Secure 2 brings a new approach to authentication through a wider range of data, biometric authentication, and an improved online experience. In the first version of 3D Secure, the shopper is redirected to another site to answer additional security questions (usually a unique password or SMS verification). The redirection introduced in 3D Secure 1 might lead to lower conversion rates, due to technical errors during the redirection or shoppers dropping out of the authentication process.
In 3D Secure 2, the authentication is performed within your app or payment form. The shopper's identity may be verified by using passive, biometric, and two-factor authentication approach. A transaction may go through a frictionless or a challenge authentication flow.
As a general rule, the chargeback liability shifts to the issuer if the shopper completes a successful challenge authentication flow.
PSD2 and 3D Secure 2
The Revised Payment Services Directive (PSD2) is a European Union directive governing banking and payments. One of the mandates of PSD2 is the implementation of Strong Customer Authentication (SCA). When a shopper makes an online payment, more information is required at the time of the transaction.
PSD2 possible exemptions and out-of-scope transactions
If a transaction is out of scope of the PSD2 regulation, PSD2 will not require you to present an additional challenge to shopper. If a transaction falls into one of the SCA exemptions, you will most likely not be required to present a challenge, unless the issuer decides otherwise.
These transactions include:
- Transactions from a whitelisted merchant: If a shopper adds the merchant to a whitelist after a first strong authentication, all subsequent transactions can receive an exemption. However, this needs to be implemented by every issuer separately. Contact Support Team for more information.
Merchant-initiated transactions (MIT): A transaction where the shopper is not present at the moment of the purchase. Merchants usually initiate transactions after a shopper agrees to a series of MITs in the initial sign-up transaction. The initial shopper-initiated transaction should be strongly authenticated. This includes, for example, subscription charges for the same value or a variable amount.
- Low value transactions: Transactions below 30 EUR can qualify for an exemptions. However, a strong authentication is still needed every 5 transactions or when the total exempted value reaches 100 EUR.
- Low risk transactions based on TRA (Transaction Risk Analysis): Based on an acquirer's and issuer's fraud levels, the TRA exemption can be granted on all transactions below a certain amount.
- Secure corporate transactions: Transactions using virtual cards, lodged cards, and payments from central travel accounts. These transactions are considered to be already secure through existing corporate protocols. The full ranges for this type of cards are currently held by issuing banks, and are not communicated by the schemes.
- Mail Order and Telephone Orders (MOTO) transactions: MOTO transactions are not considered to be electronic payments, so these are out of the scope of the regulation. However, the schemes have placed increased restrictions on what qualifies as a MOTO transaction. Contact Support Team for more information.
- Inter-regional transactions: Payments where the issuer or the acquirer of the card are not based in Europe are also considered out of scope.
If you have questions on exemptions and out-of-scope transactions, contact Support Team.
Participating card schemes
3D Secure 2 is supported by the following card schemes:
- Discover / Diners
- American Express
- Cartes Bancaires
Uses passive authentication. The domains exchange all necessary information in the background. If the authentication is successful, the transaction is completed without further shopper interaction.
To maximize probability of achieving a frictionless flow, include additional information in your request. Parameters such as
shopperEmail help issuers validate the shopper's identity.
Under PSD2 regulations for in-scope transactions within Europe, the only way to get the frictionless flow for in-scope transactions will be to submit an exemption request, with the result depending on the issuer's approval.
The issuer requires additional shopper interaction for verification, either through biometrics, two-factor authentication, or similar methods based on SCA authentication factors.
In a browser-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.
How it works
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 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 device fingerprint and then submit the required data to Adyen. The possible responses 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.
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 Support Team. However, note that not having a fallback implementation might negatively affect your authorization rates since SCA is required for authorization in some markets.
In addition to a full integration where you perform both 3D Secure 2 authentication and payment authorization with Adyen for browser-based or app-based (Android, iOS) transactions, we also offer the following:
- Authentication only integration: Perform only the 3D Secure 2 authentication with Adyen and submit the authorization later.
- Authorize with 3D Secure 2 authenticated data: Perform the payment authorization request with Adyen using authenticated data from a third-party 3D Secure 2 provider.
Integrate a browser-based flow
Check out how you can support 3D Secure 2 on a browser.
Use Android 3D Secure 2 SDK
Learn how you can use the SDK on your Android app.
Use iOS 3D Secure 2 SDK
Learn how you can use the SDK on your iOS app.