Few pieces of payments infrastructure have a worse reputation among e-commerce teams than 3-D Secure. The original protocol earned it: pop-up windows, static passwords nobody remembered, and abandoned carts that showed up in the revenue report a week later. 3-D Secure 2, the version card networks and issuers run today, was rebuilt specifically to remove that friction, and most merchants who still fear it are reacting to a protocol that was retired years ago.
The catch is that 3DS2 only pays off when it is configured deliberately. Turn it on for every transaction and you invite challenges you did not need. Turn it off entirely and you carry fraud liability you could have transferred. Authentication is one control among several, and it works best inside the wider framework set out in our guide to payment fraud and chargeback prevention for online retailers.
This article covers how the protocol actually works, when the liability shift applies, which exemptions exist, how to measure what a challenge costs you in lost conversion, and how to roll it out without betting the whole checkout on a single switch.
In short
- 3DS2 is not the old protocol. It passes 100+ data elements from merchant to issuer before the shopper sees anything, which lets most transactions authenticate silently in the background.
- Frictionless is the normal outcome, not the exception. Well-configured merchants routinely see the large majority of 3DS2 attempts resolve without any shopper interaction, though the exact rate depends on issuer, geography and data quality.
- The liability shift is the commercial reason to use it. When authentication completes successfully, fraud chargeback liability generally moves from the merchant to the card issuer, subject to network rules that vary by scheme and region.
- Exemptions are a routing decision, not a loophole. Low-value payments, transaction risk analysis, merchant-initiated transactions and trusted-beneficiary flows can each skip a challenge, but most of them also skip the liability shift.
- The expensive mistakes are configuration mistakes. Sparse data in the authentication request, a broken challenge window on mobile, and blanket “always challenge” rules destroy more revenue than fraud does.
What 3-D Secure 2 changed compared with the original protocol
The original 3-D Secure, launched around 2001 and marketed as Verified by Visa or MasterCard SecureCode, worked on a simple premise: interrupt the checkout, redirect the shopper to their bank, and ask for a password. It authenticated the cardholder, and it did so at enormous cost. Redirect pages broke on mobile browsers, static passwords were forgotten constantly, and merchants who enabled it commonly reported double-digit drops in completed orders.
3-D Secure 2 inverts the model. Instead of starting with a shopper interruption, it starts with a data exchange. The merchant, usually via a payment service provider, sends a rich authentication request to the issuer containing device fingerprint, browser characteristics, billing and shipping address, transaction history with that merchant, cart value, and a range of other signals. The issuer scores that bundle and decides whether it already has enough confidence to approve without asking the shopper anything at all.
According to EMVCo, the standards body that maintains the specification, the protocol was designed to support both browser and app-based flows natively, and to carry substantially more contextual data than the first version. The practical consequence for a retailer is that the shopper experience under 3DS2 is usually invisible. Nothing pops up, nothing redirects, and the authentication happens in the milliseconds between “place order” and the confirmation page.
The three domains, and why the name matters
The “3-D” refers to three domains that participate in every authentication: the acquirer domain (your side, including your acquirer and payment provider), the issuer domain (the cardholder’s bank), and the interoperability domain (the network infrastructure that connects them). Understanding that split explains why so many 3DS problems are not yours to fix directly. If a specific issuer challenges aggressively, the lever you control is the quality of the data you send, not the issuer’s risk model.
It also explains why 3DS results vary so much by market. The same configuration that produces a 95% frictionless rate in one country can produce far more challenges in another, because issuer behavior differs. If you want the underlying mechanics of who sits where in that chain, our explainer on how card networks really work behind every retail checkout maps the full path from checkout button to settlement.
Authentication is not authorization
One distinction causes more confusion than any other. Authentication answers “is this really the cardholder?” Authorization answers “does this card have the funds and will the issuer approve the charge?” They are separate messages, often milliseconds apart, and a transaction can pass one and fail the other.
A successfully authenticated transaction can still be declined at authorization for insufficient funds, velocity limits or issuer risk rules. That matters when you diagnose a checkout problem: a drop in completed orders after enabling 3DS2 might sit in the authentication step, the authorization step, or in shoppers abandoning at the challenge screen. Those are three different failures with three different fixes.
| Dimension | 3-D Secure 1 | 3-D Secure 2 |
|---|---|---|
| Default shopper experience | Redirect to issuer page on nearly every transaction | Silent background check, challenge only when needed |
| Data sent to issuer | Roughly 15 fields | 100+ data elements including device and behavioral signals |
| Mobile app support | None native, browser redirect only | Native SDK support for in-app flows |
| Authentication method | Static password | Biometrics, one-time passcode, in-app banking approval |
| Typical conversion impact | Large negative, frequently double digit | Small when frictionless, meaningful only on challenged traffic |
| Merchant control | Effectively binary on or off | Per-transaction request of preferred flow, plus exemptions |
Frictionless versus challenge flows and what triggers each
Every 3DS2 attempt resolves into one of two paths. In a frictionless flow the issuer scores the incoming data, decides it is confident enough, and returns an authenticated result with no shopper involvement. In a challenge flow the issuer wants further proof and asks the shopper to complete a step: approve in a banking app, use a fingerprint or face scan, or enter a one-time passcode.
The decision belongs to the issuer, but you influence it heavily. The single largest lever is data completeness. Authentication requests that arrive with a full billing address, a valid email, a phone number, a populated device profile and prior transaction history give the issuer something to score. Requests that arrive nearly empty give the issuer no basis for confidence, and the safe default for an issuer with no information is to challenge.
What pushes a transaction toward a challenge
- Sparse or malformed data in the authentication request, especially missing address, email or device fields.
- A first-time card at your store, with no relationship history for the issuer to lean on.
- High transaction value relative to typical spend on that card.
- Mismatch between billing country, IP geolocation and shipping destination.
- Issuer-side policy, including regulatory step-up rules that force periodic strong authentication regardless of risk.
What the merchant can actually request
The protocol lets you signal a preference in the authentication request. You can indicate no preference, request a frictionless outcome, or request a challenge. Requesting frictionless is a hint, not an instruction, and the issuer can override it. Requesting a challenge, by contrast, is generally honored, which is useful when your own risk engine flags a transaction you would rather push onto the issuer.
That asymmetry is worth internalizing. You can reliably add friction; you cannot reliably remove it. Everything you do to reduce challenge rates works indirectly, by making the issuer confident enough to choose frictionless on its own.
Where authentication is heading next
The challenge experience itself is changing. Issuers have moved steadily from one-time passcodes sent by SMS toward in-app biometric approval, which is both harder to intercept and faster for the shopper. Passkeys are the next step in that trajectory, replacing the shared-secret model entirely, and the shift is already visible in how regulators treat SMS as an authentication factor. Our analysis of why passkey checkout follows OTP bans traces which markets are moving first and what merchants should expect.
The liability shift: when it applies and when it does not
Strip away the technical layers and the commercial argument for 3DS2 is one sentence: when authentication succeeds, fraud chargeback liability generally moves from you to the card issuer. A customer disputing a charge as unauthorized becomes the issuer’s problem rather than a debit against your account, because the issuer approved the authentication.
That protection is narrower than most merchants assume. It covers fraud-category chargebacks, typically the reason codes for unauthorized or fraudulent use of a card. It does not cover disputes about the goods: item not received, item not as described, duplicate processing, or cancelled recurring billing. Those remain merchant liability regardless of how the transaction authenticated, and they are a large share of real-world dispute volume.
The precise conditions vary by card network and by region, and network rules are revised regularly. Visa, Mastercard, American Express and Discover each publish their own operating regulations, and the treatment of a partially authenticated transaction (an “attempted” authentication where the issuer was unavailable) is one of the areas where they differ. Confirm the current terms with your acquirer or the relevant network’s published rules rather than relying on a general summary, including this one.
What the shift does not protect you from
Friendly fraud is the sharpest example. A cardholder who genuinely made a purchase, completed a biometric approval, received the goods and then disputes the charge anyway is a real and growing problem. If they dispute it under a fraud reason code, the authentication record is strong evidence in your favor, which is exactly why representment matters. If they dispute it as “item not received,” the liability shift is irrelevant and your delivery evidence is what decides the case.
Chargebacks also carry costs the liability shift never touches: dispute fees, operational time, and the chargeback ratio thresholds that networks monitor. A merchant sitting near a monitoring program threshold does not get relief from a liability shift on individual cases. Authentication reduces one category of loss; it does not remove the need for delivery evidence, clear billing descriptors and a working dispute response process.
| Dispute scenario | Authenticated with 3DS2 | Not authenticated |
|---|---|---|
| Cardholder says charge was unauthorized | Liability generally shifts to issuer | Merchant liability |
| Item not received | Merchant liability | Merchant liability |
| Item not as described | Merchant liability | Merchant liability |
| Duplicate or incorrect amount charged | Merchant liability | Merchant liability |
| Subscription billed after cancellation | Merchant liability | Merchant liability |
| Merchant-requested exemption applied | Typically no shift, merchant retains liability | Merchant liability |
Exemptions, low-value flows and risk-based routing
In the European Economic Area and the United Kingdom, strong customer authentication is a regulatory requirement rather than a merchant choice. The rules come from the second Payment Services Directive and its associated regulatory technical standards, supervised by the European Banking Authority in the EEA and by the Financial Conduct Authority in the UK. Those frameworks also define a set of exemptions where a transaction can proceed without a challenge.
Thresholds and conditions are set in regulation and have been amended over time, and the EU has an ongoing revision of its payments framework that may change them further. Treat any figure below as a pointer to look up, not as a settled fact, and verify the current values against the EBA, the Financial Conduct Authority or your acquirer before you build routing logic around them.
The exemptions merchants use most
Low-value transactions. Small payments have historically been exemptible below a per-transaction ceiling, with cumulative counters that force authentication after a run of consecutive exempted payments or once a cumulative spend limit is reached. The counters are issuer-side, so you cannot see how close a given card is to tripping one.
Transaction risk analysis. TRA lets a payment provider or issuer skip authentication when its own fraud rates sit below defined thresholds and the transaction value falls under a ceiling tied to those rates. This is the most powerful exemption for a high-volume, low-fraud merchant, and it is applied by your provider on your behalf rather than by you directly.
Merchant-initiated transactions. Subscription renewals, installment plans and other charges the cardholder does not actively trigger sit outside the scope of strong customer authentication, provided the initial transaction that set up the mandate was properly authenticated. Getting that first transaction right is what makes every subsequent renewal frictionless.
Trusted beneficiaries. A cardholder can add your business to a list of trusted merchants held by their issuer, after which future transactions can proceed without a challenge. Adoption depends entirely on issuer interfaces, which is why this exemption is more attractive on paper than in practice for most retailers.
Corporate and secure corporate payments. Transactions made through dedicated corporate payment processes can qualify for an exemption, which matters mainly for B2B sellers.
The trade-off nobody mentions in the sales deck
Every merchant-requested exemption you use keeps liability with you. That is the deal: you buy a smoother checkout and you keep the fraud risk. The right way to think about it is as a pricing decision, not a compliance decision. If your fraud rate on low-value first-time orders is negligible, retaining liability on those orders costs you very little and saves real conversion.
The economics only work if you can see the numbers. You need fraud rate by segment, average order value, dispute cost per case, and the incremental conversion you gain by skipping a challenge. Cost-per-transaction modeling of this kind sits alongside the same discipline retailers apply to interchange fees, where a fraction of a percent across enough volume decides whether a payment strategy is working.
| Exemption | Who applies it | Typical use case | Liability shift |
|---|---|---|---|
| Low value | Merchant or provider request | Small basket, repeat purchase categories | No |
| Transaction risk analysis | Provider or acquirer | High volume, low fraud rate portfolios | No |
| Merchant-initiated transaction | Merchant, out of scope | Subscriptions, installments, top-ups | Depends on initial setup |
| Trusted beneficiary | Cardholder, via issuer | Frequent repeat customers | No |
| Corporate payment | Merchant or provider | B2B and procurement flows | No |
| Full 3DS2 authentication | Issuer decision | New customers, high value, elevated risk | Yes, for fraud disputes |
Measuring the conversion cost of a challenge
Most teams argue about 3DS2 with anecdotes because they have not instrumented the funnel properly. The fix is unglamorous: track the authentication step as its own funnel stage, with its own drop-off, segmented the way you segment everything else.
At minimum you want five numbers. The share of attempts that resolve frictionless. The share that go to challenge. The share of challenges the shopper completes. The authorization approval rate for authenticated versus non-authenticated traffic. And the fraud and dispute rate for each cohort.
The arithmetic that decides the argument
Take a merchant processing 100,000 card transactions a month at an average order value of 120 USD. Suppose 85% resolve frictionless and 15% go to challenge, and that 80% of challenged shoppers complete it. The 20% who abandon represent 3,000 transactions, or 360,000 USD in gross merchandise value at risk in the challenge step alone.
Not all of that is lost revenue. Some of those abandoners return and complete later, some were fraudsters who abandoned precisely because they could not pass, and some would have failed authorization anyway. But even at a 50% true-loss assumption, the challenge step is costing six figures a month, which is the number that should drive your configuration work.
Run the same arithmetic on the other side. If authentication moves 0.4% of that volume out of merchant fraud liability at an average dispute cost of 150 USD including fees and handling, the saving is 60,000 USD a month. Whether 3DS2 is net positive depends entirely on those two figures for your business, not on a general claim about the protocol.
Segment before you conclude
Aggregate numbers hide the decision. Challenge rates and completion rates vary sharply by issuing country, card brand, device type, new versus returning customer, and order value band. A single blended abandonment figure will tell you that 3DS2 “costs 3% of orders” and hide that the real picture is 0.5% on returning desktop customers and 12% on first-time mobile buyers in one specific market.
Mobile deserves particular scrutiny. Challenge completion on mobile web has historically lagged desktop, because app-switching to a banking app and returning to a browser session is a fragile sequence. If your mobile challenge completion is more than a few points below desktop, you have a technical problem, not a shopper-behavior problem.
Common misconfigurations that quietly kill approvals
The failures that cost the most money are rarely dramatic. They do not throw errors or trigger alerts. They just move a few percent of transactions from frictionless to challenged, or from challenged to abandoned, and the loss shows up as an unexplained dip in conversion.
Sending the minimum viable payload
This is the most common and most expensive mistake. Many integrations send only the fields a provider marks as strictly required, omitting optional ones that materially improve issuer confidence: cardholder email, phone number, full billing address, shipping address, account age at your store, prior successful purchase count, and device data.
The optional fields are optional to the protocol, not to the outcome. An issuer scoring a request with nine populated fields will challenge more often than one scoring a request with thirty. Audit an actual outbound authentication request against the full field list your provider supports, and populate everything you legitimately hold.
Breaking the challenge window
The challenge is rendered in an iframe or a native SDK view. Content security policy headers that block the issuer’s domain, an iframe sized too small for the issuer’s content, aggressive cookie blocking, or a single-page app that unmounts the container on a state change will all break it. The shopper sees a blank box or a spinner and leaves.
Test this on real devices across your top issuing banks, not only in a sandbox. Sandbox challenge pages are simplified stand-ins and rarely reproduce the layout quirks of a live issuer’s screen.
Treating every transaction identically
A blanket “always request challenge” rule is the configuration equivalent of running 3DS1. It guarantees maximum friction on your safest traffic, which is where most of your revenue is. The mirror-image error, requesting frictionless on everything including obviously risky orders, gives up the liability shift exactly where you most need it.
Ignoring soft declines
When an issuer declines an authorization because authentication was required but not performed, that is a soft decline. The correct response is to step the transaction up to 3DS2 and retry. Integrations that treat a soft decline like a hard decline show the shopper a generic “payment failed” message and lose a sale that was fully recoverable.
Letting the data go stale
Recurring and card-on-file setups accumulate a specific kind of rot: addresses that no longer match, expired cards, and tokenized credentials that were never linked to a properly authenticated initial transaction. Each of these quietly raises challenge and decline rates on renewals, and the failure is usually attributed to “involuntary churn” rather than to the authentication setup that caused it.
Rolling 3DS2 out selectively instead of everywhere at once
The right way to deploy 3DS2 outside of markets where it is mandatory is as a targeted risk tool. You are not choosing between “on” and “off” at the site level. You are deciding, per transaction, whether the liability transfer is worth the friction, and that answer is different for a returning customer buying a 25 USD refill than for a first-time buyer shipping a 900 USD order to a freight forwarder.
A staged rollout that produces usable evidence
- Instrument first. Add authentication as a tracked funnel stage before changing anything, and hold a clean baseline for at least two to four weeks.
- Start with the riskiest slice. Enable 3DS2 on the segment with the worst fraud rate: high value, first-time customers, mismatched shipping, or a specific geography. Friction hurts least where fraud is highest.
- Audit the payload. Before widening, confirm your authentication requests carry the full field set. Doing this after a broad rollout means measuring an unnecessarily bad challenge rate.
- Widen by cohort, not all at once. Add one segment at a time and hold each for long enough that dispute data, which lags by weeks, can catch up.
- Layer exemptions deliberately. Once the base is stable, apply low-value and TRA exemptions to the segments where retained liability is cheap, and measure the conversion gain against the fraud cost.
- Review quarterly. Issuer behavior, network rules and your own fraud mix all move. A rule set that was optimal last year is unlikely to be optimal now.
Governance, or who owns the switch
3DS2 configuration tends to fall between teams. Payments owns the provider relationship, fraud owns the risk rules, engineering owns the checkout, and growth owns the conversion metric that all three affect. Without one named owner, rules get added and never removed, and nobody can explain why a given segment is challenged.
The practical fix is a single documented rule set with a stated rationale per rule, reviewed on a fixed cadence, with authentication metrics reported in the same place as conversion metrics. When the two are on the same dashboard, the trade-off becomes an explicit decision rather than an accident. For the wider control framework these rules sit inside, our payment fraud prevention guide covers how authentication, screening and dispute handling reinforce each other.
Information, not legal or compliance advice
This article is general information about how 3-D Secure 2 works and how merchants commonly approach it. It is not legal, regulatory, tax or compliance advice, and it does not tell you what your business is required to do in your specific circumstances. Payment authentication requirements depend on where you are established, where your customers are, which card networks and acquirers you work with, and which regulatory regime applies to each transaction.
Rules change, and some of them change frequently. Exemption thresholds, strong customer authentication requirements and network liability rules are set by regulators and card networks, and the figures and conditions described here can be amended. Verify current requirements directly with primary sources: the European Banking Authority and the European Commission for the EEA, the Financial Conduct Authority for the United Kingdom, and the published operating regulations of Visa, Mastercard, American Express and Discover for network rules.
For decisions with legal or financial consequence, consult a qualified payments compliance specialist, a regulatory attorney or your acquiring bank, all of whom can assess your actual setup. Nothing here should be treated as a substitute for that advice or as an assurance that a particular configuration is compliant in your market.
FAQ on 3-D Secure 2
Does 3-D Secure 2 hurt conversion rates?
Only on the portion of traffic that gets challenged. Frictionless authentications are invisible to the shopper and have no measurable conversion cost. The impact comes from challenged transactions, where a share of shoppers abandon rather than complete the step, so the real question is what percentage of your traffic is challenged and how well those challenges render on your customers’ devices.
What percentage of 3DS2 transactions are frictionless?
It varies widely by issuer, country, card brand and the quality of data in your authentication request. Merchants sending complete payloads to well-configured issuers commonly see the large majority resolve frictionless, while sparse integrations see far more challenges. Measure your own rate by segment rather than relying on a benchmark, because the spread across markets is very large.
Is 3-D Secure 2 mandatory?
It depends on your market. In the European Economic Area and the United Kingdom, strong customer authentication is a regulatory requirement for most in-scope electronic payments, and 3DS2 is the standard way card transactions meet it. In the United States there is no equivalent mandate and 3DS2 is optional. Confirm the requirements for your specific markets with your acquirer or the relevant regulator.
Does the liability shift cover all chargebacks?
No. It generally covers fraud-category disputes where the cardholder claims the transaction was unauthorized. Disputes about the goods or the service, including item not received, item not as described, duplicate charges and cancelled subscriptions, remain merchant liability regardless of authentication. The exact reason codes covered are defined by each card network and can be revised.
Can I turn 3DS2 on for only some transactions?
Yes, and outside mandated markets that is usually the right approach. Most payment providers let you set rules by order value, customer history, geography, device or your own risk score, so you can request authentication where fraud risk justifies the friction and let low-risk transactions run without it.
What happens if the issuer is unavailable during authentication?
The network’s attempts server can typically return a proof-of-attempt result, indicating the merchant tried to authenticate even though the issuer could not respond. Whether an attempted authentication carries the liability shift varies by network and region, so check the current position with your acquirer rather than assuming it does.
Do subscriptions and recurring charges need 3DS2 every time?
Usually not. Merchant-initiated transactions such as subscription renewals are generally out of scope for strong customer authentication, provided the initial transaction that established the mandate was properly authenticated and correctly flagged. This is why getting the first transaction right matters so much for subscription businesses.
Why do my mobile challenge completion rates lag desktop?
Almost always for technical reasons rather than shopper reluctance. Common causes are an iframe sized too small for the issuer’s challenge screen, content security policy headers blocking the issuer domain, cookie restrictions in mobile browsers, and single-page app navigation that destroys the challenge container. Test on real devices across your highest-volume issuing banks.
Does using an exemption still give me the liability shift?
Generally no. Merchant-requested exemptions such as low value and transaction risk analysis let a transaction skip the challenge, but liability for a subsequent fraud dispute typically stays with the merchant. That trade-off is the core of exemption strategy: you are buying conversion by accepting risk, so it only makes sense where your fraud rate on that segment is genuinely low.