惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Hugging Face - Blog
Hugging Face - Blog
量子位
H
Help Net Security
Microsoft Azure Blog
Microsoft Azure Blog
MongoDB | Blog
MongoDB | Blog
小众软件
小众软件
爱范儿
爱范儿
博客园 - 【当耐特】
Vercel News
Vercel News
S
SegmentFault 最新的问题
M
MIT News - Artificial intelligence
F
Fortinet All Blogs
Apple Machine Learning Research
Apple Machine Learning Research
GbyAI
GbyAI
博客园 - 叶小钗
博客园_首页
V
Visual Studio Blog
宝玉的分享
宝玉的分享
B
Blog
MyScale Blog
MyScale Blog
C
Check Point Blog
博客园 - 三生石上(FineUI控件)
L
LangChain Blog
V
V2EX

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
跨境支付入门(五):一文理解信用卡授权、预授权、增量授权...
Amour · 2026-01-30 · via 人人都是产品经理

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

在做收单系统、支付网关或风控,经常会遇到这些问题:

  • 0 元授权和预授权是什么?
  • 为什么 Capture 之后不能再发增量授权?
  • Mastercard 为什么强调“授权拒付保护期”,而不是 Capture 时间?
  • 多次 Capture 卡组织不支持,Stripe 又是怎么做到的?

本篇从支付系统视角出发,一文带你理解Authorization和Capture。 Note:本人实际上Aggregator、ISO、MOR、PF、Payment Processor、Acquiring Bank都做,所以系统视角会兼容各种角色,和市场上单一业务的系统可能有所差别。

一、 单信息与双信息:信用卡请求模型

信用卡交易在卡组织体系中,本质上分为两种处理模型:

  1. 单信息(Single Message System)
  2. 双信息(Dual Message System)

它们的差异,直接决定了Authorization、Capture、请款(Presentment)如何发生

1. 单信息交易(Single Message System)

单信息交易的特点是:

  • 授权与资金扣账在同一条报文中完成(专业术语叫Sale,卡组看到Purchase多一点)
  • 不存在独立的 Capture

常见于:

  • 借记卡
  • ATM
  • 部分本地卡组织网络

特点总结:

  • 实时扣款
  • 不支持预授权、增量授权
  • 不存在多次 Capture 的问题

比较少,本篇不展开。

2. 双信息交易(Dual Message System)

Visa / Mastercard 的 CNP(Card Not Present 无卡交易) 交易,绝大多数属于双信息体系

其核心特征是:

第一步:Authorization(授权) 第二步:Capture / Presentment(请款)

授权和资金结算被严格拆分。

这也是后面所有复杂场景(预授权、增量授权、多次 Capture)的基础。

二、 Authorization:所有 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 的本质是:

  • 发卡行冻结额度(冻结时间5-7天,取决于发卡行)
  • 卡组织记录授权状态
  • 为后续 Capture / Presentment 提供合法依据

下面是一个授权的流程图,在信用卡付款流程中,授权的链路非常长,整个过程需要在非常短的时间内同步完成。

1. 标准授权(Authorization)

最常见的授权形态:

  • 卡组0100 / 0110 报文
  • 指定确定金额
  • 用于立即或稍后 Capture

限制规则:

  • 授权一旦被 Capture原授权额度即被消耗
  • 不允许在 Capture 后再发起增量授权

2. 0 元授权(Zero Amount Authorization)

0 元授权是一种非金融授权,特点是:

  • 金额为 0
  • 不冻结额度

主要用于:

  • 卡有效性校验
  • 卡片状态检测
  • 绑定卡验证

关键限制:

  • 0 元授权不能直接 Capture
  • 必须重新发起一笔正式授权

在Mastercard文档中Zero Amount Authorization能用在增量授权用来延长拒付保护期,实际使用中比较少,这里我就只截个图

3. 预授权(Pre-Authorization)

Pre-Authorization 是授权的一种业务场景,不是独立交易类型。

典型行业:酒店、租车、航空、邮轮。

特点:

  • 授权时金额可能是预估值
  • 实际消费金额在后续确定
  • 允许在授权有效期内进行后续操作

Pre-Authorization 本身仍然是 Authorization,区别在于Pre-Authorization的有效期更长(30天)。

4. 增量授权(Incremental Authorization)

当原授权金额不足时,可以发起增量授权,增加原始预授权的金额。

典型场景:

  • 酒店延住
  • 租车超时
  • 航班改签

核心规则(非常重要):

  • 只能基于尚未 Capture 的授权
  • 一旦 Capture,不允许再发起 Incremental Authorization
  • 增量授权仍属于授权阶段,不是 Capture

5. 更新授权(Reauthorization/Authorization Update)

当授权即将过期,但交易尚未完成时:

  • 可以发起 Reauthorization
  • 用于延长授权有效期

典型场景:

  • 长周期服务
  • 延迟履约

Reauthorization不能超过原始授权金额,Capture后不能再发起

6. 授权拒付保护期(Authorization Chargeback Protection Period)

在前面Mastercard的文档里面反复出现了这个词,这里面解释一下他是什么意思

从授权或预授权成功开始,在限定时间内完成 Presentment 的交易,发卡行不得仅因“授权过期(chargeback code:4808)”而发起授权相关拒付。注意这里仅保护授权类的4808拒付。

Mastercard 强调的是,授权拒付保护期而不是授权到 Capture 的时间

原因是授权成功后即使你尚未 Capture / Presentment持卡人仍可能向发卡行发起拒付

在双信息体系中:

  • 授权本身就是一项被卡组织记录的交易行为
  • 超出保护期的授权,可能无法享受拒付责任保护

这个概念要与授权冻结期区分开,一个是保护拒付,授权冻结期是冻结持卡人的金额,两者都是7天和30天,有相似之处

7. 授权拒付保护期延展请求(Authorization Chargeback Protection Period Extension)

内容看Zero Amount Authorization部分。

三、 Capture:从授权到交易完成的系统分界点

在收单系统中,Capture 是一个非常关键的生命周期节点

1. 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:授权生命周期结束

不允许:

  • 增量授权
  • 更新授权

2. Capture 与 Presentment

收单行Capture和Presentment会同时存在,非收单行系统只会到Capture。

在真实收单行系统中:

  • Capture 是交易状态
  • Presentment 是文件行为

模型是:

  • 系统内记录 Capture 交易
  • 后续批量生成 Presentment 文件
  • 通过清算系统提交卡组织

3. 多次 Capture

卡组织规则层面:

Mastercard / Visa:不支持普通电商场景下同一授权的多次 Capture

但在酒店、租车、航旅等特定行业模型中:

  • 允许一次授权对应多次 Presentment(Multiple / Partial Clearing)
  • 每次 Presentment 生成独立 ARN

这里提供一个支付系统的思路:Capture接口上允许多次Capture,发Presentment文件的时候将Capture记录合并,对外就是支持多次Capture,对于卡组还是在一个请款文件中。

4. 是否需要在 Authorization 中声明支持多次 Capture?

在 Mastercard Authorization Request 中:不存在一个显式的 “Multi Partial Capture” 参数

是否允许多次 Capture:由 Authorization 类型 + MCC + 行业规则 隐式决定

如果授权语义或行业不匹配:后续多次 Presentment 将面临拒付或合规风险

四、 常见场景对照

酒店场景:

  • Pre-Authorization 冻结房费
  • Incremental Authorization 覆盖延时
  • Capture 在退房时一次完成

电商场景:

  • 标准授权
  • 立即 Capture
  • 单次 Presentment

订阅 / 延迟履约:

  • Authorization
  • Reauthorization 延期
  • 最终 Capture

聚合支付系统:

  • 内部拆分 Capture
  • 对外仍遵循卡组织一次 Capture 规则

总结

如果你是收单行或支付系统,可以记住这几句话:

  • Authorization 是一切的起点
  • Capture 是授权生命周期的终点
  • Capture 之后,不再允许任何授权类操作
  • Presentment 是文件,不是交易

这一篇我们主要介绍了Authorization和Capture的业务,下一篇将介绍Reversal Refund Credit

本文由 @Amour 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议。