The Electronic Commerce Indicator (ECI) is a two-digit numeric value that encodes the outcome of a 3-D Secure authentication exchange. It travels alongside the transaction from the merchant's payment system through to the card network and issuing bank, acting as the authoritative signal for liability assignment and risk scoring during dispute resolution.
Understanding ECI is non-negotiable for any merchant or developer handling online card payments. An incorrect or missing code can void liability-shift protection, inflate decline rates, and leave the business exposed to fraud-related chargebacks even when authentication infrastructure was correctly deployed and functioning.
How ECI (Electronic Commerce Indicator) Works
The ECI code is produced at the end of the 3DS authentication flow and must be submitted as part of the subsequent authorization request. The sequence is deterministic: authentication happens first, ECI is assigned based on the outcome, and that code travels to the issuer embedded in the authorization message alongside the CAVV.
Cardholder initiates checkout
The shopper enters card details on the merchant's checkout page. The merchant's 3DS requestor — typically the payment gateway or an embedded SDK — prepares an authentication request and sends it to the card network's 3DS server along with device fingerprint and contextual risk data.
3DS Server routes to the issuer's ACS
The card network's 3DS server forwards the authentication request to the issuer's Access Control Server (ACS). The ACS evaluates risk signals and decides whether to approve frictionlessly or step up the cardholder with a challenge such as an OTP or biometric prompt.
Issuer returns authentication result
After challenge completion or frictionless approval, the ACS returns an Authentication Response message containing a standardized authentication status: fully authenticated, attempted (ACS or cardholder did not complete the flow), or failed/unavailable.
ECI code is assigned
The 3DS server or payment system maps the authentication status to the correct ECI code based on card network rules. Visa uses 05 (full), 06 (attempted), 07 (not authenticated). Mastercard uses 02, 01, 00 respectively. American Express mirrors the Visa convention.
CAVV and ECI submitted to acquirer
The merchant's system bundles the ECI value with the CAVV and the 3DS transaction ID, then submits all three in the authorization request to the acquiring bank. A missing ECI or CAVV typically voids liability-shift protection even if authentication genuinely occurred.
Issuer evaluates ECI for liability and approval
The issuing bank reads the ECI code to determine who bears fraud liability and may use it as an approval signal. A high-assurance ECI (05 or 02) often improves approval rates because the issuer has cryptographic proof the cardholder was verified, reducing its own exposure on the transaction.
Why ECI (Electronic Commerce Indicator) Matters
ECI is not a technical formality — it is the contractual mechanism by which card networks transfer financial risk between merchants and issuers. Without a correct ECI, merchants processing card-not-present transactions absorb the full cost of fraud at dispute time, regardless of how robust their fraud stack is.
The stakes are material. Card-not-present fraud accounts for roughly 75% of total payment card fraud in mature markets, according to data compiled by the European Central Bank and UK Finance in their annual fraud reports. Merchants that implement 3DS correctly and consistently pass valid ECI codes see fraud-related chargeback rates decline by as much as 80%, based on scheme-level reporting from Visa's global merchant risk programs. A third data point underlines the cost of inaction: industry analysis consistently shows that for every $1 of fraud absorbed, merchants incur approximately $3.75 in total losses when accounting for merchandise cost, processing fees, operational dispute handling, and reputational impact — making liability-shift via correct ECI handling one of the highest-ROI security controls available to online merchants.
Liability shift is conditional
Passing ECI 05 or 02 shifts liability to the issuer only for fraud-related chargebacks — specifically, "cardholder did not authorize" disputes. Chargebacks based on "item not received" or "item not as described" are never covered by the 3DS liability shift, regardless of ECI value.
ECI (Electronic Commerce Indicator) vs. CAVV
ECI and CAVV are frequently conflated because they are generated in the same authentication flow and submitted together in the authorization request. They are, however, fundamentally different artifacts that serve distinct functions in the liability framework.
| Attribute | ECI | CAVV |
|---|---|---|
| What it is | 2-digit numeric outcome code | Cryptographic authentication token |
| Generated by | 3DS server via network mapping | Issuer's Access Control Server (ACS) |
| Purpose | Signals authentication level and liability routing | Cryptographically proves authentication occurred |
| Format | 2 digits (e.g., "05", "06") | Base64-encoded string (~28 characters) |
| Required for liability shift | Yes | Yes — must accompany ECI |
| Meaningful in isolation | Partially — shows auth level claimed | No — unverifiable without matching ECI |
| Verifiable by issuer | Yes, via card network rule mapping | Yes, via ACS cryptographic validation |
Think of ECI as the label and CAVV as the proof. A fabricated or mismatched label — ECI without a valid corresponding CAVV — will fail issuer-side cryptographic validation and may trigger a network investigation for rule violations.
Types of ECI (Electronic Commerce Indicator)
ECI values are defined per card network and the numeric codes are not universal across schemes. The following covers the three major global networks. Developers must implement per-network mapping logic rather than a single universal value.
Visa and American Express
- ECI 05 — Full authentication. The cardholder was successfully authenticated by the issuer, either via a challenge or frictionlessly. Full liability shift applies to fraud-related chargebacks.
- ECI 06 — Attempted authentication. The merchant invoked 3DS but the issuer or card was not fully enrolled, or the ACS timed out. Partial liability shift applies in most regions, though coverage is narrower than ECI 05.
- ECI 07 — No authentication. 3DS was not invoked, was unavailable, or authentication was not possible. No liability shift; the merchant bears full fraud risk.
Mastercard
- ECI 02 — Full authentication. Functionally equivalent to Visa ECI 05.
- ECI 01 — Attempted authentication. Functionally equivalent to Visa ECI 06.
- ECI 00 — No authentication. Functionally equivalent to Visa ECI 07.
3DS 2.x frictionless and ECI
3DS 2.x (EMV 3DS) introduced frictionless authentication, where ECI 05 or 02 can be returned without a consumer-facing challenge step. The ECI value itself is identical to the challenged flow — the change is in how the authentication decision is reached internally, not how the outcome is reported downstream.
Best Practices
Correct ECI handling requires discipline at both the integration and operational levels. Errors are common, silent, and expensive — they often only surface when a chargeback dispute is lost.
For Merchants
Verify that your payment gateway or 3DS provider correctly maps authentication outcomes to ECI codes for every card network you accept. Do not assume a single ECI value covers all schemes. Visa and Mastercard mappings are different and must be handled independently in your authorization flow.
Always confirm that your acquirer is receiving the ECI value populated in the authorization request. Request transaction detail reports and audit a sample of 3DS-authenticated transactions to verify that ECI and CAVV fields are non-empty. If they are blank, a fraud-prevention control you believe is active may be silently failing.
Store ECI values alongside transaction records and retain them for a minimum of 18 months. In the event of a chargeback dispute, ECI and CAVV are the primary evidence that authentication occurred. Inability to produce these values during representment typically results in an automatic loss regardless of the underlying authentication outcome.
Review your 3DS fallback logic carefully. If 3DS is unavailable, your system may default silently to ECI 07. Confirm this is an intentional business decision and that compensating controls — velocity limits, AVS checks, CVV validation — are active to manage the elevated fraud exposure.
For Developers
Implement ECI mapping as a network-aware function. Never hardcode a single ECI value across card brands. The mapping function should accept the card network identifier and the authentication status as inputs and deterministically return the correct ECI code for that combination.
Validate that ECI and CAVV fields are non-null before constructing any authorization message for a 3DS-attempted transaction. A null ECI on an authenticated transaction is a silent failure mode: the transaction will process and appear successful, but without liability-shift protection — a discrepancy that only becomes apparent during a dispute weeks or months later.
Log authentication responses in full, including raw ACS messages and 3DS server responses, so that ECI generation can be audited and debugged without relying on downstream system logs. This is particularly critical when investigating disputed transactions where the authentication state may be contested.
Test ECI handling explicitly using card numbers for each supported network in sandbox environments. Validate the ECI 05/02, 06/01, and 07/00 code paths independently, and confirm all three are correctly forwarded in authorization request fields — not just generated internally.
Common Mistakes
1. Assuming ECI values are universal across card networks. Developers frequently apply Visa's ECI 05 to Mastercard transactions. Card networks validate ECI against known per-network values; mismatches can cause soft declines or silent liability-shift failures that are invisible until a dispute is filed.
2. Submitting ECI without CAVV. Some integrations pass ECI in the authorization request but omit or truncate the CAVV field. The issuer receives a code indicating authentication occurred but cannot verify it cryptographically. The liability-shift claim will be rejected if the transaction is disputed, regardless of ECI value.
3. Not updating ECI handling after a 3DS version migration. Merchants who migrate from 3DS 1.0 to 3DS 2.x sometimes carry forward legacy field mappings that no longer align with EMV 3DS message structures. Authentication status values and field positions changed between versions — always re-audit and regression-test ECI mapping after any 3DS library or version upgrade.
4. Treating ECI 06 or 01 as equivalent to full authentication. Attempted authentication provides some liability-shift protection, but the coverage is narrower. In regions operating under PSD2 Strong Customer Authentication requirements, ECI 06 alone does not satisfy SCA obligations, and issuers may decline the transaction outright or reject a liability-shift claim during dispute resolution.
5. Failing to log and retain ECI values at the transaction level. Merchants that do not persist ECI at the individual transaction record cannot produce evidence during chargeback representment. Card network rules place the burden of proof on the merchant — without logged ECI and CAVV values, even a genuinely authenticated transaction will lose the dispute.
ECI (Electronic Commerce Indicator) and Tagada
For merchants operating across multiple acquirers or processors, consistent ECI handling becomes a cross-system orchestration problem. Different processors expose different field names, message formats, and validation rules — creating risk of ECI being dropped or misrouted at the acquirer boundary.
Tagada's payment orchestration layer normalizes ECI and CAVV handling across all connected processors and card networks. When routing a 3DS-authenticated transaction through Tagada, the ECI value and CAVV generated by your 3DS provider are automatically mapped to the correct authorization fields for the target acquirer — regardless of which network or processor handles the transaction. You can audit ECI population per transaction in the Tagada dashboard and configure alerting rules for transactions where ECI or CAVV fields are unexpectedly empty, giving you real-time visibility into liability-shift coverage across your full payment volume without building per-acquirer integration logic in-house.