Paste the ECI your gateway returned and pick the card scheme. You get the outcome it stands for, whether anyone actually authenticated the cardholder, and whether fraud liability moved. Single letters are read as a 3-D Secure transStatus instead.
A two-digit code in the authorization message that says what happened at the authentication step: the cardholder was authenticated, authentication was attempted but could not be completed, or none happened.
It matters because it is the field a dispute is judged on. Not the 3-D Secure response your checkout saw — the ECI that arrived with the authorization.
Both schemes report the same three things. The cardholder was authenticated. Authentication was attempted but the issuer could not finish it. Nothing was authenticated. What differs is the digits, and they run opposite ways: Visa numbers the outcomes 05, 06, 07 from best to worst, and Mastercard numbers them 02, 01, 00 from best to worst. Higher is worse for one and better for the other.
| Outcome | Visa | Mastercard | Fraud liability |
|---|---|---|---|
| Cardholder authenticated | 05 | 02 | Moves to the issuer |
| Authentication attempted, not completed | 06 | 01 | Moves to the issuer |
| No authentication | 07 | 00 | Stays with the merchant |
This is why a gateway that flattens both schemes into one eci field produces bugs that only show up for half your traffic. A rule written as “treat 05 as authenticated” is correct for Visa and silently wrong for every Mastercard transaction, where 05 is not a value at all.
One more source of confusion: Mastercard's own documentation may not use the word ECI. Mastercard carries the e-commerce security level in its UCAF Security Level Indicator, and the two-digit 00/01/02 that payment APIs surface as “eci” is that concept reshaped into Visa's form by the gateway. If you are comparing a gateway field against a Mastercard specification and cannot find the term, that is why.
Leading zeros vary too. Some gateways send 5 where others send 05. This page treats them as the same value, but a string comparison in your own code will not.
The ECI arrives with the authorization. The transStatus arrives earlier, in the 3-D Secure authentication response, and it is a letter rather than digits. Two fields, two messages, two systems — which is why they can disagree.
| transStatus | Meaning | What it implies |
|---|---|---|
Y | Authenticated | Authorize, carrying the authentication data |
A | Attempted | Not authenticated, but proof of the attempt is provided |
C | Challenge required | Not a failure. Run the challenge, then read the final result |
D | Challenge required, decoupled | Happens out of band; wait for it (3DS 2.2.0+) |
I | Informational only | No decision is being reported (3DS 2.2.0+) |
N | Not authenticated | The cardholder did not pass |
R | Rejected by the issuer | The issuer asks that authorization not be attempted |
U | Could not be performed | Nothing was decided either way |
S | Secure Payment Confirmation | Challenge via SPC (3DS 2.3.1+) |
C is the one that costs money when it is misread. It means the issuer wants to challenge the cardholder and the flow is unfinished; a checkout that treats it as a decline throws away transactions that would have completed. R is the opposite mistake in the other direction — the issuer is asking you not to authorize, and sending the authorization anyway usually earns a decline you could have avoided.
A successful 3-D Secure step does not move liability by itself. Liability moves when the authorization carries the authentication result, and the scheme therefore stamps it with an authenticated or attempted ECI.
Authentication and authorization are two separate exchanges, and in most stacks two separate systems. If the authentication result never gets attached to the authorization — a different service builds the authorization, a retry drops it, a field is not mapped — the scheme sees an unauthenticated transaction and the ECI reflects that. The 3-D Secure logs will still show a clean success. This is the usual explanation for “we passed 3DS but got charged back anyway”.
So when the two disagree, the ECI is the one that decides the outcome, and the transStatus is the one that tells you what the authentication step believed. You need both to work out which half broke.
The ECI is a summary. The evidence behind it is a cryptographic value — a CAVV for Visa, an AAV inside the UCAF for Mastercard — carried in the authorization alongside it.
This page does not decode those, and that is deliberate. Their internal layout, and which subfield of DE48 carries them, are defined in each scheme's own interface specification. Those are licensed documents, not public standards, so publishing their structure here is not something we will do. Validating a CAVV also needs the issuer's keys, which means it was never going to be a web page's job.
What you can take from this page is the part that is publicly documented: what the indicator means, and what it implies for liability. For the layout, use the specification your acquirer gave you.