| STAN (DE11) | RRN (DE37) | |
|---|---|---|
| 全称 | 系统跟踪审计号 | 检索参考号 |
| 长度 | 6 位数字 | 12 位 |
| 谁生成 | 发起方(终端/收单) | 收单方 |
| 唯一范围 | 当天、单机构内唯一 | 较长期、跨系统追踪 |
| 主要用途 | 冲正/应答匹配当笔 | 退款/查询/对账引用 |
| STAN(DE11) | RRN(DE37) | |
|---|---|---|
| 长度 | 6 位数字 | 12 位字符 |
| 唯一范围 | 当天、同一受理机构内 | 整笔交易生命周期,跨系统 |
| 谁生成 | 发起请求的一方 | 收单方生成,端到端原样传递 |
| 适合用来 | 在途匹配「这个响应对应哪个请求」 | 对账、争议、跟对接方沟通 |
6 位数字一共 100 万个值,而且每天重置。交易量大的收单方一天之内就可能绕回;就算不绕,过了零点也一样从头开始。所以 STAN 单独拿来当键是不行的。要用 STAN + 受理机构标识(DE32)+ 传输日期(DE7)组合匹配。少任何一项,迟早会把响应配到错误的请求上。这类故障的表现——甲的批准结果被写进乙的订单——只在 STAN 绕回的那一小段时间窗里出现,事后按单号回溯不到。
这也是为什么冲正报文的 DE90 里要把原 STAN、原日期、原受理机构标识打包在一起:任何单独一项都不足以唯一定位。
跟卡组织、收单方或发卡行沟通某一笔具体交易时,报 RRN。它是贯穿授权、清算、结算、拒付整个生命周期都不变的标识,对方系统也是按它建索引的。报 STAN 过去,对方多半还是会回过头来问你要 RRN。
有些卡组会在 RRN 里编码一些结构(比如年份位、一年中的第几天、终端或流水号片段),但千万别去解析它取含义:各家布局不同,也不保证稳定。当成不透明字符串处理就好。
👉 相关:ISO 8583 字段速查(DE11 / DE37)。