把网关返回的 ECI 贴进来再选卡组织，直接得到：这个值代表哪种结果、到底有没有人核对过持卡人、欺诈责任有没有转移。输入单个字母时按 3-D Secure 的 transStatus 解。
授权报文里的一个两位码，说明认证那一步发生了什么：持卡人通过了认证、尝试过认证但没能完成、或者压根没认证。
它要紧是因为争议处理看的是这个域。不是你收银台看到的那个 3-D Secure 响应，而是随授权报文一起到达的 ECI。
两家报的是同样三件事：持卡人通过了认证；尝试过认证但发卡行没能完成；什么都没认证。不同的是数字，而且方向相反 —— Visa 从好到坏是 05、06、07，Mastercard 从好到坏是 02、01、00。同一个「数值变大」，一家是变坏，另一家是变好。
| 结果 | Visa | Mastercard | 欺诈责任 |
|---|---|---|---|
| 持卡人已认证 | 05 | 02 | 转移给发卡行 |
| 尝试过认证但未完成 | 06 | 01 | 转移给发卡行 |
| 未认证 | 07 | 00 | 留在商户 |
所以把两家压进同一个 eci 字段的网关，会造出「只在一半流量上出现」的 bug。一条写成「05 视为已认证」的规则，对 Visa 是对的，对每一笔 Mastercard 都静默地错 —— 在那边 05 根本不是一个取值。
还有一处容易卡住的地方：Mastercard 自己的文档里可能压根不出现 ECI 这个词。Mastercard 是用 UCAF 的安全级别指示符（Security Level Indicator）来承载电商认证等级的，各家支付接口里那个叫 “eci” 的 00/01/02，是网关把这个概念改写成了 Visa 的形状。如果你拿网关字段去对 Mastercard 的规范却找不到这个词，原因就在这儿。
前导零也不统一。有的网关发 5，有的发 05。本页当同一个值处理，但你自己代码里的字符串比较不会。
ECI 随授权报文到达。transStatus 更早，在 3-D Secure 的认证响应里，而且是字母不是数字。两个域、两条报文、两套系统 —— 这就是它们会互相矛盾的原因。
| transStatus | 含义 | 意味着什么 |
|---|---|---|
Y | 认证成功 | 去授权，把认证数据带上 |
A | 已尝试认证 | 没完成认证，但给了「尝试过」的凭证 |
C | 需要挑战 | 不是失败。去走挑战，再读最终结果 |
D | 需要挑战，解耦认证 | 在收银台之外完成，等结果（3DS 2.2.0 起） |
I | 仅供参考 | 这里没有给出任何结论（3DS 2.2.0 起） |
N | 认证不通过 | 持卡人没通过 |
R | 发卡行拒绝 | 发卡行要求不要发起授权 |
U | 无法完成认证 | 两个方向都没有结论 |
S | 用 SPC 挑战 | 通过 Secure Payment Confirmation 挑战（3DS 2.3.1 起） |
读错最贵的是 C。它的意思是发卡行要验证持卡人、流程还没结束；把它当成拒绝的收银台，会把本来能成的交易白扔掉。R 是反方向的同类错误 —— 发卡行明确要求你不要授权，硬发通常换来一个本可避免的拒绝。
3-D Secure 那一步成功，本身并不转移责任。责任转移发生在授权报文带上了认证结果、卡组织因此给它打上「已认证」或「已尝试」那档 ECI 的时候。
认证和授权是两次独立的交互，在多数系统里还是两套服务。如果认证结果没被挂到授权报文上 —— 授权由另一个服务拼装、重试时丢了、某个字段没映射 —— 卡组织看到的就是一笔未认证交易，ECI 也如实反映。而 3-D Secure 的日志里仍然是干干净净的成功。「明明过了 3DS 却还是被拒付」通常就是这么来的。
所以两者矛盾时，决定结果的是 ECI，告诉你认证那一步自己以为发生了什么的是 transStatus。要判断是哪一半坏了，两个都得看。
ECI 是个结论。它背后的证据是一个密码学值 —— Visa 那边叫 CAVV，Mastercard 那边是 UCAF 里的 AAV —— 和它一起放在授权报文里。
本页不解这些，而且是故意不解。它们的内部排布、以及在 DE48 里由哪个子域承载，都定义在各卡组织自己的接口规范里。那些是需要授权才能拿到的文档，不是公开标准，把它们的结构搬到这里不是我们会做的事。另外校验一个 CAVV 还需要发卡行的密钥 —— 那本来也不该是一个网页干的活。
本页能给你的是公开可查的那一半：这个指示符是什么意思、对责任意味着什么。排布去看你收单机构给你的那份规范。