Strong customer authentication has applied to e-commerce card payments across the European Economic Area since September 14, 2019, under the EU's revised Payment Services Directive, and the protocol that carries most of that authentication is 3-D Secure 2, first published by EMVCo in 2016. For merchants, the spec is not only a fraud control — it is a liability instrument.
Nuv Media publishes information, not financial advice.
What did 3-D Secure 2 replace?
The original 3-D Secure, deployed by card networks in the early 2000s, asked shoppers for a static password on a redirect page. It cut fraud, and it cut conversions with it: the redirect broke the merchant's page, failed on early mobile browsers, and trained customers to abandon. Liability shifted to the issuer when the password was accepted, which made the friction commercially rational for everyone except the merchant watching checkout rates.
Version 2 rebuilt the flow for mobile-first checkout. Authentication runs inside the merchant's page or app through hidden device-data collection and an SDK, the issuer's access control server scores the transaction, and most sessions end with no visible customer step. EMVCo has iterated the spec since — version 2.2 extended app-based and decoupled flows — but the architecture has held: collect richer data, decide silently, challenge rarely.
The name describes three domains: the acquirer domain, where the merchant and its processor live; the issuer domain, where the cardholder's bank and its access control server live; and the interoperability domain, where directory servers relay authentication messages between the two. Every 3-D Secure 2 transaction is a conversation among exactly those three parties.
How does the frictionless flow work?
When a customer pays, the 3-D Secure 2 client gathers device and account data — device fingerprint, transaction amount, merchant category, purchase history signals — and sends it to the issuer's access control server. The issuer's risk engine evaluates the request and, for low-risk transactions, returns an authentication result with no customer interaction. The cardholder sees a normal checkout; the merchant receives proof of authentication to present if the payment is later disputed.
Frictionless authentication is risk-based authentication: the issuer, not the merchant, decides which transactions are safe enough to pass untouched. European issuers lean on it heavily because PSD2's strong customer authentication requirement demands two of three factors — something the customer knows, possesses, or is — and the issuer can often satisfy the possession factor through the device channel already in play.
When does a challenge still appear?
When the risk score is high, the issuer escalates to a challenge: a one-time passcode, an in-app approval, or a biometric prompt. Challenges still lose sales — every additional screen is an abandonment opportunity — so issuers tune their thresholds. From the merchant's side, a completed challenge is the strongest authentication result available and carries the clearest liability position.
Market practice varies. European checkout routinely shows a passcode or app approval on larger or unusual purchases, while many United States issuers authorize through risk scoring alone, and most US e-commerce still completes without any visible 3-D Secure step.
What is data-only authentication, then?
EMVCo also defines a data-only mode built primarily for the United States market, where issuers historically did not run full access control servers. In data-only, transaction data flows to the issuer for risk scoring, but the issuer does not return an authentication result — it simply proceeds with the authorization decision.
The distinction matters because liability does not move. Data-only improves the issuer's fraud decision, which can mean fewer false declines, but the merchant keeps chargeback exposure for fraud claims. Frictionless and challenge flows, by contrast, carry the liability shift. Merchants evaluating 3-D Secure adoption in the US should ask their processor which modes their issuers actually support, because the economics differ by BIN.
| Flow | Customer experience | Liability shift | Typical market |
|---|---|---|---|
| Frictionless | No visible step | Yes, on authenticated transactions | Europe, growing elsewhere |
| Challenge | Passcode or app approval | Yes, strongest position | Europe on high-risk sales |
| Data-only | No visible step | No shift for fraud claims | United States |
How does the liability shift actually work?
Card networks' 3-D Secure programs state the principle plainly: when an issuer authenticates a cardholder through 3-D Secure 2, the issuer bears the loss for subsequent fraud chargebacks on that transaction, where the network's program rules apply it. For a merchant, authenticated transactions largely close the fraud-chargeback category that card-not-present selling is most exposed to — unauthorized-use claims.
Two exceptions shape real implementations. First, merchants can maintain exclusion lists so specific high-margin or high-risk segments stay outside 3-D Secure, retaining chargeback exposure by choice. Second, in Europe, when a merchant claims a PSD2 strong customer authentication exemption instead of authenticating — low-value payments, transaction risk analysis, whitelisted beneficiaries — the merchant, not the issuer, carries the liability if the exemption is abused. Exemptions trade friction for risk; authentication trades a little friction for protection.
What does the merchant trade for the shift?
Authentication adds messages to checkout, and challenge flows add screens. The commercial work is calibration: apply 3-D Secure where fraud claims cluster, request exemptions where baskets are small and histories are clean, and keep an exclusion list for segments where conversion is worth more than the fraud saving. Merchants selling into Europe largely have no choice — strong customer authentication is law — while US merchants treat the protocol as a pricing and risk decision, processor by processor.
The other trade is operational. Authentication data changes the dispute file: an authenticated transaction disputed as fraud now gets answered with the authentication value proof, not parcel tracking. Dispute teams that have not updated their representment playbooks leave recovered money on the table.
For more context, read How Regulation II Caps Debit Interchange Fees at 21 Cents.
For more context, read payment orchestration.
For more context, read Where the FX Markup Hides in Cross-Border Payments.
