Adyen 3D Secure: How 3DS2 Authentication Works
3D Secure is the authentication layer that sits between a card payment and its approval. Adyen 3DS is one of the most widely used implementations of this standard, built into Adyen's payments platform and handling billions of transactions annually across Europe, North America, and Asia.
How Adyen handles 3D Secure matters for any developer integrating card payments, and for any merchant trying to balance fraud prevention against checkout conversion. The two are in direct tension: more authentication means less fraud, but it also means more friction, and friction costs sales. The regional data on this — particularly from the US and Brazil — is more severe than most merchants expect.
What Is Adyen 3D Secure?
When someone pays online with a Visa card, Visa can require the shopper to prove they're who they say they are. The mechanism for doing that is 3D Secure — an authentication protocol that card networks (Visa calls it Verified by Visa, Mastercard calls it SecureCode) developed specifically for card-not-present transactions. Adyen 3DS is how Adyen implements it across its payments platform.
There are two versions. The first generation — 3DS1 — shunted the shopper off to the card issuer's own authentication page, breaking the checkout flow entirely. Conversion dropped. Merchants hated it. Most have abandoned 3DS1 wherever they can.
3D Secure 2 replaced it with a smarter approach. Rather than redirecting, it quietly collects device and browser data in the background — screen resolution, time zone, IP address, session history — and sends all of it to the issuing bank. The bank's risk engine gets 150+ data points to evaluate. With that much signal, it can often just approve the transaction silently, without the shopper ever knowing 3DS ran at all.
EU and EEA merchants don't have much choice here. PSD2's Strong Customer Authentication rules mandated 3D Secure 2 for card payments above €30. Any payment method involving a card transaction falls within scope. Outside the EU, 3DS2 is strongly recommended for the fraud liability protection it provides, but not legally required.
How Adyen 3DS2 Authentication Works
The 3DS2 flow runs through three phases: data collection, authentication, and authorization. It completes in seconds when everything goes smoothly.
- Shopper initiates payment — enters card details on the merchant's checkout page
- Adyen collects device data — a small JavaScript component (the 3DS2 fingerprint) runs in the background, gathering browser and device signals: screen resolution, time zone, language, device type, IP address
- Adyen sends an authentication request — the device fingerprint and transaction data are packaged and sent to the card issuer via the card network
- Issuer evaluates the request — the issuer's risk engine assesses the 150+ data points against the cardholder's behavior history and fraud signals
- Issuer decides: frictionless or challenge — if risk is low, the issuer authenticates silently (frictionless); if risk signals are present, the issuer requests a challenge
- Challenge flow runs if triggered — the shopper completes additional verification: one-time password, biometric, or bank app confirmation
- Authentication result returned — Adyen receives the authentication result (authenticated, not authenticated, or attempted)
- Adyen submits the authorization — with the authentication result attached, the payment moves to authorization through the card network
- Liability shift applies — if authentication succeeded, fraud-related chargeback liability shifts from the merchant to the issuing bank
The key difference between 3DS1 and 3D Secure 2 is step 2. In 3DS1, the issuer had almost no data to work with, so challenges were frequent. In 3D Secure 2, the richer device fingerprint means issuers can approve far more transactions silently, regardless of which payment method the shopper uses, as long as it's a card.
Frictionless vs. Challenge Flow in Adyen
The frictionless and challenge outcomes are determined by the issuer, not by Adyen or the merchant. That said, Adyen's data collection quality directly affects how often issuers can go frictionless — better device fingerprinting data means fewer issuers need to escalate to challenge.
| Factor | Frictionless flow | Challenge flow |
|---|---|---|
| Shopper experience | Invisible — no extra step | Requires OTP, biometric, or app confirmation |
| Conversion impact | Minimal — same as no 3DS | Significant drop (varies by market) |
| Who decides | Issuing bank's risk engine | Issuing bank's risk engine |
| Trigger | Risk signals low, data sufficient | Risk signals elevated or data incomplete |
| Liability shift | Yes — issuer bears fraud risk | Yes — issuer bears fraud risk |
| Typical share | 40%–93% of transactions (market-dependent) | 7%–60% (market-dependent) |
Japan shows the frictionless upside: approximately 60% of 3DS transactions complete frictionlessly, and overall conversion stays at 93%. Brazil is the opposite — widespread challenge flows have produced a 55% conversion hit. The US sits at a 43% average conversion impact from challenge flows, per Stripe research on 3DS adoption patterns.
Fraud protection is consistent regardless of which flow completes. Both frictionless and challenge authentication trigger the liability shift. A fraud-related chargeback after successful 3DS authentication is the issuer's financial problem, not the merchant's.
Adyen Dynamic 3D Secure Rules
Most 3DS implementations apply authentication universally: every transaction, every time. Adyen's Dynamic 3D Secure rules engine lets merchants be more surgical about it.
Dynamic 3DS lets merchants configure rule-based routing that applies 3DS selectively, based on risk signals, exemptions, and transaction characteristics. The goal is to maximize authentication on risky transactions while using exemptions to reduce friction on low-risk ones.
Key rule types available in Adyen's Dynamic 3DS configuration:
- Exemption rules — route low-risk transactions through SCA exemptions (transaction risk analysis, low-value exemptions below €30, trusted merchant listings) to skip 3DS entirely where legally permitted
- Soft decline handling — automatically re-route transactions that issuers decline without 3DS, triggering 3DS authentication on the second attempt
- Velocity rules — apply 3DS based on transaction frequency from a given card or device within a time window
- Amount thresholds — trigger 3DS above a specified transaction value while exempting smaller purchases
- Country-based rules — apply different authentication logic depending on the shopper's country, accounting for regional SCA mandates and issuer behavior
- Card type rules — route corporate or premium cards through 3DS while allowing standard consumer debit through exemption flows
Merchants who configure Dynamic 3DS intelligently can reduce challenge flow exposure significantly compared to universal 3DS application, while maintaining full fraud protection on high-risk segments.
Adyen 3DS Integration Methods
How merchants integrate 3DS through Adyen depends on their payment integration method. Adyen supports three primary approaches:
- Sessions (recommended) — Adyen's prebuilt integration handles 3DS natively with no extra configuration. The Sessions flow collects device fingerprints automatically and manages frictionless/challenge routing transparently. Simplest path for most merchants.
- Drop-in — Adyen's hosted UI component embeds in the merchant's checkout page and handles 3DS flows, including challenge popups and result handling. Less configuration than a full API integration, more customization than Sessions.
- API integration — full control over the 3DS flow. The merchant's code handles fingerprint collection, authentication requests, result parsing, and authorization submission. Required for highly customized checkouts or native mobile apps needing native 3DS2 within the app interface.
For most e-commerce merchants, Sessions or Drop-in provides the best balance of integration effort and 3DS compliance. Native API integration is typically used by enterprise merchants with dedicated payment engineering teams.
One Adyen-specific detail: native 3DS2 in mobile apps requires Adyen's iOS and Android SDKs, which include the fingerprinting components and challenge UI. Web integrations using Sessions or Drop-in handle this automatically.
3D Secure Conversion Impact: Regional Data
The headline "3DS hurts conversion" is partially true, but the actual impact depends almost entirely on market-specific factors — how familiar shoppers are with bank authentication flows, and whether mobile banking UX is smooth.
| Market | Challenge rate | Conversion impact | Notes |
|---|---|---|---|
| Japan | ~40% challenge | Minimal drop | Bank app authentication is familiar; high frictionless rate |
| UK | ~25% challenge | Low-moderate | Bank app (biometric) is standard, fast experience |
| France | ~50% challenge | Moderate | Challenge rates doubled but users familiar with OTP |
| US | ~45% challenge | -43% on challenged transactions | 3DS still novel; users unfamiliar with bank OTP flow |
| Brazil | ~60%+ challenge | -55% | Challenge rates high; bank authentication flows inconsistent |
| Global average | — | USD 1.72B market (2026) | Expected to reach USD 4.66B by 2034 |
Fraud reduction numbers are clearer: 3DS authentication reduces fraud disputes by up to 80%, and Europe estimates it prevents roughly €900 million in annual fraud losses. These are merchant-side savings. Chargebacks are expensive beyond the transaction value — they add operational overhead, risk scoring penalties, and in some cases processor relationship risk.
The conversion paradox resolves when you separate two things: whether 3DS was applied, and whether the challenge was smooth. Markets with good mobile banking apps and experienced shoppers absorb challenge friction well. Markets where shoppers hit OTP-via-SMS or inconsistent bank apps lose a lot of checkouts.
3DS and Crypto Payments
3D Secure applies to card payments and nothing else. Cryptocurrency transactions don't go through card networks, so there's no 3DS flow to trigger.
That cuts both ways. Crypto payment gateways can't rely on the 3DS liability shift — there's no issuing bank to transfer the fraud risk to. Security depends on other mechanisms: transaction monitoring, wallet screening, real-time risk scoring at the gateway level.
The other side: no 3DS friction. No device fingerprinting running in the background, no issuer challenge, no OTP to wait for. The checkout is as simple as scanning a wallet address or confirming in a wallet app. For merchants who've watched challenge flow damage conversion in the US or Brazil, that simplicity is worth real money.
For merchants who want to offer crypto as a payment option alongside traditional cards, Plisio provides a crypto payment gateway that handles crypto acceptance without adding 3DS compliance complexity to the merchant's stack.
