This page explains what 3D Secure 2 (3DS2) is, how it relates to Strong Customer Authentication (SCA), and how your Valpay integration with Adyen handles the authentication step.
What 3D Secure 2 is
3D Secure 2 is an authentication protocol that adds a layer of verification for card-not-present transactions, such as online payments. During a card payment, the card issuer can confirm that the genuine cardholder is making the purchase before the payment is authorized.
3DS2 supports two implementation styles:
Native: the issuer performs authentication inside your website or app, using passive, biometric, or two-factor methods.
Redirect: the shopper is sent to the issuer's own site to provide additional data, such as a password or an SMS code. Redirects can lower conversion if shoppers drop out.
How it relates to PSD2 SCA
PSD2 (the Revised Payment Services Directive) is a European regulation that requires Strong Customer Authentication on affected online payments to make them more secure. 3D Secure is Adyen's recommended way to apply SCA, and both 3D Secure 1 and 3D Secure 2 are compliant methods.
A few points to keep in mind:
PSD2 applies to banks, not merchants. To comply, issuing banks must refuse non-compliant transactions, so you apply SCA to avoid your payments being refused.
Your payments fall in PSD2 SCA scope when both the acquiring entity and the shopper's issuer are in the European Economic Area, Monaco, Switzerland, or the UK.
Similar rules exist elsewhere, for example the Payment Services Regulations 2017 in the UK.
Whether 3DS2 is required, and whether it adds friction, depends on the region and the issuer's rules.
Frictionless vs challenge flow
When native 3D Secure 2 runs, a qualifying transaction follows one of two paths, depending on the issuer:
Frictionless flow: the parties exchange the needed data in the background using the shopper's device fingerprint. The shopper is not interrupted.
Challenge flow: the issuer asks the shopper for more proof, such as a biometric check or a two-factor code, before the payment continues.
Liability shift
A successful 3D Secure authentication can shift chargeback liability for certain fraud-related chargebacks from you to the card issuer. The exact rules depend on the card scheme and region. See Card Payments for related context.
How your integration handles it
How you implement 3DS2 depends on your server-side flow:
Sessions flow (recommended): 3D Secure 2 support is built in. You do not need extra configuration. With Drop-in and Components, the 3DS2 challenge is presented automatically as an additional action, so you do not build the authentication UI yourself.
Advanced flow / API-only: you handle the authentication step yourself. When Adyen returns an action, you submit the result to the
/payments/detailsendpoint to complete the payment. Adyen also provides a pre-built 3D Secure 2 Component for this.
Note that Apple Pay and Google Pay can carry their own authentication, so a separate 3DS2 challenge may not apply. See Apple Pay and Google Pay.
For the overall payment sequence, see Standard Payment Flow. For questions about your specific SCA obligations, contact Valpay Support.
3DS status and version in the Valpay portal
On the transaction detail page in the Valpay portal, you will see two 3DS-related fields:
3DS Status — whether 3D Secure authentication was applied to the transaction. Yes means 3DS ran on the payment. No means it did not, which can happen when the transaction is out of SCA scope, an exemption was applied, or the payment method does not support 3DS.
3DS Version — only appears when 3DS Status is Yes. Shows the specific version of the 3DS protocol used to authenticate the transaction (for example, 2.2.0).
What the version number means
The version tells you which generation of the 3DS protocol handled authentication on that transaction. This is relevant for understanding how the issuer authenticated the cardholder and whether liability shift applies.
1.0 / 1.0.2 — the original 3DS protocol. Always redirect-based, meaning the cardholder was sent to the issuer's own site. No frictionless flow, minimal data passed between parties. Most card schemes are phasing this version out, so seeing it in the portal is increasingly rare.
2.1.0 — the first major release of the EMVCo 3DS2 specification. Introduced frictionless authentication and richer device fingerprinting. Decoupled authentication was not yet available at this version.
2.2.0 — the current mainstream version and the most commonly seen in the portal. Adds decoupled authentication (the cardholder completes the challenge independently from the live transaction session), improved frictionless approval rates, and optional shopper whitelisting. Full liability shift applies to successful authentications at this version.
2.3.x — newer revisions with incremental improvements to device data collection and authentication methods. Adoption is growing as issuers upgrade.
For partners and merchants, the version number is most useful for troubleshooting and reconciliation. If a transaction was challenged or declined during authentication, the version helps confirm whether the issuer was running a current protocol. The liability shift benefit applies to all successful 3DS2 authentications regardless of whether the version was 2.1.0, 2.2.0, or later — what matters is that authentication completed successfully.