第 7 章 一笔卡交易的三段生命周期
所属：第二部分 · 卡（第 4–8 章） 前置：第 2 章（清算、结算、终局性）、第 5 章（四方模型、授权链路与资金链路反向）、第 6 章（interchange） 本章新概念：授权、请款、撤销、退款、拒付、预授权、ISO 8583
本章那张“授权、请款、入账、结算、撤销、退款、拒付”的状态表建议直接存下来。 后面讲风险、合规、对账时都要回来查它。
一、三秒钟的错觉¶
上一章最后问：刷卡三秒提示“支付成功”时，商户拿到那 97.70 了吗？你账户里那 100 块被扣走了吗？
这一章讲那三秒里实际发生了什么。
你在店里刷卡，POS 上显示“支付成功”。
此时实际发生的事情，比屏幕上那四个字少得多：
| 你以为发生了 | 实际发生了 |
|---|---|
| 你账户里的 100 块被扣走了 | 没有。余额一分没动，动的是“可用额度” |
| 商户收到了 97.70 | 没有。商户一分钱还没拿到 |
| 交易结束了 | 没有。它才走完三段里的第一段 |
发生的只有一件事：发卡行同意了这笔交易，并冻结了你的一部分额度。
二、三段¶
| 阶段 | 英文 | 谁在动 | 什么时候 | 钱动了吗 |
|---|---|---|---|---|
| 授权 | authorization | 商户 → 收单 → 卡组织 → 发卡行，原路返回 | 1 到 2 秒 | 没有 |
| 清算提交 | clearing / presentment | 商户日终打包 → 收单 → 卡组织 → 发卡行 | T+1 | 没有 |
| 结算 | settlement | 发卡行 →（按卡组织算出的净额）→ 收单行 → 商户 | T+1 到 T+2 | 动了 |
（T+1 指交易日之后的第 1 个工作日。）
第一段：授权
发卡行在这一到两秒里做三件事：确认卡有效、确认额度够、跑一遍风险评分。然后返回批准或拒绝。
批准的同时，发卡行在自己的系统里放一个“冻结”（hold）：你的余额还是 1000，但可用额度变成了 900。
这里对照清算与结算：这一步既没有清算也没有结算，它只是一次信息交换。 卡网络之所以能做到秒级，恰恰是因为它把最快的一段（问一句“行不行”）和最慢的一段（真的划钱）彻底拆开了。
第二段：清算提交
商户日终把当天所有已授权的交易打包成一个批次（batch），交给收单方。收单方汇总后提交给卡组织。卡组织按清算与结算讲的净额轧差，算出每家发卡行和每家收单行之间谁欠谁多少。
上一章那张分账表，就是在这一步被算出来的。
第三段：结算
发卡行按卡组织算出的净额，把钱划给收单行，收单行再按合同周期打给商户。钱不进卡组织自己的账——四方模型说过，它只算数、发指令。
常见是 T+1 或 T+2。但对新商户或高风险行业，收单方会故意拖长到 T+7 甚至更久，还会扣下一部分不放。
这笔扣款叫滚存准备金（rolling reserve）：收单方从每笔结算里扣留一小部分、押一段时间，用来抵扣未来可能发生的退款和拒付。它和货币层级那个存放在央行的准备金没有任何关系，只是中文撞了名。为什么要这样设计，未来讲支付的五类风险时会展开。
三段走完，本章开头那三个问题就有答案了。把三个数字各自什么时候变画在同一条时间轴上：
三条线在三个不同的时刻才拐弯，而用户看到的“支付成功”只对应最左边那一次。
三、授权不等于扣钱：由此长出的一整套状态¶
这是全章最实用的一张表。
| 动作 | 英文 | 发生了什么 | 用户看到什么 |
|---|---|---|---|
| 授权 | authorization | 冻结额度 | 待处理（pending） |
| 请款 | capture | 商户确认要收这笔钱，纳入当日批次 | 仍是待处理，直到清算完成 |
| 入账 | posting | 请款的交易走完清算，冻结转成一笔正式扣款 | pending 消失，账单上出现一笔正式消费 |
| 结算 | settlement | 钱通过清算网络从发卡行划到收单行，再到商户 | 用户端看不到变化；商户在 T+1 到 T+2 收到钱 |
| 撤销 | void / reversal | 授权后未请款就取消 | 待处理记录消失，额度立刻恢复 |
| 授权过期 | expiry | 商户一直不请款，冻结自动失效 | 常见 7 到 30 天后额度自动恢复 |
| 退款 | refund | 一笔金额相反的新交易 | 原交易保留，另有一条退款记录 |
| 拒付 | chargeback | 持卡人向发卡行申诉，强制把钱要回 | 商户被扣款，另付争议处理费 |
前四行是一笔交易正常走完的路径：授权 → 请款 → 入账 → 结算，也就是授权、清算提交、结算那三段一路推到底，钱在最后的结算这一步才真正到商户。后四行是中途的岔路——钱没走完就被拦下、退回或追回。
授权和请款为什么要分开？
因为很多生意在刷卡的那一刻还不知道最终该收多少钱。酒店入住时不知道你会不会用迷你吧，加油站在你插卡时不知道你要加多少油，外卖平台在下单时不知道你会不会加小费。
所以流程是：先授权一个预估金额占住额度，等确定了实际金额再请款。这叫预授权。
四、三个真实的坑¶
坑一：预授权金额和实际金额不一致
加油站在你插卡时冻结 100 美元，你实际只加了 40。
| 时点 | 冻结金额 | 实际请款 | 用户可用额度 |
|---|---|---|---|
| 插卡时 | 100 | — | 少了 100 |
| 加完油 | 100 | 40 | 仍少 100 |
| 清算完成后 | 释放 | 40 | 恢复到只少 40 |
中间那一段就是客诉高发区：用户看到“扣了 100”，实际只花了 40。做产品时要么在前端明确解释，要么在知道实际金额后立刻发一笔撤销（void / reversal，授权后未请款就取消），再按 40 重新授权一次。
坑二：退款不是撤销，而且要赔手续费
退款是一笔全新的、方向相反的交易，要重新走完三段生命周期，所以用户要等 3 到 5 天才看到钱回来。
更关键的一点：退款时商户已付的手续费通常整笔不退。 其中 interchange 一定不退——发卡行该干的活已经干完了，风险也已经承担过了；收单方那一部分按合同多数也不退。
用上一章的数字算一遍：
| 步骤 | 商户的现金 |
|---|---|
| 收款 100 元 | +97.70 |
| 全额退款 100 元 | −100.00 |
| 净结果 | −2.30 |
商户把货款一分不少退了，自己还倒贴 2.30 元手续费。这就是为什么退货率高的品类（服装、鞋类）在支付成本上格外吃亏。
坑三：授权过期时间因行业而异
酒店的预授权可能保留 30 天，普通零售 7 天。做对账系统时如果按统一时长处理，会出现大量“已授权未请款”的挂账，查起来极其痛苦。
五、对比：撤销、退款、拒付¶
三个词经常被混用，但它们在时点、成本和后果上完全不同。
| 维度 | 撤销 void | 退款 refund | 拒付 chargeback |
|---|---|---|---|
| 什么情况下发生 | 下错单、金额变了，商户还没请款 | 钱已收到，顾客退货或取消，商户同意退 | 持卡人不找商户、直接找发卡行：盗刷、商户拒不处理、货不对板 |
| 谁发起 | 商户 | 商户 | 持卡人 |
| 时点 | 请款之前 | 请款之后 | 交易后，窗口最长 120 天以上 |
| 钱实际动过吗 | 没动过 | 动过又退回 | 动过，被强制追回 |
| 手续费 | 不产生 | 已付的 MDR 通常整笔不退 | 商户另付争议处理费，常见 15 到 25 美元 |
| 对商户的记录 | 无影响 | 无影响 | 计入拒付率 |
| 商户能否申辩 | 不适用 | 不适用 | 可以，提交证据申辩，英文叫 representment |
为什么商户宁可主动退款，也不愿被拒付？
因为拒付会计入商户的拒付率，而卡组织对这个比率设有监控门槛。超标的商户会被列入监控计划、被罚款，持续超标可能被停止收单服务——那等于断了生意。
（具体门槛数值和统计口径这些年一直在调整，做产品时以卡组织当期发布的规则为准。量级上，这个门槛在 1% 以下。）
所以你会看到很多电商争议一来就直接同意退款，哪怕自己有理。这不是好说话，是在用 100 块的货款买一次不进拒付统计的保险。
六、报文长什么样：ISO 8583¶
点到为止，你不需要会写，但需要知道它的存在和它带来的限制。
ISO 8583 是 1987 年定稿的卡交易报文标准，今天全球绝大多数卡授权仍然跑在它上面。它是一种紧凑的二进制格式，用“位图”标记这条报文里哪些字段存在。
几个常见字段：
| 字段 | 含义 | 举例 |
|---|---|---|
| MTI | 报文类型 | 0100 授权请求，0110 授权响应 |
| DE2 | 主账号，即卡号 | — |
| DE4 | 交易金额 | 定长数字，隐含小数位 |
| DE39 | 响应码 | 00 批准，51 余额不足，05 拒绝不说明原因 |
| DE41 | 受理终端标识 | — |
需要记住的两件事：
- 这是一个 1987 年的标准，比互联网商用还早。它的设计目标是在极窄的专线带宽上跑通授权。
- 今天很多看似莫名其妙的产品限制，来源就是它。 金额字段是定长的，所以有金额上限；字段是数字或固定字符集的，所以商户名在账单上经常显示成一串奇怪的大写缩写；响应码只有两位数，所以“交易失败”的原因经常语焉不详——DE39 返回 05，就是发卡行明确拒绝但不愿说为什么。
下一章讲的 3DS（一套在授权之前先由发卡行验证持卡人身份的流程）和令牌化（把真实卡号换成一串替代号码，让商户永远拿不到真卡号），都是在不推翻 ISO 8583 的前提下，往这套老骨架上打补丁。
七、这一章引出的问题¶
以上全部建立在两个前提上：卡在现场，人在现场。
有一张实体卡可以插进读卡器，有一个活人可以签名或输密码。发卡行的风险因此是可控的。
网上买东西时，这两个前提同时消失了。商户只拿到一串数字，看不见卡、也看不见人。这串数字可以被抄走、被转卖、被在世界任何角落使用。
于是问题变成：谁来证明这笔交易是持卡人本人做的？如果证明不了、又发生了盗刷，损失算谁的？
下一章讲这两个问题，以及围绕它们打了三十年的技术军备竞赛。
八、自检题¶
- 用户在 App 里看到一笔“待处理”的交易。用本章的词说清楚，此时这笔钱在哪一方手里。
- 一个客单价 200 元、退货率 20%、毛利率 30% 的服装电商，支付手续费按 2.3% 算。每卖出 100 单，它在支付上的真实成本是多少？
- 为什么说 3DS 和令牌化是“往老骨架上打补丁”，而不是替换掉它？
九、参考答案¶
先自己答完再往下看。
钱还在持卡人自己的账户里，一分没动。发生的只是发卡行冻结了对应额度，导致可用额度减少。商户此时也没有收到任何资金，它只拿到了一个“发卡行同意付款”的承诺。要等清算提交和结算完成，钱才真的从发卡行流向收单行再到商户。
分步算：
- 卖出 100 单，成交金额 100 × 200 = 20000 元，手续费 20000 × 2.3% = 460 元。
- 退货 20 单，退款金额 20 × 200 = 4000 元。这 4000 元货款全额退回，但对应的 4000 × 2.3% = 92 元手续费不退还。
- 实际留存订单 80 单，销售额 16000 元，毛利 16000 × 30% = 4800 元。
- 支付真实成本 = 460 元（含被退货订单那 92 元的沉没手续费）。
- 占毛利比例 = 460 ÷ 4800 ≈ 9.6%。
交叉验证：若退货率为零，手续费为 16000 × 2.3% = 368 元，占毛利 7.7%。两者相差的 92 元正是退货订单的沉没手续费，与上面的算法一致。
因为它们都没有改动 ISO 8583 的授权报文结构本身。令牌化只是把 DE2 字段里的真实卡号换成一串替代号码——替代号码本身就是格式合法的卡号，所以报文一个字节都没变；3DS 是在授权发起之前另跑一套独立流程，把结果作为附加字段塞进原有报文。全球几十万家机构的系统跑在这套标准上，替换的成本高到不可能，所以所有创新都必须以“兼容旧报文”为前提。这也解释了为什么支付行业的技术演进看起来总是叠床架屋。
上一章：第 6 章 Interchange：整个支付行业的经济学核心 下一章：第 8 章 卡不在场：一场持续三十年的欺诈军备竞赛