3DS2 and the Authentication Tax: What Operators Are Actually Paying

3D Secure 2 was supposed to solve the authentication problem that plagued its predecessor — the full-page redirect, the forgotten passwords, the 15-20% abandonment rates that made 3DS1 a byword for checkout friction. And EMV 3DS2 has delivered on that promise in frictionless flow scenarios. But as issuer adoption has deepened and challenge thresholds have tightened in response to fraud pressure, a new problem has emerged: the authentication tax. For merchants and payment operators, understanding exactly what you're paying — in conversion loss, in declined revenue, in operational overhead — is prerequisite to building a policy that doesn't leave money on the table.

How EMV 3DS Actually Works

The architectural difference between 3DS1 and 3DS2 is the data layer. EMV 3DS passes up to 150 data elements to the issuer's Access Control Server (ACS) during the authentication request — device fingerprint, billing/shipping address match, browser characteristics, transaction history with the merchant, account age, behavioral signals from the cardholder's session. The issuer's ACS processes these elements through its risk model and makes a binary decision: approve frictionlessly (frictionless flow) or require the cardholder to complete a challenge (challenge flow).

In the frictionless flow, the cardholder sees nothing. Authentication happens in the background in under 100ms. The issuer issues an Authentication Value (AV), the merchant receives a liability shift for fraud chargebacks, and the transaction proceeds. This is the happy path — and for low-risk transactions at merchants with strong 3DS2 data quality, frictionless rates of 85-95% are achievable.

The challenge flow is where friction enters. Challenges are most commonly delivered as OTP (one-time password via SMS), biometric (on mobile banking apps), or in-app push notification. Challenge completion rates vary significantly by geography and demographic: European markets with mature banking app ecosystems see challenge completion rates of 75-85%. Markets with high SMS reliance and older banking infrastructure see rates as low as 55-65%. Every challenge that doesn't complete is a transaction that fails — and for many merchants, the challenge completion rate is the single most important lever on their 3DS2 conversion performance.

The liability shift mechanics are worth spelling out precisely. When 3DS2 authentication is completed (frictionless or challenge), fraud chargeback liability shifts to the issuer. When 3DS2 is attempted but the issuer's ACS times out or returns an error, the liability outcome is not automatic — under Visa's rules, protection turns on which response type the failure actually produces and whether it carries a Cardholder Authentication Verification Value (CAVV), not on the fact that a timeout occurred (see below). When 3DS2 is not attempted (the merchant bypasses authentication), liability remains with the merchant. This creates a meaningful policy question: for high-value transactions where issuer challenge rates are high, does the liability shift justify the conversion cost of the challenge?

What Happens When Visa Secure Can't Authenticate the Cardholder

This section describes Visa's own Visa Secure program rules for EMV 3DS specifically, as set out in the Visa Core Rules and Visa Product and Service Rules (April 2026 edition). It makes no claim about Mastercard Identity Check, which runs its own separate liability framework, or about EMVCo protocol internals beyond what Visa's rules text states. It's also scoped within Visa's own fraud dispute framework: Visa's Category 10 fraud dispute conditions run from 10.1 through 10.5, and everything below is about Dispute Condition 10.4, Visa's card-absent-environment fraud dispute, specifically — not about 10.1 or 10.2 (EMV's card-present liability shift) or any other condition in that range.

Visa defines four possible Authentication Responses to an Authentication Request: Attempt Responses, Authentication Confirmations, Authentication Denials, and Unable-to-Authenticate Responses. An Authentication Denial is the issuer affirmatively refusing to authenticate the cardholder. An Unable-to-Authenticate Response is a different thing — Visa's glossary defines it as a message indicating the issuer "is unable to authenticate the Cardholder for reasons other than those that result in an Authentication Denial." It is a non-answer, not a refusal, and the rules restrict when an issuer is allowed to send one.

Under section 10.15.2.4, an issuer may respond with an Unable-to-Authenticate Response only under one or more of three conditions: the issuer "experiences technical problems that prevent a timely response", the authentication data the merchant sent doesn't comply with the 3-D Secure specification, or the transaction was attempted with a non-reloadable prepaid card. That first condition is what an ACS timeout actually is under Visa's rules — a defined, permitted trigger for a specific response type, not an automatic liability outcome by itself.

There's a separate scenario: an issuer that doesn't participate in Visa Secure at all. Section 10.15.2.3 covers that case directly. For an EMV 3DS Authentication Request, if an issuer does not support Visa Secure, Visa itself responds on the issuer's behalf with an Attempt Response that contains a Cardholder Authentication Verification Value (CAVV). US-Region issuers are required to give Visa their CAVV keys specifically so Visa can stand in this way. The same section adds a detail that matters for what follows: an issuer must verify the CAVV, but Visa's own text states, "If the CAVV is not verified during Authorization by the Issuer or by Visa, the CAVV is assumed to be valid."

That CAVV is what Dispute Condition 10.4 protection actually turns on — not whether the cardholder completed a challenge. Under Dispute Condition 10.4, Visa's card-absent-environment fraud dispute, section 11.7.5.3 lists the invalid-dispute conditions: cases where an issuer's 10.4 dispute doesn't stand. Two of them turn on Visa Secure response types. The first is intuitive: a Secure Electronic Commerce Transaction carrying Electronic Commerce Indicator (ECI) 5 is protected — the 10.4 dispute is invalid — if the issuer responded to the Authentication Request with an Authentication Confirmation using Visa Secure with EMV 3DS, and the CAVV was included in the authorization request. The second is the counterintuitive one. Visa's rules label it a Non-Authenticated Security Transaction: an ECI 6 transaction is also protected if a CAVV was included in the authorization request and the issuer — or Visa, standing in for the issuer — responded to the Authentication Request with an Attempt Response that itself included a CAVV, provided the transaction is not a non-reloadable prepaid card transaction. An Attempt Response, by Visa's own glossary definition, is a message indicating "the Issuer or Cardholder is not participating in Visa Secure." The cardholder never completed an authentication in this scenario at all. The transaction still carries Dispute Condition 10.4 protection, because the attempt produced a CAVV.

The reverse holds too, and it's the part the earlier version of this article got wrong. Section 5.8.4.4 does impose a CAVV condition on ECI 5 and 6 in the clearing record: an acquirer may use ECI 5 there only if the CAVV was included in the authorization request, and may use ECI 6 there only insofar as that same condition was met by a CAVV the issuer or Visa actually provided. But that clearing-record rule isn't what carries the no-protection conclusion here — section 11.7.5.3's two protected combinations each impose their own CAVV-in-the-authorization-request requirement, on their own terms. The ECI 5 combination requires an Authentication Confirmation and a CAVV in the authorization request; the ECI 6 combination requires a CAVV in the authorization request and an Attempt Response that itself included a CAVV. Without a CAVV in the authorization request, neither combination is satisfied — regardless of what ECI value ends up in clearing. An Unable-to-Authenticate Response isn't one of the response types 11.7.5.3 protects. And on the CAVV itself: Visa's rules require a CAVV only in Authentication Confirmations and Attempt Responses under 10.15.2.3; they do not provide for one in an Unable-to-Authenticate Response — reading that absence as exclusion is PaymentBrief's inference, not a stated Visa rule. So a timeout that produces an Unable-to-Authenticate Response, without a CAVV in the authorization request, satisfies neither of 11.7.5.3's protected combinations. The liability outcome depends on which of the four response types actually came back and whether a CAVV was present — not on whether an authentication attempt was made, and not on the fact that the ACS failed to respond.

There's also a trap built into the CAVV mechanic. Table 11-153 treats reuse of a previously validated CAVV or TAVV on a later ECI 5 transaction — one carrying different authorization data, such as a different date or amount — as its own compliance condition, where the cardholder claims that later transaction is fraudulent. Reuse creates the acquirer's own exposure through the Compliance process rather than through Dispute Condition 10.4: a CAVV that validated one transaction does not extend protection to a second transaction with different data.

None of the paragraphs above say to log anything — that operator translation is PaymentBrief's own reading, not Visa's. What it implies for monitoring: the field worth capturing per transaction isn't a simple attempted/not-attempted flag or an ACS success/timeout status. It's which of the four Authentication Response types actually came back, whether a CAVV was present in the authorization request, and which ECI value was actually submitted at clearing. A dashboard built around attempt/no-attempt or success/timeout isn't recording the fields Visa's own dispute-condition table checks. An ACS timeout describes what happened at the network layer; on its own it doesn't say whether Dispute Condition 10.4 applies to that transaction, because the rule doesn't test for a timeout — it tests for a response type, an ECI, and a CAVV.

The Issuer Threshold Problem

Issuers control their own challenge thresholds, and those thresholds vary enormously — not just across issuers, but across transaction types, time windows, and fraud pressure periods. This is the central tension in 3DS2 economics. A merchant may have excellent fraud performance, rich 3DS2 data quality, and a mature risk model — and still see a 20% challenge rate from a specific issuer that has simply set aggressive thresholds in response to portfolio-level fraud.

Issuers set challenge thresholds based on several factors: their authorization fraud rates (target is typically under 10 basis points for card-not-present), regulatory requirements (PSD2's Strong Customer Authentication mandate in Europe requires step-up for transactions above €30 except under specific exemptions), portfolio-level fraud pressure from specific merchant categories, and their own risk appetite.

The PSD2 SCA exemption landscape is particularly important for European operators. Transactions under €30 can be processed without SCA under the low-value exemption (though issuers can override this). Merchants with fraud rates below 0.13% can apply for transaction risk analysis (TRA) exemptions for transactions up to €500. Trusted beneficiary whitelisting allows cardholders to register merchants for SCA-free payments after an initial authenticated transaction. These exemptions significantly affect the realized challenge rate for sophisticated operators — merchants actively managing SCA exemptions routinely achieve frictionless rates 15-20 percentage points higher than those passively processing transactions. For the operational mechanics — how an exemption is actually carried in the authorization message, why issuers reject qualifying requests anyway, and the precise TRA fraud-rate bands — see SCA Exemption Strategy: The Operator Playbook.

Measuring the Conversion Cost

Stripe has published analysis suggesting that 3DS2 challenge flows reduce checkout conversion by 3-8% relative to frictionless transactions — the range reflecting the variance in challenge completion rates by geography and channel. Internal data from large payment processors is broadly consistent with this range: a well-implemented 3DS2 integration with active exemption management and optimized challenge UX typically sees 3-4% conversion impact from challenges; a poorly optimized integration in challenge-heavy markets can lose 8-12%.

For a merchant processing $100M annually in card-not-present volume, a 5% challenge rate with a 70% completion rate means 1.5% of transactions fail at authentication. At an average order value of $80, that's roughly $1.875M in annual abandoned revenue — before accounting for the re-engagement cost of cart abandonment emails and the customer experience damage.

The operational costs are less visible but real. 3DS2 technical implementation requires maintaining SDK integrations (Stripe, Adyen, and Braintree all have proprietary 3DS2 SDKs that require ongoing maintenance), monitoring authentication analytics to detect ACS performance degradation, and managing exemption logic in the payment request flow. Issuers occasionally deprecate ACS versions with minimal notice, creating authentication failures that look like unexplained conversion drops until identified.

The fraud-conversion tradeoff is also not linear. Authentication typically blocks 40-60% of card-not-present fraud, but the fraudulent transactions that do get through post-3DS2 are systematically harder to detect — fraudsters who clear authentication have either compromised the cardholder's authentication device (SIM swap, device takeover) or are using synthetic identities that pass the issuer's risk model. Post-auth fraud requires different detection approaches than traditional card testing.

When to Push Back on Issuers and How to Tune Your Integration

Merchants and operators have more leverage over their 3DS2 challenge rates than many realize. The mechanisms are underused, particularly in the US market where SCA mandates don't apply and the exemption toolkit is less developed than in Europe.

Data quality investment is the highest-ROI lever. The ACS risk model is only as good as the data it receives. Merchants sending minimal 3DS2 fields (the technical minimum is just a handful of elements) will see significantly higher challenge rates than those sending the full 150-element payload. Shipping address, account creation date, transaction history, and device fingerprint data are particularly high-signal. PSPs like Adyen and Stripe automatically populate many fields from their network data, which is one reason their challenge rates are often lower than those of smaller acquirers using the same underlying networks.

Exemption management requires active policy decisions. The request flow should apply SCA exemptions where the transaction qualifies and the merchant's fraud rate supports it. Low-value exemptions, TRA exemptions, and recurring transaction exemptions all have different risk profiles and need to be monitored against chargeback outcomes to verify the exemption is earning its conversion recovery.

Issuer engagement is a realistic option for large merchants. Issuers update their ACS configurations regularly, and a merchant with clean fraud data can often work through their acquirer or directly with major issuers to have specific BINs reviewed. If a particular issuer's BINs are driving disproportionate challenge rates at a merchant with below-average fraud rates, that's a quantifiable business case for a configuration review.

Challenge UX optimization matters more than most operators acknowledge. For mobile transactions, native in-app authentication (biometric or push) dramatically outperforms SMS OTP on completion rate. Working with issuers to enable app-based challenges for mobile flows, and ensuring the redirect experience for web-based challenges is smooth and branded, can recover 5-10 percentage points of challenge completion rate.

As issuers invest further in behavioral biometrics and passive authentication signals, the frictionless rate ceiling will rise — Visa and Mastercard both have network-level initiatives to improve authentication accuracy using tokenization and device intelligence data that issuers can incorporate into their ACS models. The operators who win in this environment will be those who treat authentication as an active optimization surface rather than a compliance checkbox.