支付系统的复杂性往往隐藏在交易类型的细节中。从超额捕获的餐饮小费处理，到部分授权的资金风险管控，再到退款流程的实时认证要求，本文将深入解析五种核心交易类型的运作机制与设计要点，帮助产品经理掌握支付系统的底层逻辑与合规边界。

在上一篇文章里面我们主要介绍了Authorization和Capture，这一篇我们将再介绍一些类型以及特定场景。

在 Authorization 与 Capture 之后，系统还会面临：

• 金额浮动（Over Capture）
• 授权不足（Partial Authorization）
• 撤销交易（Reversal）
• 主动退款（Refund）
• 独立打款（Credit）

一、Over Capture：超额Capture

Over Capture 是指：

Capture 金额大于 Authorization 金额。

听起来不合理，但在特定行业，它是被卡组织允许的合规行为。

1. 常见场景

• 餐厅小费
• 酒店服务费
• 租车附加费用

例如：

在餐饮场景里，真实交易流程是这样的：

1. 顾客刷卡
2. 商户发起 Authorization（例如 100 USD）
3. 顾客用餐结束
4. 在小票上手写小费（例如 10 USD）
5. 商户录入最终金额 110 USD
6. 发起 Capture

关键点是：

小费是在授权之后才产生的。

授权发生时，系统根本不知道最终金额。

这决定了： Authorization 金额只能等于账单金额，小费只能在 Capture 阶段体现。

2. 限制条件

Over Capture 并非通用能力，必须满足：

1、MCC 属于允许浮动行业

2、浮动比例在合理区间（通常 15%–20%）

3、在授权有效期内清算

4、具备签名小票或电子证据

如果不满足，可能触发：

• No Authorization 拒付
• Incorrect Amount 拒付

这里是我从Stripe网站找到的内容：

Stripe这里面也说明了Over Capture和Incremental Authorization的差别就在于不需要再做一次授权。

卡组允许：在特定 MCC 下，Capture 金额可以在授权金额基础上合理浮动。

3. 系统视角

Over Capture 不是新的授权。

它是：

在原授权基础上的合规金额调整。

这意味着：

• 不会产生新的授权编号
• 不会重新进入发卡行风险判断
• 但必须在清算规则内完成

二、Partial Authorization：授权只批了一部分金额

Partial Authorization 是指：

发卡行只批准部分金额。

例如：

请求授权 100 USD，发卡行仅批准 70 USD。

常见场景：

• 借记卡余额不足
• 预付卡
• 部分资金可用

1. 系统需要做什么？

多发生在线下POS场景，Online的业务大部分不会接受部分授权成功。收单系统设计必须决定：

• 是否允许部分授权
• 是否提示用户补差额
• 是否自动取消交易

如果不支持部分授权，系统应立即做 Reversal。

2. 风险点

如果商户错误地按 100 USD 清算，将触发 No Authorization 拒付，并且如果交易已经结束，商家只能capture到一部分的金额，造成资金损失。

因此：

Capture 金额必须 ≤ 批准金额。

三、Reversal/Void：撤销

Reversal 是：

在cut-off前撤销授权或交易。

常见情况：

• 用户取消订单
• 授权金额错误
• 系统异常
• 交易未完成

Reversal 的特点：

• 发生在 Authorization 或 Refund 之后
• 发生在 Clearing 之前
• 作用是释放冻结额度

1. 资金流向

Reversal 不会发生真实扣款。

它只是通知发卡行：

不要再为这笔授权保留额度。

2. 关键点

Reversal ≠ Refund。

Reversal 是“未完成交易的撤销”，不会被收取手续费。

Refund 是“已完成交易后的退款”，会被收取退款手续费。

四、Refund：原交易的主动退款

Refund 是：

商户在交易完成后，主动原路退还资金。

与 Reversal 不同：

• Refund 发生在 Capture / Clearing 之后
• 资金已经清算
• 必须走独立交易流程

1. Mastercard 规则变化

现在 Mastercard 要求：

Refund 需要发起 Authorization Request（0100）。

也就是说Refund 已经变成需要发卡行实时审批的交易。

2. 这意味着什么？

Refund 不再是单纯“资金退回”。

它是：

一笔新的、实时认证的资金交易。

因此经常出现：

• Refund 授权失败
• 发卡行拒绝退款

五、Credit：独立入账交易

Credit 是：

不依赖原交易的资金入账，更像是pay-out。

例如：

• 商户赔偿
• 人工打款
• 奖励金发放

它与 Refund 的最大区别是：Refund 必须关联原交易，Credit 可以独立存在。

1. 风险区别

Refund：

• 拒付风险较低
• 属于售后行为

Credit：

• 更容易被风控关注
• 可能被用于洗钱或套利

因此很多收单行会限制 Credit 功能，能支持Credit的支付公司也比较少。

六、五种交易类型的核心区别

• Over Capture：授权金额的合规浮动，发生在 Capture 阶段
• Partial Authorization：发卡行只批准部分金额，发生在 Authorization 阶段
• Reversal：撤销尚未清算的交易，释放冻结额度
• Refund：已完成交易的主动退款，需要实时授权
• Credit：独立资金入账，不依赖原交易

七、从系统生命周期角度总结

一笔信用卡交易，从系统视角看：

Authorization → Capture → Clearing

之后可能进入：

Reversal（若未清算） Refund（商户主动） Chargeback（持卡人发起）

而Over Capture 与 Partial Authorization，发生在授权与扣款之间。

八、真正重要的一点

作为收单行或支付系统，一定要清晰各种交易类型的场景和边界，才能设计出合理的状态机以及校验机制，保证业务正常运行。

结语

到这里，我们已经讲清楚了各种交易的类型和请求，接下来我们将介绍独立于支付请求之外的争议体系。

• Retrieval Request（调单）
• Chargeback（拒付）
• Representment（抗辩再请款）
• Chargeback Reversal（拒付撤销）
• Pre-Arbitration（预仲裁）
• Arbitration（仲裁）