




















支付系统的核心逻辑藏在Authorization与Capture的设计细节中。本文深度解析信用卡交易的两种处理模型,从0元授权到增量授权,从拒付保护期到多次Capture的实现,带你穿透Visa/Mastercard规则迷雾,掌握支付系统设计的底层逻辑。

在做收单系统、支付网关或风控,经常会遇到这些问题:
本篇从支付系统视角出发,一文带你理解Authorization和Capture。 Note:本人实际上Aggregator、ISO、MOR、PF、Payment Processor、Acquiring Bank都做,所以系统视角会兼容各种角色,和市场上单一业务的系统可能有所差别。
信用卡交易在卡组织体系中,本质上分为两种处理模型:
它们的差异,直接决定了Authorization、Capture、请款(Presentment)如何发生。
单信息交易的特点是:
常见于:
特点总结:
比较少,本篇不展开。
Visa / Mastercard 的 CNP(Card Not Present 无卡交易) 交易,绝大多数属于双信息体系。
其核心特征是:
第一步:Authorization(授权) 第二步:Capture / Presentment(请款)
授权和资金结算被严格拆分。
这也是后面所有复杂场景(预授权、增量授权、多次 Capture)的基础。
Authorization和Authorisation,美式英语和英式英语的区别,做跨境业务都是表示授权,这里引用Ayden的定义:
Authorization is the process of the card issuer(like Visa or Mastercard) verifying payment details and reserving the funds to capture it later.
在双信息体系中,任何 Capture 都必须基于一次成功的授权。
Authorization 的本质是:
下面是一个授权的流程图,在信用卡付款流程中,授权的链路非常长,整个过程需要在非常短的时间内同步完成。

最常见的授权形态:
限制规则:
0 元授权是一种非金融授权,特点是:
主要用于:
关键限制:
在Mastercard文档中Zero Amount Authorization能用在增量授权用来延长拒付保护期,实际使用中比较少,这里我就只截个图

Pre-Authorization 是授权的一种业务场景,不是独立交易类型。
典型行业:酒店、租车、航空、邮轮。
特点:
Pre-Authorization 本身仍然是 Authorization,区别在于Pre-Authorization的有效期更长(30天)。

当原授权金额不足时,可以发起增量授权,增加原始预授权的金额。
典型场景:
核心规则(非常重要):
当授权即将过期,但交易尚未完成时:
典型场景:
Reauthorization不能超过原始授权金额,Capture后不能再发起
在前面Mastercard的文档里面反复出现了这个词,这里面解释一下他是什么意思
从授权或预授权成功开始,在限定时间内完成 Presentment 的交易,发卡行不得仅因“授权过期(chargeback code:4808)”而发起授权相关拒付。注意这里仅保护授权类的4808拒付。
Mastercard 强调的是,授权拒付保护期而不是授权到 Capture 的时间
原因是授权成功后即使你尚未 Capture / Presentment持卡人仍可能向发卡行发起拒付
在双信息体系中:
这个概念要与授权冻结期区分开,一个是保护拒付,授权冻结期是冻结持卡人的金额,两者都是7天和30天,有相似之处
内容看Zero Amount Authorization部分。
在收单系统中,Capture 是一个非常关键的生命周期节点。
A payment that has been authorized by the payment processor must be captured to be completed. Capturing is the act of transferring the reserved funds from the shopper to the merchant.
Capture 表示:
一旦 Capture:授权生命周期结束
不允许:
收单行Capture和Presentment会同时存在,非收单行系统只会到Capture。

在真实收单行系统中:
模型是:
卡组织规则层面:
Mastercard / Visa:不支持普通电商场景下同一授权的多次 Capture
但在酒店、租车、航旅等特定行业模型中:
这里提供一个支付系统的思路:Capture接口上允许多次Capture,发Presentment文件的时候将Capture记录合并,对外就是支持多次Capture,对于卡组还是在一个请款文件中。
在 Mastercard Authorization Request 中:不存在一个显式的 “Multi Partial Capture” 参数
是否允许多次 Capture:由 Authorization 类型 + MCC + 行业规则 隐式决定
如果授权语义或行业不匹配:后续多次 Presentment 将面临拒付或合规风险
酒店场景:
电商场景:
订阅 / 延迟履约:
聚合支付系统:
如果你是收单行或支付系统,可以记住这几句话:
这一篇我们主要介绍了Authorization和Capture的业务,下一篇将介绍Reversal Refund Credit。
本文由 @Amour 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。