How CAVV Works
The CAVV is the final cryptographic output of a successful 3D Secure authentication session. It is produced by the issuing bank's Access Control Server (ACS) and travels back through the authentication chain to the merchant, who must then include it in the authorization request sent to the card network. Understanding this flow is critical for any payment team integrating 3DS or troubleshooting authentication failures.
Cardholder Initiates Checkout
Authentication Request Sent
Directory Server Routes to ACS
ACS Authenticates the Cardholder
ACS Generates the CAVV
CAVV Returned in Authentication Response
Merchant Passes CAVV in Authorization
Issuer Validates CAVV and Responds
Why CAVV Matters
CAVV is the technical foundation of the liability shift mechanism — one of the most consequential financial protections available to online merchants. Without a valid CAVV on file, a merchant processing a fraudulent card-not-present transaction has no legal or contractual basis to contest the resulting dispute. The downstream costs go far beyond the transaction value itself.
According to Visa's published 3D Secure data, merchants who authenticate transactions through 3DS experience up to a 40% reduction in fraud rates compared to unauthenticated card-not-present flows. EMVCo's 2023 industry report documented that global 3DS transaction volume surpassed 70 billion transactions, reflecting the scale at which CAVV-based authentication now operates. A separate Mastercard study found that 3DS2's frictionless authentication path — which still generates a valid CAVV — reduces unnecessary friction-induced cart abandonment by up to 70% compared to 3DS1, directly impacting conversion rates at scale.
The business case for ensuring CAVV completeness is therefore twofold: it protects against fraud-coded chargebacks through liability shift, and it enables smoother checkout flows that improve authorization approval rates.
Liability Shift Requires a Valid CAVV
CAVV vs. ECI
CAVV and ECI are generated together by the ACS and are always interpreted as a pair. Neither value alone is sufficient to determine the authentication outcome or the liability shift status of a transaction. Merchants and developers sometimes confuse the two, but they serve entirely different roles.
| Attribute | CAVV | ECI |
|---|---|---|
| Full name | Cardholder Authentication Verification Value | Electronic Commerce Indicator |
| Format | Base64-encoded string (~28 chars) | 2-digit numeric code |
| Generated by | Issuer's Access Control Server (ACS) | ACS or directory server |
| Purpose | Cryptographic proof of authentication | Classification of authentication outcome |
| Included in auth request | Yes — passed to issuer for validation | Yes — interpreted by acquirer and network |
| Triggers liability shift | Yes, when valid and paired with correct ECI | Yes, when paired with valid CAVV |
| Visible to merchant | Yes — stored and passed through PSP/gateway | Yes — returned in authentication response |
| Network-specific naming | CAVV (Visa), AAV (MC), AEVV (Amex) | Identical term across all networks |
| Fails silently if wrong | Issuer rejects or declines authorization | Incorrect ECI can negate liability shift |
Think of ECI as the label that classifies what happened during authentication (fully authenticated, attempted, not authenticated), and CAVV as the unforgeable stamp that proves that classification is legitimate.
Types of CAVV
CAVV values are not all equal. The authentication outcome — reflected in the ECI indicator — determines both the format of the CAVV and the degree of liability protection it confers. Three main variants exist across the Visa specification, with direct equivalents on Mastercard and other networks.
Fully Authenticated CAVV (ECI 05 / 02) Generated when the cardholder successfully completes all authentication steps, whether through a frictionless risk-based decision or an explicit challenge. This provides full liability shift for fraud-coded chargebacks. The ACS sets the authentication result code within the CAVV to indicate full success.
Attempted Authentication CAVV (ECI 06 / 01) Generated when the card is enrolled in 3DS but the issuer's ACS is unable to authenticate the cardholder — for example, the cardholder abandons the challenge or the ACS is temporarily unavailable. The network's attempt server generates a substitute CAVV. Partial liability shift applies: the merchant is protected against fraud disputes but not against all chargeback reason codes.
Non-Participating / No CAVV (ECI 07 / 00) No CAVV is generated when the card is not enrolled in 3D Secure or when authentication is bypassed (e.g., merchant-initiated transactions, recurring payments after initial authentication). No liability shift is available. Merchants should track which transaction segments fall into this category and assess their fraud exposure accordingly.
3DS2 Transaction Status Codes
Best Practices
Correctly handling CAVV data requires coordination across merchant operations, payment integrations, and backend infrastructure. Failures typically happen at the handoff points between authentication and authorization.
For Merchants
Always store the full authentication response. Retain the CAVV, ECI, XID/dsTransID, and transaction status from every authentication attempt. You will need these fields if a chargeback is disputed — card network rules require merchants to produce authentication evidence to invoke liability shift.
Never retry authorization without re-authenticating. If an authorization is declined and you retry, do not reuse the CAVV from the previous attempt. The cryptographic binding to the original transaction data makes the CAVV invalid for a new authorization request. A new 3DS session must be initiated.
Segment reporting by ECI value. Build dashboards that break out authorization approval rates and fraud rates by ECI code. This surfaces whether your 3DS integration is generating full-authentication (ECI 05/02) versus attempted-authentication (ECI 06/01) outcomes — a meaningful difference in liability protection and often in issuer approval rates.
Understand exemptions carefully. Transaction Risk Analysis (TRA) exemptions, low-value exemptions, and merchant-initiated transactions do not generate a CAVV. Ensure your payment team understands which transaction types carry no authentication value and therefore no liability shift.
For Developers
Pass all three authentication fields. Authorization requests must include the CAVV, ECI, and the 3DS transaction reference (XID for 3DS1, dsTransID for 3DS2) as a complete set. Omitting any one field may cause the issuer to ignore the authentication data and process the transaction without liability shift, even if authentication occurred.
Validate the ARes before proceeding. Parse the authentication response and check the transStatus field before extracting the CAVV. Only proceed to authorization if transStatus is Y or A. If transStatus is N (authentication failed) or R (rejected), do not attempt authorization with that card in the same session.
Handle SDK and 3DS server errors explicitly. Network timeouts or ACS unavailability produce a transStatus of U (unable to authenticate). Your integration should surface this state to the payment logic layer — not silently fall back to unauthenticated authorization — so the merchant can decide whether to apply an exemption or re-attempt.
Log raw authentication responses server-side. Never rely solely on client-side callbacks to capture CAVV data. Implement server-to-server notification handling (challenge results, ACS callbacks) so authentication values are persisted securely even if the cardholder's browser session is interrupted.
Common Mistakes
Passing a stale or mismatched CAVV. The CAVV is cryptographically bound to the transaction amount, currency, and date used during authentication. If any of these fields change between authentication and authorization — a common scenario when taxes or shipping are calculated after 3DS — the issuer's validation will fail. Always authenticate with the final confirmed transaction amount.
Conflating 3DS enrollment with successful authentication. A card being enrolled in 3D Secure does not guarantee a CAVV will be generated. If the cardholder abandons the challenge or the ACS returns an error, the authentication fails without a usable CAVV. Integrations that assume enrollment equals authentication will submit authorizations with missing or invalid authentication fields.
Ignoring CAVV handling for recurring transactions. Only the initial transaction in a recurring series requires 3DS authentication with a full CAVV. Subsequent merchant-initiated transactions use a different authorization flow with the original transaction reference. Attempting to run a new 3DS flow for each recurring charge — or omitting authentication data entirely — creates both compliance and liability exposure depending on the card network's rules.
Discarding the authentication response after authorization. Some integrations extract only the authorization approval code and discard the raw 3DS authentication data. When a fraud-coded chargeback arrives months later, the merchant cannot produce the CAVV and ECI evidence required to invoke liability shift. Store all authentication response data for the full dispute window (typically 120–540 days depending on network rules).
Applying 3DS exemptions without understanding the liability consequences. Low-value exemptions and TRA exemptions bypass 3DS authentication entirely, which means no CAVV is generated and no liability shift applies. Teams that liberally apply exemptions to reduce friction often see those exemptions create concentrated fraud exposure in exactly the transaction segments that are exempt.
CAVV and Tagada
Tagada's payment orchestration layer handles CAVV propagation transparently across the acquirer and processor connections it manages. When a merchant authenticates via 3DS through Tagada's routing infrastructure, the CAVV, ECI, and 3DS transaction reference are automatically forwarded in the authorization request to the downstream processor — no manual field mapping required.
Authentication Data Across Routes
Tagada also surfaces authentication outcome breakdowns in its reporting dashboard, segmented by ECI code and processor. This allows payment teams to identify whether specific acquirer routes are producing lower rates of fully-authenticated (ECI 05/02) outcomes versus attempted (ECI 06/01), which can signal configuration issues in the 3DS server or ACS connectivity problems that erode liability-shift coverage over time.