3-D Secure is never just a conversion test

A 3-D Secure test does not compare a fast checkout with a slower version of the same checkout. It changes who assesses the transaction, what evidence reaches the issuer, whether the cardholder is challenged, how an exemption is handled and, in some cases, who absorbs a fraud dispute. EMV 3DS is a pre-authorisation exchange among the merchant side, the card network and the issuer; it can end frictionlessly or require the issuer to interact with the cardholder.123

That makes “conversion” an incomplete verdict. A higher immediate completion rate can coexist with more fraud exposure or less dispute protection. A lower checkout rate can coexist with fewer fraudulent orders or better issuer confidence. The result is not interpretable until the test also measures frictionless and challenge outcomes, authorisation, fraud, liability eligibility, exemption treatment and issuer behaviour.

Authentication is not authorisation

The first measurement error is to stop at “3DS successful.” Authentication establishes confidence that the person using the credential is the cardholder. Authorisation is the issuer’s later decision about whether the payment may proceed, considering matters such as account status, available funds and risk signals.3 A cardholder can complete a challenge and still receive an authorisation decline.

The reverse path matters too. An initial authorisation may be soft-declined because authentication is required, causing the payment to enter 3DS and then be attempted again. Public processor documentation identifies authentication_required as an issuer decline that can trigger this flow.4 Counting the first decline as a lost payment, or the second request as a new customer attempt, corrupts the comparison.

The unit of analysis should therefore be the commercial payment attempt, not an API call. Correlate its initial request, authentication messages, any challenge, the final authorisation and the order outcome. Report at least two success rates: authentication success among 3DS attempts, and authorised orders among eligible checkout attempts. Neither can substitute for the other.

The issuer owns the decisive branch

A merchant can request or prefer a challenge, but the issuer’s Access Control Server (ACS) reviews the authentication request and decides whether further checks are needed. If it requests a challenge, the merchant side can continue with that challenge or terminate the authentication.5 “3DS on” is therefore not a single treatment. It is a request into another party’s risk engine.

That engine sees more than an amount and card number. EMVCo documents transaction, cardholder, merchant-relationship, device and browser information used in risk assessment. In browser flows, the 3DS Method can let the ACS collect device information before authentication; incomplete or inaccurate data can produce more challenges or authentication failures.6 A checkout change that alters field population, device-data collection or timing has changed the risk signal, not merely the user interface.

Aggregate results conceal this dependency. Two arms with identical merchant logic can receive different challenge rates because their issuer mix differs. Evaluate outcomes by issuer or card range where reporting and privacy constraints permit, as well as issuer country, device channel, amount band and new-versus-returning relationship. Those are diagnostic cuts, not invitations to search for a flattering segment: define them before reading the result.

Friction is a sequence of failure surfaces

“Challenged” is not the same as “customer saw a prompt,” and “challenge failed” is not the same as abandonment. The protocol can return frictionless success, a challenge request, an attempted authentication, rejection, inability to authenticate or an unavailable response.7 Once challenged, the ACS may use an embedded browser interaction, an app-based flow or an out-of-band step such as approval in a banking application.5

Instrument the boundaries. Record whether the 3DS Method was requested and completed; whether an authentication request received a response; whether the issuer requested a challenge; whether the challenge UI was presented; whether the cardholder completed it; and whether the result returned in time to continue payment. Public authentication analytics likewise separate authentication rate, challenge rate, authentication success and challenge success rather than compressing them into one number.8

This decomposition changes the remedy. A high challenge rate points toward issuer risk decisions or poor input data. A low presentation rate points toward integration or rendering. Presentation followed by abandonment points toward the challenge experience. Successful authentication followed by decline belongs to authorisation. A conversion chart alone assigns all four failures to “3DS friction” and makes each one harder to fix.

Liability and fraud change the denominator

3DS can change the economics of an accepted order even when checkout completion is unchanged. Visa’s public merchant guidance says correctly processed Visa Secure transactions can protect participating merchants from certain fraud-related disputes after successful authentication, and sometimes after an authentication attempt; it also warns that liability-shift rules vary by region and that program conditions apply.9 “Authenticated” is not a universal guarantee that every dispute has moved elsewhere.

Exemptions make the distinction sharper. Under the EU regulatory technical standards, low-value remote transactions may avoid strong customer authentication below €30, subject to cumulative value or transaction-count limits. The transaction-risk-analysis exemption is tied to real-time risk checks, payment value and the payment service provider’s rolling fraud rate; the reference thresholds for remote card payments become stricter as the exempted amount rises.10 The EBA further states that the payer’s payment service provider makes the ultimate decision whether to accept an exemption, apply SCA or decline.11

An exemption can remove a challenge without producing the same liability position as successful authentication. Public processor guidance explicitly notes that an approved SCA exemption does not carry fraud liability shift.12 A policy that maximises exemptions may improve the visible funnel while retaining more fraud loss. A policy that requests authentication more often may add challenges while changing dispute exposure. Comparing only authorised orders treats those positions as equivalent when they are not.

Fraud and disputes also arrive after the checkout dashboard has declared a winner. Preserve the original experiment assignment and authentication evidence through those later outcomes. Compare fraud by value and count, fraud-related disputes, preventable false declines and the share of disputed value that remained with the merchant side. Do not merge liability eligibility with realised recovery: the former is a rules-and-message property; the latter is an eventual financial outcome.

Exemptions are routing decisions, not a control group

It is tempting to label an exempted payment “3DS off.” EMVCo’s protocol model is more precise: the merchant side can signal a request for a low-value, transaction-risk-analysis, trust-list or secure-corporate exemption, while the ACS evaluates the request and may report which exemption it applied.6 An exempted flow can still use the 3DS messaging path and give the issuer data without presenting a challenge.

The control group must therefore be defined by actual treatment: no authentication request, frictionless authentication, issuer-applied exemption, merchant/acquirer-requested exemption, completed challenge, failed challenge, unavailable authentication or soft-decline recovery. Regulatory scope must be recorded separately. Where SCA is required, deliberately suppressing it is not a neutral conversion experiment; it invites an issuer decline and changes the compliance and liability conditions.1011

This also prevents selection bias. Low-risk traffic is more likely to qualify for frictionless handling or an exemption, while riskier traffic is more likely to be challenged. A raw comparison of frictionless and challenged orders mostly compares populations that the issuer already judged differently. Randomise only policies that are legally and operationally interchangeable, then analyse the issuer’s downstream branches as outcomes rather than self-selected experimental arms.

A decision needs a scorecard, not a winner

Start with one denominator: all checkout attempts eligible for the policy being tested. From it, build a joined funnel through 3DS initiation, issuer response, frictionless or exempted outcome, challenge presentation, challenge completion, authorisation and order completion. Keep retrying API requests attached to the same payment intent. Show issuer and device segments beside the aggregate.

Then add the delayed ledger: fraudulent transaction value, fraud-related dispute value, liability status and net accepted good orders. State the observation window, because a same-day conversion result and a later fraud result are not equally mature. Guardrails should include technical unavailability and the share of payments whose authentication result could not be matched to authorisation.

The final decision may be conditional. Request 3DS for one risk band, seek exemptions for another, improve the data sent to a cluster of issuers, or repair a challenge hand-off on a particular device channel. That is not a messy alternative to a clean conversion answer. It is the shape of the system being tested: several decision-makers, several failure surfaces and several kinds of loss.

3-D Secure should earn its place through better risk-adjusted payment outcomes, not through the prettiest single funnel. Conversion remains important. It is simply one line in the scorecard.

Sources

1. “EMV 3-D Secure.” (opens in a new tab) EMVCo.
2. “Improving Risk Analysis and Frictionless Flow: Business Overview.” (opens in a new tab) EMVCo.
3. “3D Secure: your guide to safer transactions.” (opens in a new tab) Visa.
4. “Stripe decline codes.” (opens in a new tab) Stripe Documentation.
5. “Challenge Flow: Technical Features.” (opens in a new tab) EMVCo.
6. “Improving Risk Analysis and Frictionless Flow: Technical Features.” (opens in a new tab) EMVCo.
7. “Raw 3D Secure responses.” (opens in a new tab) Adyen Docs.
8. “Authentication analytics.” (opens in a new tab) Stripe Documentation.
9. “Dispute Management Guidelines for Visa Merchants.” (opens in a new tab) Visa.
10. “Commission Delegated Regulation (EU) 2018/389.” (opens in a new tab) European Commission, EUR-Lex.
11. “EBA publishes Opinion on the implementation of the RTS on strong customer authentication and common and secure communication.” (opens in a new tab) European Banking Authority.
12. “Strong Customer Authentication exemptions.” (opens in a new tab) Stripe Documentation.