ISO 8583 Parser
免费 · 讲解 · 约 8 分钟 · 更新于 2026-08-25

3-D Secure、ECI 与责任转移:到底哪个域说话

认证和授权是两条不同的报文,发出的时间不同,通常还由不同的系统发出。欺诈责任跟着授权报文带了什么走,而不是跟着 3-D Secure 那一步报了什么走。这两者会互相矛盾 —— 而矛盾本身就是问题所在。
本页内容: 两条报文,两套系统 · 责任到底是被什么转移的 · 两家的取值,以及为什么方向相反 · 结果不对时的排查顺序 · 本文到哪里为止

两条报文,两套系统

一次 3-D Secure 认证是它自己的一次交互,而且不是 ISO 8583。商户的 3DS 服务器通过 HTTPS 用 JSON 和卡组织的目录服务器、发卡行的访问控制服务器对话,拿回一个带 transStatus 的认证响应。

授权是另一次交互,更晚,走 ISO 8583。它带的是 ECI —— 一个两位的电子商务指示符,说明认证那一步发生了什么 —— 以及支撑这个说法的密码学证据。

两者之间没有任何自动的关联。必须由你系统里的某个环节把第一次交互的结果取出来、挂到第二次上去。在多数架构里这是两个服务之间的一次交接 —— 出问题就出在这儿。

责任到底是被什么转移的

责任不是因为 3-D Secure 成功而转移的。它转移是因为授权报文到达时带上了认证结果,卡组织因此给它打上了「已认证」或「已尝试」那档 ECI。争议处理看的就是 ECI。

这个区别在一切正常时看不见,在出问题时决定一切。如果认证结果始终没进到授权报文里,卡组织看到的就是一笔普通的、未认证的电商交易,ECI 也如实反映。而你的 3-D Secure 日志仍然是干干净净的成功 —— 因为认证确实成功了。两份记录都没错,它们描述的是两件不同的事。

「明明过了 3DS 还是被拒付」通常就是这么来的。不是卡组织错了,也不是发卡行错了,是一次交接把一个域丢了。

还有一点在依赖它之前该知道:已尝试这一档通常也会转移责任,这一点常让人意外 —— 按通行规则,尝试过就够了。但豁免、区域规则、特定产品的例外都存在,所以具体某一笔要以卡组织自己的规则为准,不是以这一页为准。

两家的取值,以及为什么方向相反

两家报的是同样三种结果,编号方向相反。

结果VisaMastercard责任
持卡人已认证0502转移给发卡行
尝试过但未完成0601转移给发卡行
未认证0700留在商户

Visa 这边数字越大结果越差,Mastercard 那边数字越大结果越好。所以一个把两家压进同一个 eci 值的网关字段,会在一半流量上表现正确、在另一半上表现错误,而且哪儿都不会报错。ECI 解析工具接受一个取值加一个卡组织,告诉你这是哪一种,也包括「这个值不属于你选的这家」这种情况。

Mastercard 自己的文档里可能压根不出现 ECI 这个词 —— 它是用 UCAF 的安全级别指示符来承载电商认证等级的,你的支付接口里那个叫 “eci” 的 00/01/02,是网关把这个概念改写成了 Visa 的形状。

结果不对时的排查顺序

顺序是有讲究的。每一步都很便宜,而且能排掉一整类原因,所以照着往下走比凭感觉猜快。

1. 先确定该读哪一家的表。06 在 Visa 是「已尝试、责任已转移」,在 Mastercard 根本不是一个取值。先从卡号判断卡组织,再去解释那两位数字。这一步就能排掉所有「我们把 05 当已认证」这类问题 —— 它最常见也最难发现,因为它永远只在一半流量上出错。

2. 确认 ECI 和 transStatus 说的是不是同一次认证。用户重试、会话过期、收银台重新发起,都会产生一次新的认证和一个新的 transStatus。日志里挨在一起的两个值,不一定来自同一次尝试。

3. 认证成功但 ECI 不这么说 → 去看授权报文实际带了什么。就是上一节说的那次交接。授权往往由另一个服务拼装,不是跑 3-D Secure 那个;重试路径、没映射的字段、会重新拼请求的队列,都会静默地把认证结果丢掉。把实际发出去的授权和你以为发出去的那条逐域对一遍。

4. transStatus 是 C 却被当成失败 —— 那就是问题本身。C 的意思是发卡行要验证持卡人、流程还没结束。把它读成失败的收银台,会白扔掉本来能成的交易。最终结果要从挑战之后的结果报文里读,不是从第一个响应里读。

5. transStatus 是 R 就不要去授权。发卡行明确要求你不要发。硬发通常换来一个本可避免的拒绝,而且这个拒绝没法归咎于别人。

6. 如果对不上的是责任归属,以 ECI 为准。transStatus 说的是认证那一步自己以为发生了什么,ECI 才是卡组织据以行动的东西。判断哪一半坏了要两个都看,但能定争议的只有一个。

7. 上面都对上了结果还是不对,剩下的原因就不是公开资料能回答的了。那个密码学值是否有效、是否放在了你的收单机构期望的子域里 —— 这些定义在卡组织的接口规范里,而校验还需要发卡行的密钥。到这一步该翻收单机构给你的那份规范,而不是继续搜。

本文到哪里为止

ECI 是对一个说法的概括。证据是随它一起送出去的密码学值 —— Visa 那边叫 CAVV,Mastercard 那边是 UCAF 里的 AAV。

本站不公开它们的内部排布,也不写它们由 DE48 的哪个子域承载,因为那些定义在各卡组织需要授权才能取得的接口规范里,不是公开标准。同一条规矩也让其它卡组织专有的结构不出现在本站。这里写的是公开可查的那一部分,以及你可以自己核对的推理。

→ 按正确的卡组织解一个 ECI

相关阅读