卡交易逆向流程：撤销、退款、冲正与拒付

支付被取消、接口返回 timeout、账单出现退款、商户收到争议通知，都可能被笼统称为「冲正」或「钱退回去了」。这些事件发生在不同阶段，发起方、网络消息、资金影响和后续责任也不同。

处理一笔逆向交易前，先确认原交易停在哪一步：只有 Authorization，已经 Capture，已经进入 Clearing / Settlement，还是结果仍然未知。这个判断比「当天还是隔天」更可靠。正向阶段的职责可先参见《卡交易正向流程：授权、清算与结算》。

先看原交易停在哪一步

「当日撤销」和「隔日退款」便于口头沟通，却不能稳定决定系统动作。跨时区交易、延迟 Capture、快速 Clearing 和处理商内部状态都会让自然日失去判断力。

Authorization Reversal：释放未使用的授权

酒店退房后不再使用全部预授权、租车订单取消、电商订单在发货前取消，都会出现「授权已经批准，但交易没有按原金额完成」的情况。Merchant 可以提交 Authorization Reversal，由 Acquirer 经卡网络转给 Issuer，目标是释放不再需要的 Authorization Hold。

以 2026 年 4 月版 Visa 公共规则为例：已完成交易的最终金额低于累计授权金额时，Merchant 应在交易完成后 24 小时内撤销差额；其他获批但未完成的交易，应在取消、Cardholder 改用其他支付方式或授权有效期结束等规则规定的较早时点起 24 小时内撤销。自动加油机等场景存在地区例外。

这条 24 小时规则约束 Merchant 提交 Reversal 的时间，不保证 Issuer App 在 24 小时内更新，更不等于每个网络都采用相同窗口。授权占用的展示和释放速度由 Issuer 处理；通信费、网关费或 Misuse of Authorization 相关费用则要看网络费率表、Acquirer 与 Merchant 合同。

Void：一个操作名，未必是一种卡网络消息

Merchant 后台里的 Void 通常表示「阻止这笔付款继续完成」。如果付款还没有 Capture，PSP 可能把 Void 实现为 Cancel 或 Authorization Reversal；如果交易已经提交到后续处理，系统也可能拒绝 Void，要求改走 Refund。

因此，Void 的边界不应写成「当天日切前」。系统需要读取 PSP 返回的状态和能力，确认它会释放授权、阻止尚未提交的 Clearing，还是只更新 Merchant 自己的订单状态。交易已经完成后，仅修改本地状态不能阻止网络清算。

ISO 8583 的 0400、0420 或其他消息类型也不能脱离具体网络 Profile 使用。同一个 Void 按钮在不同处理商上可能对应不同消息，公开业务状态不应直接绑定一个跨网络固定 MTI。

Refund：对成功付款发起贷记

付款成功后，Merchant 可以发起全额或部分 Refund。退款通常沿原支付网络提交给 Issuer，并退回原支付方式。它可能发生在 Merchant 收到 Payout 之前，也可能发生在银行间 Settlement 之后；「隔日」不是 Refund 的定义。

Stripe 当前文档给出的银行卡退款示例约为 5～10 个工作日到账，具体取决于银行。原交易完成后很快发起的退款，有时会以 Reversal 形式展示：原扣款从账单中消失，不再另外出现一笔 Credit。这个展示和时效属于处理商与 Issuer 的实现，不是所有卡组织保证。

Refund 会改变 Merchant 或 PSP 的余额。可用余额不足时，处理商可能把退款保持为 pending、从后续收入中补足，或按合同从银行账户回收资金。它也可能失败或被取消，所以系统不能在「提交 Refund 请求」时就把交易写成最终 refunded。

技术冲正处理不确定结果

技术冲正处理的是通信异常，而不是退货或客服协商。Terminal 发出请求后如果没有收到响应，只能确认「调用方没有拿到结果」，不能确认 Issuer 没有批准、Acquirer 没有 Capture，或 Refund 没有成功。

Visa 公共规则给出一个明确场景：Merchant 在 POS timeout 后又收到 Approval Response，应提交 Authorization Reversal。这个要求说明「超时后补冲正」需要原交易结果作为依据，而不是看到 timeout 就发送一条万能 Reversal。

不同异常需要不同恢复动作：

这些场景都需要保留原交易标识、请求标识和每次状态变化。failed、reversed、refunded 和 adjusted 表示不同结果，不适合用一个布尔值覆盖。

Refund 与 Chargeback 不是同一条路

Refund 由 Merchant 主动发起，通常来自退货、取消服务或客服协商。Dispute / Chargeback 则由 Issuer 依据 Cardholder 的争议和适用规则，在卡网络中回转交易全部或部分价值。以 Stripe 的处理路径为例，Issuer 建立正式 Dispute 后，Stripe 会从 Merchant 的 Stripe 余额中扣除争议金额与相应费用。

Cardholder 提出异议并不自动证明 Merchant 有错。Issuer 需要按适用的 Dispute Condition 发起正式流程，Merchant 也可以在窗口内提交相应证据。反过来，Merchant 已发货或持有一张订单截图，也不保证抗辩成功；证据必须回答对应 Reason Code 的问题。

争议通常从三类问题开始

1. 未授权或欺诈。 卡片、账户或支付凭证被盗用，Cardholder 不认可交易。Account Takeover 也可能让攻击者使用真实账户完成购买。

2. 第一方欺诈或交易不识别。 Cardholder 本人、家庭成员或获准使用卡片的人完成消费，事后仍提出未授权；也可能只是账单上的 Billing Descriptor 与品牌名不一致。数字商品已交付后谎称未收到、家庭成员完成游戏充值等，也会落入这类运营难题。公开数据的样本和定义差异很大，不能把「超过 60%」写成所有 Merchant 的统一占比。

3. 商品、服务或处理错误。 未收到货、货不对版、重复扣款、取消订阅后继续扣费，以及退款未处理，都可能进入相应的消费争议或处理错误类别。

Visa 面向 Merchant 的争议建议要求清楚披露 Return、Refund 与 Cancellation Policy，及时提交交易，避免重复处理，并在 Clearing 中使用 Cardholder 能识别的 Merchant Name。账单名称与品牌不一致不一定构成欺诈，却会增加原本可以避免的争议。

Pre-Dispute Alerts 争取在正式争议前处理

Ethoca Alerts 一类服务连接 Issuer、Acquirer 与 Merchant，近实时共享欺诈和争议线索。Merchant 收到 Alert 后，可以停止尚未发出的商品、取消服务或发起 Refund，从而减少进入正式 Chargeback 的需要。

Alerts 不是统一的「24～72 小时拦截层」。覆盖哪些 Issuer、怎样通知、Merchant 有多少响应时间、退款后怎样关闭案件、每笔怎样收费，都取决于 Alerts Network、Acquirer、PSP 和合同。Visa 的 Rapid Dispute Resolution（RDR）又是另一种 Pre-Dispute 服务：Merchant 或 Payment Facilitator 可以按规则自动接受争议责任。两者不能只用一个 alerted 状态表示。

一笔小额交易也能说明成本取舍。假设原交易是 10 美元，服务商对一次 Alert 收取 15 美元，Merchant 选择全额退款后，当期现金影响是：

10 美元 Refund + 15 美元 Alert Fee = 25 美元

这个算例没有计入商品成本、履约是否已经发生、原交易处理费、正式 Dispute 费用或长期监控影响，也不代表任何服务商的公开报价。Merchant 是否处理 Alert，应结合订单毛利、能否停止履约、重复 Refund 风险和 Acquirer 要求判断。

监控阈值不是一个固定百分比

Visa Acquirer Monitoring Program（VAMP）会按专门的 Program Guide 识别需要治理的 Acquirer，并可以按聚合 Merchant 或 Sponsored Merchant 层级评估活动。公共 Core Rules 没有把所有 Merchant 的红线写成一个 0.9%～1.5% 区间。

不同计划可能采用不同的分子、分母、交易量门槛、地区范围和生效日期。Merchant 系统应保存 Acquirer 提供的当前计算口径与工单截止时间，不能把 0.5%、0.9% 或 1.5% 作为跨网络硬编码常量。达到监控条件后的整改、费用、准备金或终止风险，也应以当前规则和合同为准。

正式 Dispute 会经历哪些阶段

卡网络的名称和步骤并不完全相同。下面使用 Visa 公共规则中的术语表达主干流程，同时保留行业里常说的 Representment：

1. Dispute 与资金回转

Issuer 只有在适用条件满足时才能发起 Dispute，并指定对应的原因。正式 Dispute 会形成网络中的财务回转；Merchant 看到的扣款、Reserve 使用和费用，通常由 Acquirer 或 PSP 再按合同执行。

2. Dispute Response / Representment

Merchant 可以接受争议，也可以把证据交给 Acquirer / PSP，由成员机构提交 Dispute Response。Representment 常用于描述重新呈递交易及证据的动作；在 Visa Category 12 / 13 的当前公开流程中，对应阶段名称是 Dispute Response。

Issuer 收到响应后会评估证据。接受响应时，相关责任和资金可以按规则恢复；Issuer 也可能提供新信息、改变符合条件的 Dispute Condition，或进入 Pre-Arbitration。Issuer 是争议流程的一方，不是独立法院。

3. Pre-Arbitration

Pre-Arbitration 让 Issuer 与 Acquirer 在提交 Arbitration 前继续处理证据和责任。Visa 要求相关金融消息、文档、Pre-Arbitration 与 Arbitration 通过 VisaNet 或 Visa Resolve Online（VROL）处理，但地区和私有安排存在例外。Merchant 通常通过 Acquirer 或 PSP 操作，不直接把材料提交给卡组织。

4. Arbitration

前述阶段无法解决时，符合条件的一方可以把案件提交 Card Scheme Arbitration。Scheme 根据规则、证据和程序要求裁决成员机构责任。案件金额、程序费、内部运营成本与胜诉概率都会影响是否继续，但不存在跨卡组织统一的 500～1000+ 美元费用或 30～70 天结案承诺。

时限不能从一张总表读取

争议时限会从 Transaction Processing Date、预计交付日、取消日、Dispute Processing Date 或上一阶段处理日等不同事件起算。以 2026 年 4 月版 Visa 公共规则为例：

这些数字不能相加成「一笔 Chargeback 固定处理多久」，也不能拿 Visa 的 30 天覆盖 Mastercard、其他网络或 PSP 给 Merchant 的内部截止时间。实际操作应以工单中更早的 Merchant Due Date 为准，因为 Acquirer / PSP 还要预留审核和网络提交时间。

证据包按 Reason Code 组织

证据越多不一定越有效。材料需要解释对应争议原因，并能关联到同一笔订单、Cardholder、支付凭证和履约记录。

Visa 公共规则会按 Dispute Condition 规定可接受的文档和 Certification；规则还可能变化。例如，2026 年 4 月版文件已经列出 2026 年 10 月 24 日将生效的 CE 3.0 更新。在生效日前，不能把未来条款当成当前适用规则；生效后也要重新核对具体资格。

费用按合同和规则表读取

逆向流程里的「费用」至少分成 4 层：

1. Dispute 或 Refund 涉及的原交易价值。

2. PSP / Acquirer 按 Merchant Agreement 收取的 Refund、Alert、Dispute Response 或 Chargeback Fee。

3. Card Scheme 对成员机构收取的案件、合规、监控或 Arbitration 费用。

4. Merchant 自己的履约、物流、客服、证据整理与资金占用成本。

这些费用的计费条件和承担方可能不同。把 Alerts 写成每笔 12～20 美元、把首次 Chargeback 写成 15～50 美元、把 Pre-Arbitration 写成 100～150 美元，会把服务商报价、Card Scheme Fee 与 Merchant 合同混在一起。生产系统应保存费用类型、币种、计费方、合同版本和关联案件，而不是只记录一个 chargeback_fee。

收到逆向事件时，至少要能回答 5 个问题：原交易当前由谁确认，发起方是谁，余额或授权占用发生了什么变化，下一阶段的截止时间是什么，哪个外部记录能证明最终结果。这样才能让 voided、reversed、refunded、disputed 与 adjusted 各自对应可核对的业务事实。

参考资料

• Visa：Visa Core Rules and Visa Product and Service Rules

• Visa：Dispute Resolutions

• Stripe：Refund and cancel payments

• Stripe：Disputes

• Ethoca：Ethoca Alerts