| 名称 | 在卡上的哪里 | 在 ISO 8583 报文的哪里 | 谁校验 |
|---|---|---|---|
| CVV / CVC （磁道 CVV，即「CVV1」） | 写在磁条里，藏在磁道的自定义数据区（discretionary data） | DE 35（Track 2 Data）/ DE 45（Track 1 Data） | 发卡行 |
| CVV2 / CVC2 （Amex 叫 CID） | 印在卡面——背面 3 位（Amex 正面 4 位），不写进任何磁道 | 走附加数据域里由卡组织自定义的子域。具体哪个域、哪个子域各家不同，以你对端的接口规范为准 | 发卡行 |
| iCVV | 在芯片里，藏在二磁道等效数据（EMV tag 57）中 | 通常在 DE 55（ICC / EMV 数据）里，即 tag 57 | 发卡行 |
| dCVV （Mastercard 叫 CVC3） | 哪儿都没有——非接磁条模式（MSD，现已基本淘汰）下由卡片每次挥卡现算 | 随这笔交易的 track 2 数据走，落点和刷卡一样是 DE 35，只是值每笔都变 | 发卡行 |
注意最后一列的共同点：四个值全部只有发卡行能校验。收单、网关、转接方只负责把值放到报文里正确的位置。所以生产上大多数「CVV 问题」追到最后都是搬运问题——值放错了域，或者出现在了一笔根本不该带它的交易里。
芯片里的二磁道等效数据（tag 57）长得和磁条 track 2 几乎一样：同样的卡号、有效期、服务码。但自定义数据区里那个校验值是另一个数——iCVV——这是设计出来的差异。
假如有人把芯片里的 tag 57 读出来，写到一张白卡的磁条上拿去刷：这张伪卡送上来的是 iCVV，而发卡行对刷卡交易验的是磁道 CVV，校验必然失败，交易被拒。一个通道一个值，从一个通道偷到的数据没法拿去冒充另一个通道——这是 EMV 防「芯片数据降级复制成磁条卡」的关键一环。
一笔芯片交易的报文里，track 2 形状的数据可能出现两次：一次在 DE 35（Track 2 Data），一次在 DE 55 里的 tag 57（二磁道等效数据）。卡号、有效期一致，末尾的自定义数据区却对不上，这就是上一节那个机制：一边带的是磁道 CVV，一边带的是 iCVV。
想亲眼确认，把 DE 55 的十六进制贴进 EMV TLV 解析器，拿 tag 57 和 DE 35 对一下；或者整条报文直接丢进主解析器。DE 35 / DE 45 / DE 55 的格式细节见字段速查，完整报文里的样子见报文实例。
经典工单：小票或主机日志显示 CVV2 校验失败，持卡人坚持卡面上那几位数一个字没错。先别急着归因「输错了」，按这个顺序过一遍：
PCI DSS 明确规定：授权完成后不得保留卡片验证码。加密存也不行，任何形式都不能留——请求日志、数据库字段、崩溃转储、贴在工单里的截图，全算。CVV2 存在的意义就是在交易那一刻证明「卡在手上」，没有任何正当理由需要持久化它。
同一条规则也罩着完整磁道数据——DE 35、DE 45，以及芯片里的 tag 57，它们同属敏感认证数据。实践中出问题的很少是数据库表结构，而是没脱敏的请求/响应日志：确认脱敏发生在报文进日志管道之前。
剩下的麻烦是：要确认脱敏真的生效，总得有人至少看一次没脱敏的那行。本站所有解析都在你自己的浏览器里跑、什么都不上传——但这件事你没法在一个浏览器标签页里向安全评审证明，于是实际发生的往往是照着截图把字段一个个敲进去。离线版就是同一个解析器，以文件形式放在你自己的磁盘上，差别只在这一点上。
👉 相关：ISO 8583 字段速查（DE 35 / 45 / 55）、EMV 标签参考（tag 57）。