how to implement 3D Secure authentication with Adyen
A practical skill for adding 3D Secure 2 authentication to Adyen payments: enabling it in the Customer Area, sending the required browser data, handling the 3DS2 action, and checking liability shift. Use when card payments need SCA compliance or fraud liability shift. Triggers: 'Adyen 3DS2', 'Adyen threeDS', 'Adyen SCA'. Not for: Adyen account setup, non-card payment methods.
how to implement 3D Secure authentication with Adyen
TL;DR
Enable 3D Secure in the Adyen Customer Area, include the shopper's browser data in your payment request, and handle the 3DS2 action Adyen returns (fingerprint or challenge). Then check the liability shift result before you capture. Most of the work is wiring the action handling, not the API call.
how to implement 3D Secure authentication with AdyenUse this when
- You take card payments through Adyen and need Strong Customer Authentication for PSD2
- You want fraud liability shifted to the issuer on card-not-present transactions
- A payment returns a 3DS2 action you are not handling yet
- You are moving from basic card auth to 3DS2 on the Adyen Checkout API
Not for this skill when
- You have not set up an Adyen account or API credential yet (do that first)
- You are using non-card methods like iDEAL or bank transfer (no 3DS involved)
- You need the native 3DS SDK for in-app flows specifically (related, but a separate integration)
Steps
1. Enable 3D Secure in the Customer Area
Turn on 3D Secure 2 under your risk and authentication settings, and set the decision rules (for example, always attempt 3DS, or attempt above an amount threshold).
Expected: the Customer Area shows 3DS2 enabled for your merchant account. Payments will not request 3DS until this is on, no matter what your API call sends.
2. Send the browser data with the payment request
For web checkouts, include the channel and the shopper's browser info in your /payments call so Adyen can run the 3DS2 fingerprint. Without browser data, the flow falls back to a clunkier redirect.
Expected: Adyen returns either an authorised result (frictionless) or an action of type threeDS2 (fingerprint or challenge). No browser data usually means a redirect action instead of the smoother in-page flow.
3. Handle the 3DS2 action
Pass the action to the Adyen Web Drop-in or Components handleAction, which renders the fingerprint iframe or the issuer challenge. After the shopper completes it, Adyen calls back with the result.
Expected: the shopper sees either nothing (frictionless pass) or their bank's challenge screen, and your frontend receives a completed result. Test this end to end with Adyen's 3DS2 test cards before touching production.
4. Check liability shift before capturing
Read the liabilityShift field in the 3DS2 result. A yes means the issuer now owns the fraud liability; anything else means you still do.
Expected: liabilityShift present and true on successful authentications. Build your capture decision around it; some merchants capture anyway but price the risk, others route non-shifted payments to manual review.
Variant: handling the challenge flow on mobile
Same API shape, but the challenge renders inside your app's browser view or the 3DS SDK. Keep the session alive through the redirect and match the returning result to the original payment reference.
Variant: 3DS2 test cards and scenarios
Adyen publishes test cards that force each outcome: frictionless success, challenge required, failed authentication, and technical error. Script all four in your staging suite; the challenge path is where integrations usually break.
Why this happens
Card networks and regulators pushed authentication onto the issuer, and Adyen implements it as an asynchronous action inside the payment flow rather than a separate API. The integration feels odd because you start a payment, pause for the shopper's bank, then resume; the action-handling pattern exists to make that pause survivable.
Edge cases and pitfalls
- Dropping the browser data silently degrades to redirect flow; users bounce more on redirects.
- Treating "challenge completed" as "payment authorised": authentication and authorisation are separate outcomes, check both.
- Timeouts on the issuer challenge: set a sane expiry and reconcile by payment reference, do not double-charge on retry.
- 3DS exemptions and TRA rules can skip authentication for low-risk payments; know which of your transactions qualify.
- Test cards behave differently per scheme; run the matrix for Visa, Mastercard, and Amex if you accept all three.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_fx0d487fbW37NaJH2BeFjA
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.