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

EMV 3DS2 adds authentication evidence to an online payment. Its operational cost is the work and customer interaction involved in obtaining that evidence: issuer challenges, failed returns to checkout, integration maintenance and the decisions needed when authentication fails. Measure those costs alongside fraud protection and authorisation outcomes rather than assuming one universal conversion penalty.

How EMV 3DS Actually Works

The issuer's Access Control Server (ACS) assesses transaction and device information supplied through the integration. It can authenticate without an additional cardholder challenge, request a challenge, or return another outcome such as failure or inability to authenticate. Populate accurate supported fields; a fixed data-element count is not a performance target.

A frictionless flow avoids an additional challenge. It does not guarantee a particular latency, approval rate or absence of abandonment. A challenge can use methods such as a one-time passcode or banking-app interaction. Segment completion and recovery by issuer, device and market before changing policy. EMVCo's deployment guidance explains the flow distinction without establishing a universal completion rate.

Eligible authentication can shift liability for specified fraud disputes under the applicable programme; it does not resolve goods/services disputes or guarantee payment authorisation. Stripe's implementation guidance describes exceptions after successful authentication and distinguishes exemption requests from authentication protection. Retain the actual outcome and authentication evidence passed with the payment. Visa's particular response combinations require a more detailed assessment below.

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 challenge decisions using their risk assessment and applicable requirements. A merchant's aggregate fraud performance alone does not determine the result for every issuer or transaction.

For transactions within PSD2/SCA scope, the regulatory technical standards provide conditional exemptions. Low-value remote payments have transaction and cumulative limits. TRA depends on the PSP's fraud-rate bands, monitoring and transaction amount; a single merchant fraud rate does not establish eligibility up to the maximum band. Creating or amending a trusted-beneficiary list requires SCA. An exemption request can still lead to an issuer challenge.

Measure accepted exemption requests separately from successful frictionless authentications: avoiding a challenge does not imply the same liability outcome. See SCA Exemption Strategy: The Operator Playbook for the exemption indicators and detailed eligibility mechanics.

Measuring the Conversion Cost

Use a funnel connecting payment attempts, authentication requests, challenge requests, completions, authorisations and completed orders. Report timeouts and abandoned returns separately. Compare similar issuer, device and risk cohorts; a challenged cohort can have a different risk mix from a frictionless cohort, so the raw conversion gap is not automatically caused by the challenge.

Illustrative arithmetic, not a benchmark: if 5% of 100,000 payment attempts require a challenge and 70% of those complete, 1,500 attempts do not complete that challenge. This does not establish 1,500 lost orders: some customers retry or use another payment method. Link eventual orders to attempts before estimating revenue loss.

Include operational work in the assessment: integration maintenance, evidence retention, authentication monitoring and recovery paths. Avoid attributing an observed checkout drop to an ACS change without the response logs and provider evidence needed to distinguish it from authorisation or front-end failures.

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 means sending accurate, supported transaction and device information. Test completeness and field validity with your provider, then measure outcomes. More populated fields do not by themselves prove better performance, and provider size does not establish a lower challenge rate.

Exemption management requires transaction-level eligibility and issuer acceptance. Monitor requested and accepted exemptions alongside fraud and liability outcomes. Do not group every subsequent recurring payment under one exemption: mandate setup, merchant initiation and amendments can have different treatment.

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 should support the methods offered by the issuer, preserve return-to-checkout state and handle cancellation and timeout clearly. Test mobile app switching, browser redirects and recovery. Claim a completion improvement only when measured against comparable cohorts.

Treat authentication as an operating policy: specify the evidence required, the recovery path for each outcome and the measurements that would justify changing it. A higher frictionless rate is useful only in the context of completed orders, fraud outcomes and the protection actually obtained.