土法炼钢兴趣小组的算法知识备份

【金融科技工程】支付系统全景：收单、发卡、聚合、跨境、B2B、C2C

2026-04-22 · architecture · fintech · #payment #acquiring #issuing #card-scheme #unionpay #visa #mastercard #alipay #wechatpay #upi #pix #fednow

文章导航

分类入口
architecturefintech
标签入口
#payment#acquiring#issuing#card-scheme#unionpay#visa#mastercard#alipay#wechatpay#upi#pix#fednow

目录

“支付”是金融科技里最被滥用的词。有人说”我在做支付”，实际上是在写一个调用微信统一下单接口的 SDK；有人说”我们是支付公司”，实际上是在做网关路由加聚合清分；而真正面对卡组织、持牌拿清算号、和发卡行对账的团队，往往不在这种场合露面。前五篇我们把钱建模、把账记好、把幂等与事务做稳——从第六篇开始，我们开始搭真实的管道。

这篇文章不讲任何一条具体接口（那是 07–09 篇的事），目标只有一个：把”支付”这个词拆成一组互不重叠的工程子系统，让你在拿到一个支付项目时，能在十分钟内判断自己在整个链条的哪一环、上下游是谁、钱怎么流、谁承担费率、监管牌照在哪一端。读完你应该能回答以下问题：商户刷一笔 100 元的 Visa 卡，这 100 元在 T+0 到 T+2 之间经过了哪些机构？支付宝的”服务商”和 Stripe 的”payment facilitator”有什么区别？巴西 PIX、印度 UPI、美国 FedNow 为什么都在 2020 之后集中涌现？一个跨境 SaaS 订阅收款为什么比境内贵三倍？

读者画像：正在做或即将做支付对接的后端工程师、架构师，以及需要对支付链路做尽调的产品与合规同学。本文不讨论加密货币支付（留给第 14 篇）、不讨论证券清算（留给第 18 篇）。

本篇是第 06–10 篇”支付系统五连”的开篇，后续四篇会分别展开卡组织、中国两大钱包、支付网关、以及订阅计费。这五篇里每一篇都默认读者已经建立起本文的词汇体系——否则阅读时会频繁碰到”到底 Acquirer 和 Gateway 区别是什么”“PayFac 和 ISO 到底哪个承担 Chargeback”之类的概念混淆。

一、四个参与方与一条最短链路

1.1 谁在参与一笔支付

任何一笔非现金支付，本质上都是一方的负债减少、另一方的负债增加。钞票不跑，跑的是银行账簿上的数字，以及在各机构之间传递的报文。最小的参与者集合有四个：

发卡与收单之间，还有一个卡组织/清算网络（Card Scheme / Clearing Network）。它不开户、不放款，只做三件事：路由报文、制定规则、做轧差清算（Net Settlement）。银联、Visa、Mastercard、JCB、American Express、Discover 都属于这一层。更广义的清算网络还包括 CNAPS（中国）、Fedwire/FedNow（美国）、SEPA/T2（欧盟）、CHATS（香港）、FPS（英国）等——它们的角色等价，只是不走卡、直接走银行账户。

1.2 一条最短的卡支付链路

以”境内信用卡线下刷卡 100 元”为例，报文链路大致是：

sequenceDiagram
    autonumber
    participant C as 持卡人
    participant M as 商户 POS
    participant A as 收单行
    participant S as 银联
    participant I as 发卡行

    C->>M: 插卡/挥卡
    M->>A: 授权请求 (ISO 8583 0100)
    A->>S: 路由至卡组织
    S->>I: 转发授权请求
    I-->>S: 扣减可用额度,授权成功 (0110)
    S-->>A: 返回授权
    A-->>M: 打印小票
    Note over S,I: T+0 日终批量清算<br/>轧差净额
    S->>I: 清算文件
    S->>A: 清算文件
    I->>S: 净额划款 (via CNAPS)
    S->>A: 净额划款
    A->>M: T+1 入账 (扣除手续费)

这条链路在金融工程里被叫作“四方模式”（Four-Party Model）：持卡人—发卡行—卡组织—收单行—商户。“四方”指的是除卡组织之外的四个账户持有方之间的清结算关系。下文的”三方模式”则是 Amex/Discover/Diners 那种发卡=收单=卡组织的封闭体系。

在更复杂的现实里，还要加入几个次级角色：

一家”看起来简单”的支付公司，内部往往同时扮演 Processor + Gateway + PayFac 三个角色。拆角色比拆公司更能帮你理解链路。

1.3 授权、清算、结算：三件事不要混为一谈

初学者最常见的误解是把”授权成功”当作”钱到账”。实际上它们分属三个阶段：

阶段 中文 英文 发生时机 动作
授权 Authorization Auth 实时（<3s） 发卡行冻结额度，不扣款
请款/清算 Capture & Clearing Clearing 当日或 T+1 收单把授权兑现为应收
结算 Settlement Settlement T+1 ~ T+N 真实资金在行间划转

很多问题——比如”订单已支付但商户未入账”、“退款显示成功但卡单未返款”——都源于工程师没有区分这三个阶段。关于授权与请款的状态机细节，见第七篇《卡组织收单链路》。关于清算与结算的差别，见第十一篇《清算 vs 结算》。

一个常见的反例：电商大促前要对一大批订单做”预占”（锁库存+冻资金），然后次日再集中 capture。如果系统把授权当成”已收到钱”来入账，财务账面就会跑出一个巨大的虚增资产科目；等第二天 capture 失败（卡 3D 校验二次、额度变化、卡被挂失），出现大规模”已入账却收不到钱”的差错。正确的做法是：授权仅写应收 pending子账，capture 成功才转到应收 confirmed，对账时两者相减即为”在途授权”。这一模式见第 03 篇《复式记账工程化》。

1.4 一张容易被忽略的”报文版图”

工程上还需要区分报文的方向和强度。以一笔国际卡支付为例，同一笔业务可能涉及：

报文族 作用 协议 时效
Auth / AuthResp 实时授权 ISO 8583 / ISO 20022 acmt 秒
Reversal 冲正（前端超时后回滚授权） ISO 8583 0400 秒
Advice 单边通知（强制消费、脱机） ISO 8583 0120 秒
Capture / Presentment 请款单据 批量文件 日
Clearing File 卡组织日终文件 EDI / XML / ISO 20022 日
Settlement Instruction 央行/代理行指令 MT202 / pacs.009 日
Chargeback / Representment 争议 Visa Resolve Online / Mastercom 天–月
Fee Collection 手续费清算 卡组织日终 月

这张”报文版图”比单条链路图更能揭示为什么一个支付系统动辄数百个微服务——每一族报文都对应一组入出口适配器、一组幂等表、一组重试/补单任务。

更重要的是，这些报文族的失败模式完全不同：

一个成熟的支付团队对上述每一种失败模式都有独立的运营 SOP——这不是工程 bug，是业务常态。新手把”支付系统”当成一个服务，老手把它当成”十几个松耦合子系统的总和”。本篇之后的所有内容，都是在这张图上展开。

二、支付系统的分类维度

为什么要分类？因为”我做支付”这四个字在技术面试里等价于”我写 Java”——你必须进一步问是 Android、后端、安卓系统开发还是 JVM 本身。支付领域的分类至少有四个正交维度。

2.1 按角色：收单 / 发卡 / 聚合 / 开放平台

这是工程上最重要的切分，决定你要建什么系统、接什么上游、拿什么牌照。

一个团队在不同业务线可能同时扮演多个角色。例如 Stripe 在美国既是 PayFac（自己拿 MCC，把数万小商户挂在自己名下）、又是 Issuer（Stripe Issuing 发虚拟卡）、还在做 Acquirer（Stripe Payments 自营收单，不再依赖 Wells Fargo/Paymentech）。

2.2 按主体：C2C、C2B、B2B、B2C、G2C

类型 典型场景 技术特征 监管重点
C2B 零售购物、订阅 低笔均、高并发、瞬时性强 商户资质、无证经营
C2C 好友转账、红包 社交属性、小额、高频 反洗钱、收款方实名
B2B 对公结算、供应链 大额、低频、对账复杂 三流合一、发票
B2C 工资代发、保险理赔 批量、单边、准时性 代发限额、税务
G2C 社保、退税、低保 强可靠、批量、审计 财政专户、回单

这个分类会直接影响支付通道选择：C2B 小额走条码/快捷；B2B 大额必须走 CNAPS 的大额实时支付系统（HVPS）或跨境的 CIPS/SWIFT；G2C 政务支付几乎都走国库集中支付系统，不经过商业支付机构。

一个常被忽略的细分是 C2G（个人到政府）：税费、罚款、社保缴费。这类业务名义上是 C2B 的变种，但实际接入的是财政部的非税收入收缴管理系统（NSRCS）或各省的电子税务局，报文格式、对账方式与商业支付完全不同。承接 C2G 业务的机构需要单独的系统对接与资质，工程团队常常低估其复杂度。

另一个容易混淆的是 B2B2C：平台型业务（电商、打车、外卖）——平台从消费者收钱，再分账给商家。这在会计上是”收单+分账”的合成业务，技术上要求分账必须在清分完成之前确认，否则会出现”平台账上多一笔不属于自己的钱”的合规问题。支付宝/微信/银联都提供官方分账能力（如微信的”分账 API”），但很多项目为了灵活度自己在聚合层做分账，这需要持证合规。

2.3 按场景：线上 / 线下 / 跨境 / 订阅 / 秒级

“场景”这个维度最容易被工程师误解为”只是不同 UI”，实际上每一类对授权模型的要求截然不同：线下要求脱机授权能力（断网也能刷）、线上依赖强客户认证（SCA）、订阅必须区分 CIT（Customer Initiated）与 MIT 两种交易类型、跨境强制制裁筛查（OFAC/EU/UN Sanctions List）。不同场景叠加时（比如一个订阅服务在跨境 + 移动端扣款），合规复杂度几何级数上升，这是出海 SaaS 支付接入成本的主要来源。

2.4 按通道：卡组织 / 钱包 / 账户转账 / 实时支付

这是一笔钱实际走哪根管道的分类。下一章展开。

2.5 四个维度如何组合：一个真实需求的拆解

假设一个需求：“我们要做一个宠物医院连锁的收款系统”。按上述四个维度拆：

这个组合决定了后端系统至少需要：商户中心（合规入网与多通道绑定）、收银台前端（扫码 + SDK）、订阅系统（协议支付 + 账单）、对账中心（每通道一份）、资金清分（门店按日归集到总部）。光 C2B 条码一条线绝对不够。

一个更容易暴露问题的反例：“我们只用微信支付就好”——听上去简单，但微信支付本身不能覆盖跨境、不支持企业大额、不直接对接会计发票。当业务增长到一定规模，这些缺口都要补回来。所以在选型最初阶段就把四个维度分开考虑，比后期重构便宜得多。

三、四条主干通道与它们的工程差异

3.1 卡组织（Card Scheme）

代表：Visa、Mastercard、银联（UnionPay）、JCB、Discover、American Express。

特征： - 报文格式：境内外长期使用 ISO 8583（1987/1993/2003 版本），正在向 ISO 20022 迁移（Visa/Mastercard 计划 2025–2027 年完成关键报文迁移） - 授权与清算分离：授权实时、清算日终批量 - 四方模式（Visa/Master/银联）或三方模式（Amex/Discover/Diners） - 费率复杂：Interchange + Assessment + Acquirer Markup（见第六章） - 争议机制：拒付（Chargeback），持卡人可发起，商户须举证

工程挑战：EMV 芯片流程、3-D Secure、PCI-DSS 合规、PAN（卡号）脱敏与令牌化（Tokenization）、争议与差错处理——这些在第 07 篇《卡组织收单链路》展开。

卡组织的一个被低估的事实：它们同时是规则制定者。Visa Core Rules 是一本近 900 页的文档（每年两次更新），覆盖卡面设计、商户分类、争议流程、数据安全、跨境费率等全部维度。任何一家接入 Visa 的机构都要在合同里承诺遵守这套规则，并每年接受审计。所谓”Visa 规则工程师”是一个存在于大型收单方、发卡行的专职岗位——他们的工作是监控 Visa 规则变更、评估对自家系统的影响、在规则生效前完成适配。Mastercard、银联亦然。

3.2 钱包（Wallet）

代表：支付宝、微信支付、PayPal、Apple Pay、Google Pay、Grab Pay、Kakao Pay。

一个容易混淆的区分：

支付宝、微信这种”超级钱包”同时跨了多个形态：余额支付是半封闭；绑卡快捷是卡组织通道；银行直连是账户转账。这是第 08 篇《支付宝、微信支付接入》的主题。

一个容易被忽略的事实：在 iOS 上用 Apple Pay 里绑定的某张招商银行 Visa 卡在 Costco 刷卡时，表面像”一个钱包”，底层发生的事情是：

  1. 手机安全元件（Secure Element）里存的不是真实 PAN，而是 DPAN（Device PAN，一张绑定设备的”影子卡号”）
  2. 由 Visa Token Service（VTS）维护 DPAN ↔︎ PAN 映射
  3. 每笔交易还会生成一次性密文（Cryptogram）作为 CVV 的替代，发卡行验证后才授权
  4. 报文格式仍是 ISO 8583，收单行看到的是 DPAN、发卡行拿到映射后查到真实 PAN

这套机制让持卡人遗失手机远不如丢失实体卡严重——DPAN 可以单独注销，而 PAN 不动。工程上，钱包类产品的核心竞争不在 UI 而在 TSP 资质：支付宝/微信要成为 Visa/Master/银联的 TSP 才能在线下受理端直接出 DPAN，否则每笔都要回源真实卡号。

3.3 账户转账（Bank Transfer / ACH）

代表：美国 ACH、欧盟 SEPA、中国网银互联/超级网银、日本 Zengin。

特征： - T+1 到 T+2 批处理，成本极低（美国 ACH 平均 $0.2–$0.5/笔） - 可撤销（美国 ACH 有 60 天退回窗口） - 无持卡人概念，直接基于银行账号 + 路由号

典型应用：工资代发、B2B 对公、保险定投、美国订阅的首选（因为卡费率太高）。中国的”代收代付”协议、ACH debit 就属于这一类。

两个子概念对工程选型有影响：

3.4 实时支付（Instant Payment / Faster Payment）

代表：中国 CNAPS IBPS、英国 FPS、印度 UPI、巴西 PIX、新加坡 FAST、欧盟 SCT Inst、美国 RTP（TCH）/ FedNow、泰国 PromptPay。

系统 上线年份 运营方 典型单笔限额 2025 日均笔数（公开数据）
FPS（英国） 2008 Pay.UK £1,000,000 ~1 千万
CNAPS IBPS（中国） 2010 中国人民银行清算总中心 ¥5,000,000（行间） ~1 亿
IMPS（印度） 2010 NPCI ₹5 lakh ~千万级
FAST（新加坡） 2014 ABS S$200,000 百万级
UPI（印度） 2016 NPCI ₹5 lakh（部分 ₹1 lakh） >5 亿
SCT Inst（欧盟） 2017 EPC €100,000（2024 提升至无上限） 数千万
PIX（巴西） 2020 Banco Central do Brasil 无硬性上限 >2 亿
RTP（美国） 2017 The Clearing House $10M 百万级
FedNow（美国） 2023 Federal Reserve $500k（2024 提至 $1M） 起步阶段

这一代系统的共性是：7x24、秒级到账、推送（credit push）为主、以手机号/ID 作为别名（UPI 的 VPA、PIX 的 Chave、PromptPay 的手机号）、不可撤销（反欺诈靠事前）。它们的兴起直接挤压了卡组织在本土 C2B 场景的份额——巴西 PIX 在上线 18 个月内超过了借记卡交易笔数。

工程侧要处理的新问题：幂等必须绝对可靠（不可撤销意味着重复转账无法 reverse）、反欺诈前置（授权窗口只有几百毫秒）、Mule Account 对抗（PIX 上线后诈骗从 6% 涨到巴西央行干预水平）。

四、中国收单体系

4.1 四方模式与银联的清算地位

中国境内的卡支付同样是四方模式，但卡组织层长期由中国银联一家垄断，直到 2020 年后 Mastercard NUCC、Visa/Connect（与网联合作） 陆续获得筹建/开业许可，但份额可以忽略。网联清算有限公司（NetsUnion Clearing Corporation，2017 年成立）承担的是非银行支付机构网络支付清算——也就是支付宝、微信支付的网络支付不再直连银行，而是统一走网联。

因此今天中国境内一笔 C2B 扫码支付的真实链路是：

用户微信/支付宝 -> 微信/支付宝(支付机构) -> 网联 -> 用户绑定银行
                                                      或
                                             -> 商户结算银行

而境内一笔银行卡支付是：

持卡人 -> 发卡行 -> 银联 -> 收单行/收单机构 -> 商户

两条链路的清算组织不同（一个网联、一个银联），这是”支付机构”与”银行卡收单”分业的结果。

这里有一个容易误解的点：“网联” != “银联”。银联是 2002 年成立、服务于银行卡清算的卡组织（Bankcard Clearing Organization），业务本质是 ISO 8583 报文路由 + 轧差清算；网联是 2017 年成立、服务于非银支付机构网络支付清算的平台，本质是让支付宝/微信等支付机构与银行的资金往来集中可监管。两者今天在业务上互不重叠，是中国支付清算”双线并行”结构的制度产物。境外卡组织（Visa/Master）入华的牌照是”银行卡清算机构”——对标的是银联，不是网联。

4.2 条码支付：C 扫 B 与 B 扫 C

两种条码方向在合规与风控上差别很大：

维度 C 扫 B（用户扫商户码） B 扫 C（商户扫用户码）
发起方 用户 商户
典型场景 小店贴纸、自助售货 连锁超市收银台
认证 通常静态码 + 小额免密 动态码（付款码）+ 18 位令牌
风控 商户侧低，监管限单笔 500 元静态码 用户侧强，付款码 1 分钟刷新
争议 用户错扫难追 商户刷错可撤销

《条码支付业务规范（试行）》（PBOC 2017/296 号文）对静态码单日累计、动态码单笔均有限额规定，具体数值以最新文件为准。

2023 年人行出台《关于进一步规范支付条码使用管理的通知》，把个人收款码禁止用于经营性收款（即通过”个人二维码”跑店铺收银的行为）。工程上这意味着：

这一条文直接影响了数百万小微商户的收银方式——他们不得不从”微信/支付宝个人码”迁移到”收钱吧/云闪付商户码”，才能持续经营。这是工程与监管共振的一个典型例子：不是技术推动业务，而是政策推动工程。

4.3 备付金集中存管

2017 年起，人民银行要求非银行支付机构备付金 100% 集中交存人民银行（经过 2017/2018/2019 三轮比例提升至 100%）。这是支付行业一次近乎洗牌的政策：在此之前，支付机构可以把备付金在多家银行铺开拿议价利息（俗称”吃利差”）——这是许多早期支付公司的主要利润来源。集中存管之后：

4.4 支付机构分类与牌照（示意，非法律意见）

“支付业务许可证”即俗称的”支付牌照”，业务类型通常分为：

2024 年《非银行支付机构监督管理条例》实施后，业务被重新归并为储值账户运营与支付交易处理两大类，牌照续展与新设审查收紧。工程团队接入时关注的是”对方是否具备本业务所需的牌照类型”——例如跨境人民币业务还需跨境外汇支付试点资质。

4.5 中国境内典型费率

业务 费率（近似） 备注
借记卡 POS 0.5% “96 费改”后不封顶，但竞争压到此水平
贷记卡 POS 0.6% 含发卡行+银联+收单
扫码支付（含微信/支付宝/银联云闪付） 0.38%–0.6% 通常 0.38% 起，小微商户补贴至 0.2%
特殊商户（公益、缴费） 0 或封顶 公益类零费率
B2B 对公大额 按笔，5–35 元 走大额系统或超级网银

“96 费改”指 2016 年 9 月 6 日发改委/人行联合发文取消刷卡手续费行业分类、改为发卡行服务费+网络服务费+收单服务费三段制，这是中国费率结构国际化的关键节点。

4.6 中国支付监管的三个重要节点

读懂今天中国支付行业的结构，必须理解三个关键政策节点：

  1. 2010 年《非金融机构支付服务管理办法》（人行 2 号令）：首次明确”支付机构”这一非银行金融概念，开始发放支付牌照。在此之前，支付宝、财付通的法律地位处于灰色地带。
  2. 2017 年”断直连”：《关于将非银行支付机构网络支付业务由直连模式迁移至网联清算平台处理的通知》（银支付〔2017〕209 号），要求支付宝、微信等对接银行的网络支付业务全部迁移到网联。这一刀把”支付机构绕过清算”的路堵死，所有跨行资金必须经过央行体系。
  3. 2024 年《非银行支付机构监督管理条例》：首部针对支付机构的行政法规，取代 2010 年的部门规章。把业务类型从”五类”（互联网、银行卡收单、预付卡、数字电视、移动电话）重构为”两类”（储值账户运营、支付交易处理），牌照续展、股东穿透审查、反垄断条款都大幅收紧。

这三个节点的共同主线：让央行可以看到每一笔跨行支付，且能对每一家支付机构实施穿透监管。工程上的一个直接后果是：支付机构的报表、对账、风控日志都必须满足”监管可直接下载”的格式规范（SCPCP 监管报送），这是业务系统设计时就要预留的输出接口。

历史类比：美国 1974 年的 EFTA（Electronic Fund Transfer Act）、欧盟 2007 年的 PSD1 → 2015 年 PSD2、新加坡 2019 年的 Payment Services Act，都是以十年为周期的大监管节点。一个支付工程师在十年职业生涯里，大概率会经历至少一次”全行业重构以配合新法规”的工程浪潮。理解这一点，才不会把每次法规升级当成”临时任务”——它们就是本行业工作节奏的基线。

4.7 中国数字人民币的位置

数字人民币（e-CNY）由人民银行发行，属于 CBDC（央行数字货币）。它不是一条新的支付通道，而是法定货币的数字形态——定位类似现钞，而非”新款支付宝”。工程接入形式通常是：

在本篇的”通道”分类里，数字人民币属于一种介于”钱包”和”央行清算”之间的新通道。第 14 篇《数字人民币、稳定币与 CBDC》专门展开。对本篇读者，记住一点即可：今天所有”接数字人民币”的项目，都仍通过 6+2 运营机构接入，不是直接对接央行。

五、国际收单体系

5.1 Visa/Mastercard 的四方模式

与中国结构相似：持卡人—发卡行—卡组织（Visa/Master）—收单行—商户。不同在于：

5.2 Amex/Discover 的三方模式

American Express、Discover、Diners Club 是三方模式（Three-Party Model）的代表：卡组织即发卡行即收单行。商户直接与 Amex 签约，Amex 既收费率又自己出账。

工程差异： - 无 interchange 概念，费率以一个数字呈现（通常 2.5%–3.5%，高于 Visa/Master） - 商户受理率低：美国约 80% 商户受理 Visa/Master，但只有 ~65% 受理 Amex - Amex 报文历史上走自有网络，近年通过 “OptBlue” 项目让 Fiserv 等大收单商代为受理，才普及到中小商户

一个常被追问的问题：“为什么 Amex 费率更高却在欧美商户那里难以推开？”原因有三：

  1. 费率高→商户排斥：餐饮、小零售看到 3.5% 会拒收 Amex
  2. 争议处理比 Visa/Master 更偏持卡人：Amex 的 Chargeback 成功率对商户不友好
  3. 地域覆盖：欧盟 IFR 压低了 Visa/Master 借记/信用费率，但 Amex 因为是三方不受 IFR 约束，反而差距拉得更大

但在高端 B2B、差旅、企业采购场景，Amex 反而强势——原因是积分返现体系、对公账户能力、以及 T&E（Travel & Entertainment）差旅平台的深度整合。这说明卡组织的选择同时是业务分层的选择。

5.3 Interchange++ 费率结构

国际收单标准报价形式：

总费率 = Interchange + Assessment + Acquirer Markup
         (发卡行得)  (卡组织得)   (收单方得)

欧盟 EEA 区内受 IFR（Interchange Fee Regulation，2015/751）管制，借记卡 interchange 不得超过 0.2%、信用卡不得超过 0.3%——这是欧盟卡支付费率远低于美国的直接原因。

5.4 典型商户的实际到账

某美国电商收一笔 $100 Visa 信用卡：

$100.00  消费者刷卡
- $2.00  Interchange (发卡行)
- $0.14  Assessment (Visa)
- $0.60  Stripe Markup
- $0.30  固定手续费
----------
= $96.96  商户 T+2 到账

这个三位数字的”消失”是跨境 SaaS 的主要成本来源。

5.5 Interchange 表的结构

真正让费率”听上去一个数字但实际几百档”的是 Interchange Table。下面摘录 Visa 美国 2024 年表格的示意结构（实际表格见 Visa 每年 4 月/10 月公布的 PDF）：

大类 典型档位 费率（示意） 触发条件
CPS Retail Visa Signature 2.10% + $0.10 线下、签名、普通信用卡
CPS Retail Visa Signature Preferred 2.40% + $0.10 高端联名
CPS Retail Debit Regulated 0.05% + $0.22 Durbin 法案下的大行借记
CPS Retail Debit Exempt 0.80% + $0.15 小行借记、未受 Durbin 约束
CPS e-Commerce Basic 1.80% + $0.10 基础在线
CPS e-Commerce Preferred 2.40% + $0.10 高端卡 + 3DS 强认证
EIRF / Standard Penalty 2.95%+ 未满足 CPS 条件（缺地址、迟请款）

工程含义：如果你没把地址、3DS、请款时效、MCC 正确落在报文里，费率会自动被降到 EIRF/Standard 档，每一笔多掏近 1%。一家跑在 Stripe/Adyen 之上的商户通常感知不到这种降档，但一家直连收单的持牌机构，必须在网关层做 “Interchange Optimization”——检查每一笔报文字段、尽量触发最低档。

5.6 Durbin 修正案与欧盟 IFR 的工程差别

这是为什么同一款 Shopify 插件在欧盟、美国、中国的费率配置模块差别巨大——不是工程师任性，是监管差别。

六、聚合支付：PayFac、ISO、Gateway 的本质区别

“聚合支付”是一个被过度使用的词。工程上更准确的分类是：

6.1 三种身份

身份 英文 是否持牌 资金是否过手 商户合同 典型
Gateway Payment Gateway 不需要 不过手 商户直接签收单行 Authorize.Net、早期 2Checkout
ISO Independent Sales Organization 注册 ISO 不过手 商户签收单行，ISO 代销 中国早期外包服务商
PayFac Payment Facilitator 需要（MCC/NMI） 过手 商户签 PayFac，PayFac 签收单行 Stripe、Square、Adyen for Platforms

PayFac 是 2014 年之后最重要的商业模式创新。在此之前，一个小商户要接受卡支付，需要收单行尽调 2–4 周、开 MID（商户 ID）、签合同。Stripe 的做法是：自己拿一个主 MID，然后给每个下级商户分配 sub-merchant ID，收单行只认 Stripe，对 Stripe 尽调一次就够；Stripe 对下级商户做”轻尽调”、自己承担欺诈与 Chargeback 风险。这把接入时间从”数周”压到”数分钟”，是 Stripe 崛起的核心。

代价：PayFac 要 自己合规（PCI-DSS Level 1、Card Scheme Payment Facilitator Program）、自己风控、自己承担代理商户的所有争议与洗钱责任。Adyen、Stripe、Square、Braintree、Checkout.com 都是持牌 PayFac。

6.2 中国的”聚合支付”

中国 2015–2017 年集中出现的聚合支付公司（收钱吧、哆啦宝、美团收银等）绝大多数不持支付牌照，只做聚合二维码 + 对账。人民银行 2017 年《关于开展违规”聚合支付”服务清理整治工作的通知》（银办发〔2017〕45 号）明确：聚合支付不得沉淀资金、不得代替持牌机构从事核心支付业务，只能以技术服务商身份存在。这一条是今天所有中国聚合公司必须守住的合规边界。

真正想做”资金过手”的，必须收购或自建一张持牌（例如乐刷、连连、国通星驿），这时它就不再是聚合公司，而是持牌收单机构。

6.3 典型平台速览

6.4 一个简化的商户入网数据模型

不论哪种聚合/收单身份，商户入网（Merchant Onboarding）数据模型都是系统的核心。下面是一个脱敏示意：

CREATE TABLE merchant (
    id             BIGINT PRIMARY KEY,
    legal_name     VARCHAR(256) NOT NULL,
    brand_name     VARCHAR(256),
    country        CHAR(2) NOT NULL,
    mcc            CHAR(4) NOT NULL,        -- 商户类别码
    business_type  VARCHAR(32) NOT NULL,    -- individual/company/ngo
    tax_id         VARCHAR(64),             -- 中国统一社会信用代码 / EIN / VAT
    status         VARCHAR(16) NOT NULL,    -- draft/kyc/active/frozen/closed
    risk_level     SMALLINT NOT NULL,       -- 1-5
    created_at     TIMESTAMP NOT NULL,
    UNIQUE (country, tax_id)
);

CREATE TABLE merchant_settlement_account (
    merchant_id    BIGINT NOT NULL REFERENCES merchant(id),
    currency       CHAR(3) NOT NULL,
    bank_country   CHAR(2) NOT NULL,
    bank_id        VARCHAR(32) NOT NULL,    -- SWIFT/BIC 或联行号
    account_no     VARCHAR(64) NOT NULL,    -- 存密文或令牌
    account_name   VARCHAR(256) NOT NULL,
    PRIMARY KEY (merchant_id, currency)
);

CREATE TABLE merchant_channel_binding (
    merchant_id    BIGINT NOT NULL,
    channel_code   VARCHAR(32) NOT NULL,    -- unionpay/visa/alipay/wechat/sepa
    sub_mid        VARCHAR(64) NOT NULL,    -- 收单行分配的 MID / 支付宝子商户号
    fee_template   VARCHAR(32) NOT NULL,
    effective_from DATE NOT NULL,
    PRIMARY KEY (merchant_id, channel_code, effective_from)
);

CREATE TABLE merchant_kyc_document (
    merchant_id    BIGINT NOT NULL,
    doc_type       VARCHAR(32) NOT NULL,    -- business_license/id_card/director_list
    doc_hash       CHAR(64) NOT NULL,       -- 存 OSS 的加密对象哈希
    review_status  VARCHAR(16) NOT NULL,
    reviewed_by    BIGINT,
    reviewed_at    TIMESTAMP,
    PRIMARY KEY (merchant_id, doc_type)
);

几个容易被初学者遗漏的字段：

Rolling Reserve（风险准备金）是跨境收单的标配：收单方从商户每笔结算里扣留 5%–10% 冻结 6 个月，用于覆盖后续 Chargeback。这个机制必须在数据模型里一开始就预留。

6.5 PayFac 模式下的一笔资金走账

以 Stripe 为例，一笔 $100 交易在 PayFac 模式下的资金账本变动大约是这样（简化示意）：

T+0  持卡人:        Cash $100         →   Stripe Holding Acct
     发卡行:        Liability +$100
     Stripe 内部：  创建 Charge 对象，状态 = succeeded

T+0  Stripe 账簿：
       借  Merchant Sub-account (sub-merchant M123)  +$100
       贷  Acquirer Clearing Account (Wells Fargo)   +$100

T+0  Stripe 内部计费（异步）：
       借  Platform Fee Receivable (from M123)       +$3.20
       贷  Stripe Revenue - Processing Fee           +$3.20

T+1  结算批次：
       借  Acquirer Clearing                         -$100
       贷  Stripe Operating Account (WF)             +$100

T+2  Payout 到商户：
       借  Merchant Sub-account M123                 -$100
       贷  Platform Fee Receivable                   -$3.20
       贷  Merchant Bank Account (via ACH)           -$96.80

这张账让一件事清晰：PayFac 的核心能力不是网关，而是自己的账本（Ledger）。每一个下级商户在 Stripe 内部都是一个子账户，Stripe 对每个子账户做复式记账、做 Payout 安排、做 Chargeback 计提。没有这套账本，PayFac 模式跑不下来。Stripe 自己把这套系统公开叫 “Stripe Sigma” / “Stripe Connect”，内部核心仍是第 03–05 篇所讲的复式记账 + 幂等事务。

6.6 Chargeback 与争议流程的金融本质

最后补一个容易被非支付工程师低估的话题：Chargeback 的成本为什么那么高。

一笔 Chargeback 的链路：持卡人向发卡行投诉 → 发卡行发起 Chargeback → 卡组织转发到收单行 → 收单行通知商户举证 → 商户提交 Representment → 卡组织仲裁 → 如商户败诉进入 Pre-Arbitration → Arbitration。整个流程可持续 30–120 天。

对商户的实际成本：

结论：Chargeback 不是”退款的贵一点版本”，它是一个独立的业务风险维度。持卡人友好的法律环境（美国 Reg E / 英国 FCA / 欧盟 PSD2）使 Chargeback 成功率对商户更不利。成熟的 PayFac/聚合方会用两种方式对冲：事前欺诈拦截（3DS / 设备指纹 / 规则引擎） 与 事后代举证服务。后者通常由 Ethoca / Verifi 等 Visa/Master 旗下公司提供——在争议真正上升到 Chargeback 之前，让商户有一次退款协商的机会，叫做 RDR（Rapid Dispute Resolution）。

这些机制在第 07 篇《卡组织收单链路》还会深入展开。本篇读者只需要记住：选收单/聚合方时，除了费率，还要问”Chargeback 代举证是否包含”以及”VDMP/MATCH 风险是否预警”。这两个问题能直接区分出成熟与非成熟的合作伙伴。

七、实时支付浪潮：为什么 2020 后集中涌现

7.1 共同的驱动力

2008 英国 FPS、2014 新加坡 FAST、2016 印度 UPI、2017 欧盟 SCT Inst、2020 巴西 PIX、2023 美国 FedNow——不是巧合，是三个技术与政策条件同时成熟的结果：

  1. ISO 20022 XML/JSON 报文标准成熟，使得多银行/多币种之间的语义互通成为可能
  2. 央行或行业联盟愿意自建基础设施，不再把实时支付交给卡组织（后者天然倾向于保护既有四方模式利润）
  3. 移动互联网普及让”别名支付”（以手机号、身份证号、邮箱作为账号代理）变得可用

除了技术与市场因素，还有一个更底层的驱动力：地缘与货币主权。跨境卡组织（Visa/Master）本质是美元体系的支付基础设施，而许多新兴经济体在过去十年意识到——如果本国高频小额支付仍然依赖 Visa/Master 轨道，就意味着费率、数据、规则都受制于他国。巴西央行在 PIX 上线时的官方定位就是”降低支付体系对外部的依赖”。印度 UPI、俄罗斯 Mir、中国网联+数字人民币也有类似的战略意图。这也是为什么过去五年”央行支付系统”成为全球政策学术研究的热点——它从技术议题演变成了金融主权议题。

7.2 印度 UPI 的架构要点

UPI（Unified Payments Interface）由 NPCI（National Payments Corporation of India）于 2016 年推出。工程上它的关键创新：

结果：2024 年月交易额超 $2 万亿卢比等值，远超卡支付。2024 年 NPCI 开始推进 UPI 跨境互联（新加坡 PayNow、法国、阿联酋）。

UPI 带来的行业冲击远超支付：在它上线前，印度支付市场由 Visa/Master/RuPay + Paytm 钱包主导；5 年后几乎所有 C2B/C2C 都跑在 UPI 上，传统卡组织份额被腰斩。这也解释了为什么 Visa/Mastercard 对新兴市场的”央行主导实时支付”既要合作（加入基础设施）又要警惕（可能被替代）。印度经验已被尼日利亚（NIBSS Instant Payment）、南非、肯尼亚等国参考。

7.3 巴西 PIX 的架构要点

PIX由巴西央行（BCB）2020 年 11 月推出，架构与 UPI 类似但由央行直接运营（而非行业联盟）：

上线 18 个月超越借记卡，2025 年月笔数超 50 亿笔。副作用是诈骗激增，催生了 MED（Mecanismo Especial de Devolução）——PIX 专属的追回机制，以及 PIX Infração（欺诈标记 API）。

PIX 相对 UPI 在工程上更成熟的一点是央行直接运营 DICT（别名目录服务）：所有”手机号 → 账户”的查询经过央行授权与限速，有统一的隐私与反滥用约束。UPI 的等价能力由 NPCI 与各 PSP 共同维护，历史上多次出现”PSP 被撞库攻击导致别名泄露”的事件。中国目前没有央行级 Directory（主要原因是实名制与卡号体系已足够精确），但学术界与行业也一直在讨论”是否需要一套手机号 → 账户的全国目录”。

7.4 美国 FedNow 与 RTP 的双轨

美国是发达国家里实时支付最晚落地的之一。两个系统并存：

两者都基于 ISO 20022，单笔上限 $1M，7x24 秒级。但美国实时支付的推广远慢于 UPI/PIX，主要因为： - ACH + 卡组织已经足够成熟，无强驱动力 - 商户习惯 T+2 批量 - Venmo/Zelle/Cash App 已经满足了 C2C 即时体验（虽然背后走 ACH/卡）

一个常被问到的问题：Zelle 是实时支付吗？答案是”用户感知是，技术底层不是”。Zelle 背后的 EWS（Early Warning Services）是大行联盟，用户侧看到”秒到账”，但行间清算仍走 ACH（T+1）。这类”前端伪实时、后端批处理”的架构在美国非常普遍，与 IBPS 是同一思路。真正的 RTGS 式实时只有 RTP 和 FedNow。

7.5 中国 CNAPS IBPS

IBPS（Internet Banking Payment System，网上支付跨行清算系统）是 CNAPS 下的子系统，2010 年上线，支撑小额实时跨行支付（5 万元以下早期，现多数行提升至 100 万），7x24。超级网银（业务品牌）就是它的用户侧封装。

今天中国用户感知到的”秒到账跨行转账”几乎都是 IBPS 或大额实时支付系统（HVPS）（50 万以上，工作日运营）承载。IBPS 相对国际同类起步早，但别名支付（手机号转账）的推广受限于中国不存在 UPI/PIX 式的强制央行 Directory——各行付款人仍需要输入卡号或账号。

一个容易被混淆的事实：“秒到账”不等于”清算完成”。IBPS 是”双边预授信”机制——行 A 看到 IBPS 授信额度充足就先记给用户”到账”，真正的行间轧差清算在日终才完成。对用户是秒级体验，对央行账本则仍是批处理。这一机制让 IBPS 能 7x24 不间断运行而不必求助实时的行间清算（RTGS）。第 11 篇会详细讲”到账”与”清算”的差别。

关于央行支付系统的深入内容，见第 12 篇《央行支付系统》。

7.6 一个真实的 PIX 反欺诈事件

2021 年 10 月巴西央行披露 PSafe 安全公司的报告：一个攻击团伙通过社工骗得某 PSP 的员工凭证，调取了约 16 万条 PIX 注册别名（Chave）信息，用于定向诈骗。央行随后：

  1. 上线 PIX Infração API：任何金融机构发现可疑交易可 72 小时内标记
  2. 上线 MED（Mecanismo Especial de Devolução）：受害人可请求资金冻结最长 72 小时，由接收方银行协助退款
  3. 要求所有 PIX 参与机构对”别名-账户”查询接口实施强限速与日累计审计

工程教训：实时支付系统一旦上线，反欺诈能力必须同步上线——否则诈骗成本远低于收益，会在短期内把新系统推入”不可用”的舆论危机。国内同业也有类似教训，参见 IBPS 与支付宝/微信早期红包诈骗专项治理。

七之二、B2B 与跨境的几个特殊点

虽然完整的跨境支付留到第 13 篇，但在”支付全景”这篇里不能不提几个对工程选型有决定性影响的概念。

7.7 代理行、Nostro 与 Vostro

跨境汇款的底层事实是：没有一张全球的银行账户网。B 银行在 A 国没有账户，A 银行在 B 国也没有账户，所以它们要互相开账户——

一笔跨境汇款 = 我在你那边的 Nostro 账户扣账 + 你在我这边的 Vostro 账户记账，两边对齐，SWIFT MT103 只是报文承载。工程上，Nostro 账户余额不足是跨境系统最常见的失败原因之一——余额在另一个机构那里，不是实时可查的。

7.8 SWIFT gpi 与 ISO 20022 迁移

SWIFT 从 2017 年推出 gpi（global payments innovation）：给每笔跨境汇款一个 UETR（Unique End-to-end Transaction Reference），使汇款全程可追踪，类似快递单号。今天主要国际银行的大部分 MT103 都带 UETR。

2022–2025 年 SWIFT 推进 MT-to-MX 迁移：把 MT 系列（MT103/202）迁移到基于 ISO 20022 XML 的 pacs.008 / pacs.009 / camt.052。2025 年 11 月是关键节点（MT 与 MX 共存期结束）。工程影响：

7.9 CIPS：人民币跨境的专用通道

CIPS（Cross-border Interbank Payment System，人民币跨境支付系统）2015 年上线（一期）、2018 年二期扩容，运营方为中国人民银行清算总中心。它的定位：

对出海企业的意义：人民币跨境不一定要走 SWIFT，部分对手方可以通过 CIPS 直接清算，成本更低、时效更快。但要走 CIPS，需要结算银行具备 CIPS 直参或稳定的间参通道。

八、支付方式决策树

对接支付前，先判断自己的业务落在哪个通道组合。下图是一个简化决策树：

graph TD
    Start[一笔支付需求] --> Q1{金额区间?}
    Q1 -->|< 1万元| Q2{跨境?}
    Q1 -->|1 万 - 100 万| Q3{跨境?}
    Q1 -->|> 100 万| Q4{跨境?}

    Q2 -->|境内| S1{场景}
    Q2 -->|跨境| X1[Visa/Master + 3DS<br/>或 PayPal/Stripe]

    S1 -->|线下零售| C1[条码扫码<br/>支付宝/微信/云闪付]
    S1 -->|线上电商| C2[快捷支付/绑卡<br/>或聚合网关]
    S1 -->|订阅| C3[协议支付<br/>或卡 COF + MIT]
    S1 -->|C2C| C4[微信红包/支付宝转账<br/>或 IBPS]

    Q3 -->|境内| M1[IBPS 实时<br/>或企业网银]
    Q3 -->|跨境| M2[SWIFT MT103<br/>或 CIPS 人民币]

    Q4 -->|境内| L1[HVPS 大额<br/>工作时间]
    Q4 -->|跨境| L2[SWIFT + 代理行<br/>或 CIPS]

    classDef scene fill:#3fb950,stroke:#adbac7,color:#22272e
    classDef cross fill:#f0883e,stroke:#adbac7,color:#22272e
    class C1,C2,C3,C4,M1,L1 scene
    class X1,M2,L2 cross

这张图不穷尽，但覆盖了 95% 真实业务场景。在项目启动阶段，能画出这张图并在每个分支选定一个默认通道，就能避免大量”为什么我们不直接接 SWIFT”或”为什么订阅用条码”的伪问题。

九、一张完整的资金流图

下面这张 SVG 把本文涉及的角色串成一张资金流图（以境内 C2B 卡支付为例）。实线是资金流，虚线是报文流：

境内 C2B 卡支付：资金流（实线）与报文流（虚线）

持卡人 Cardholder 付款人账户

商户 Merchant 收款人账户

发卡行 Issuer 扣账 / 授信 反欺诈 / 额度

收单机构 Acquirer 商户结算 差错处理

支付网关 Gateway 路由/风控/令牌

卡组织 Scheme 银联/Visa/Master 路由 + 轧差清算

央行 CNAPS 行间净额划转 T+0 日终 / HVPS

① 下单/授权请求

② 送收单

③ 送卡组织

④ 送发卡行

⑤ 3DS/短信

⑥ T+0 发卡行入央行

⑦ T+0 央行出收单行

spacer

⑧ T+1 收单扣费 → 商户

资金流 报文流 ltl · 2026

看这张图的正确方式：报文（紫色虚线）路径与资金（绿色实线）路径完全不重合。报文实时、资金批量。这个”分离”是所有卡支付系统一致性问题（到账延迟、Chargeback、对账差错）的根源。

十、费率与成本速查

下面这张表把本文讨论过的几类通道的大致成本放在一起。实际费率因商户类型、地域、量级差异极大，仅供决策树参考。

通道 境内小额 境内大额 跨境 到账
条码扫码（中国） 0.2%–0.6% N/A N/A T+1
银行卡 POS（中国） 0.5%–0.6% N/A N/A T+1
Visa/Master 信用卡 2.0%–3.5% 同 2.5%–4% + FX T+2
Amex 三方 2.5%–3.5% 同 2.9%–4% + FX T+2
美国 ACH $0.2–$0.5 / 笔 同 N/A T+1/T+2
欧盟 SEPA €0.1–€0.3 同 欧元区内无加价 T+1
SCT Inst / PIX / UPI ~0（C2C） 视商户 正在试点互联 <10s
CNAPS IBPS / 超级网银 免 / 2–5 元 按阶梯 N/A 秒级
CNAPS HVPS N/A 按阶梯 N/A 分钟级
SWIFT MT103 N/A $15–$50 / 笔 + FX 2–5 天 T+2 ~ T+5
CIPS（人民币跨境） N/A 按阶梯 2–5 元 / 万 当日

一个有用的经验值：跨境电商收美元卡的综合成本 ≈ 3%（IC 2.0% + Scheme 0.13% + Acquirer 0.6% + FX spread 0.3%）。这是判断出海 SaaS 毛利时绕不开的数字。

十一、工程坑点

一、“授权成功 = 订单已付款”。授权只是冻结，真正扣款在 Capture 或日终清算。国际卡 7 天内未 Capture 授权自动释放——长订单（比如酒店入住预授权）要单独处理。

二、POS 离线冲正与网关超时不是一回事。离线冲正走 ISO 8583 0400/0420；网关超时是 HTTP/TCP 层。两层都要做幂等，第 09 篇展开。

三、“到账”有三种含义：发卡行扣账、收单行入账、商户银行账户到账。三个时间点都不同，对账系统必须分别落库。

四、Chargeback 的”隐藏成本”。Visa/Master 对 Chargeback 率 >1% 的商户进 Chargeback Monitoring Program，单笔 Chargeback 罚金 $15–$50 外加举证费。做跨境 SaaS 的团队要专门建一个 Chargeback 运营流程。

五、ISO 20022 迁移不是”XML 替换 8583”那么简单。字段语义扩展（如 Remittance Information、Structured Party Identification）意味着上下游字段映射、对账规则、风控规则都要改，是一个数年的工程，Visa/Mastercard 都在推进中。

六、实时支付的不可撤销性。PIX、UPI、FedNow 一旦到账，不走卡组织的 Chargeback 流程，只能通过事后协商或监管仲裁。反欺诈必须前置到授权阶段。

七、“支付机构”牌照的边界。聚合不过手、预付卡不得跨省、银行卡收单不得为无证商户受理——这些边界在合规审计时一条都不能踩。工程上要体现为商户入网白名单、资金清分规则、禁止某些 MCC。

八、T+0 提现不是免费的午餐。支付机构为了抢商户会默认 T+0，但其资金来自机构自有现金池垫付，不是真的清算提前。一旦机构流动性吃紧，“T+0 暂停”是首当其冲的动作。

九、MCC 不是自证清白的免死金牌。2020 年多家支付机构因为”真实商户做了 MCC 7995（赌博）业务、但报文里报的是 5411（超市）“被处罚（所谓”套码”）。工程侧要对 MCC 与交易特征做交叉校验（比如 5411 单笔不应超过 5000 元的某个阈值），并对突增 MCC 做报警。

十、跨境的”名字不对”问题。SWIFT 报文里的受益人名字拼写与实际开户名差一个字母（比如 SHANGHAI vs SHANG HAI），就可能被接收方合规系统扣住数天。这不是 bug 是合规流程，工程上要在 UI 层引导用户严格按账单上的名字填写，并记录任何修正。

十一、ISO 8583 的字段解释不是统一的。ISO 8583 是个框架，银联、Visa、Mastercard、各国央行清算都有自己的 “方言”（dialect）：同一个 Field 63 的定义可能完全不同。初次对接任何新网络时，必须索取对方的 Field Dictionary 文档，不要照搬其他项目的字段映射。

十二、Chargeback 与 Refund 不同。Refund 是商户主动发起，原路退回；Chargeback 是持卡人投诉发卡行强行退，费率不退，还扣违约金。商户系统必须区分两个状态，否则对账永远对不平。

十三、“通道覆盖”不是”商户覆盖”。某些聚合方宣称”覆盖 120 个国家”，实际上大多是通过一家欧洲收单 + 一家美国收单 + 一家亚洲收单拼出来的。不同地区的 Chargeback 标准、争议处理时效、合规门槛都不同，不要把”覆盖”当”开箱即用”。

十四、监管报送的抽取口径。很多团队把监管报送当成”跑一个 SQL 导出”。正确做法是：把报送需要的字段在业务落库时就打进交易表（MCC、商户实控人、终端序列号、IP、GPS），事后拼接成本极高且不准确。

十五、账户外挂的风险。历史上多起案例是”商户系统正常、但支付机构把某笔钱划到了非本商户的账户”（俗称”飞单”）。对账系统必须以商户银行账户明细为基准回溯，不只是信支付机构的对账单。

十六、时钟同步不是小问题。ISO 8583 报文里的 Transmission Date & Time（DE7）如果和清算主机差 >5 分钟，会被判定为重放攻击或异常报文。所有支付节点必须使用 NTP/PTP 严格同步，GPS 授时作为冷备。

十七、测试环境不反映真实故障。卡组织的沙箱只覆盖”正常/拒绝”两种分支，实际生产中会遇到”超时后补发授权”、“发卡行 stand-in（代授权）”、“部分 capture”等情况。没跑过几次真实生产演练（灰度到 0.1% 流量）之前，不要宣称系统可用。

十二、选型建议与落地清单

团队只做境内 C2B 电商：不用自己持牌，直接接微信/支付宝官方 + 银联云闪付，或选一家聚合（收钱吧/连连）。接入工程量约 2 人周。

团队做跨境 SaaS 或独立站：Stripe / Adyen / Checkout.com 三选一，按目标市场选。Stripe 开发者友好、Adyen 大客户价优、Checkout 中东亚太强。接入 1 人月，合规（PCI-DSS SAQ-A）半人月。

团队做 B2B 大额结算：直连企业网银 + 对公快捷（超级网银 IBPS）+ SWIFT（跨境），自建一套资金清分与对账，不用接卡组织。

团队做持牌自营：先明确要做收单还是发卡，接银联 UP 或卡组织测试环境走通 ISO 8583，建 PCI-DSS Level 1 合规，HSM 自建或租用，TMS 自建。这是 50 人 × 1 年起的工程。

团队做聚合/PayFac：中国境内合规压力最大，推荐收购一张牌照。国际上可以直接申请 Visa/Master 的 PayFac 资格，主 Acquirer 合作 + 下级商户轻入网。

不论哪种路径，以下清单一开始就要落下：

  1. 交易表 + 分录表双写，状态机清晰（引用第 05 篇）
  2. 幂等键从商户前端穿透到发卡行（引用第 05 篇）
  3. 金额使用 minor unit 整数（引用第 02 篇），绝不使用浮点
  4. 所有外部通道调用都有补单与异步通知（第 09 篇）
  5. 每日 T+1 通道对账，差错自动挂账（第 23 篇）
  6. 敏感数据（PAN、CVV）不落库，令牌化或直接不经过自己系统
  7. 费率与会计科目一开始就建表，别写死在代码里
  8. 商户资料与结算账户变更全流程留痕，支持任意时间回放
  9. 对接的每一个外部通道都要有独立的健康检查 + 熔断 + 降级路由
  10. 监管报送字段在交易时即落库，不依赖事后拼接
  11. 密钥使用 HSM 管理，测试与生产密钥物理隔离
  12. 一套标准化的”通道接入 checklist”，每条新通道按同样流程上线

上面这十二条是本篇最实用的一张清单——它们在下一篇（卡组织链路）与再下一篇（微信支付宝）里会一一被实现。

十三、两个真实对比案例

13.1 案例一：一个国内 SaaS 的全球订阅

某团队做 B2B SaaS，客户覆盖中国、东南亚、北美、欧洲。订阅金额 $30–$500/月。选型过程：

  • 境内：微信支付协议支付 + 支付宝周期扣款。费率 0.6%。必须落地境内主体，解决发票与结汇。
  • 东南亚：Stripe（覆盖 SG/MY/TH）或 Airwallex + 本地钱包（GrabPay、GCash）。综合费率 2.5%–3.5%。
  • 北美：Stripe 主力 + 备 PayPal（约 10% 用户偏好）。费率 2.9% + $0.30。
  • 欧洲：Stripe + SEPA Direct Debit（SaaS 订阅首选，费率 €0.35 封顶 vs 卡 1.5%）。
  • 资金回流：通过 Stripe Payouts → 香港公司银行账户 → 结汇到内地主体。需要做转移定价备案。

工程启示：一个出海项目实际上要接 4–5 条相互独立的通道，不能幻想”接一家全搞定”。

13.2 案例二：一个国内连锁餐饮的收银台

某连锁餐饮 500+ 门店，选型：

  • 主通道：银联云闪付 + 微信支付 + 支付宝 + 数字人民币，全部通过聚合方 A（持牌收单）接入
  • 硬件：自助收银机（B 扫 C 为主，扫用户付款码）+ 静态码兜底
  • 费率：聚合方给到 0.38% 综合，再按量级阶梯
  • 对账：T+1 下载聚合方的对账文件 + 各通道的独立对账文件（双路对账）
  • 差错：单笔差异先挂账，超过 3 天未平由运营人工介入

工程启示：即使聚合方能给一套 API，对账也必须双路。只信聚合方的对账单，一旦聚合方自己对账出错，下游商户会在最后一环承担损失。

13.3 案例三：一个跨境 B2B 贸易平台

某跨境 B2B 平台，中国卖家 → 海外买家（欧美中小企业），单笔货款 $1 万 – $50 万。选型过程经历了痛苦的迭代：

  • v1（错误）：使用 Stripe 收款 + Stripe Payout 到中国公司银行账户。结果：Stripe 对 “marketplace” 型资金池有严格限制，且跨境 Payout 到中国账户并非其核心路径，数月后账户被冻结审查。
  • v2（改进）：使用 Airwallex 的”全球账户”能力，给每个中国卖家在香港开一个虚拟 USD 账户，海外买家通过 SWIFT 或 ACH 打款过来。卖家再从 Airwallex 结汇到境内 RMB 账户。绕过 PayFac 模式。
  • v3（稳定）：在美元端接受 ACH（低费率，适合 B2B 大额），在欧元端接受 SEPA，在买家明确要卡支付的场景下才启用 Stripe。总体费率降到 1.2% 以下。

工程启示：B2B 大额跨境不要用 PayFac。PayFac 是为 C2B 小额高频设计的，面对 B2B 大额会被合规规则卡住。B2B 场景应回到”账户转账（ACH/SEPA/SWIFT）+ 虚拟账户”路线，接受 T+1/T+2 到账为代价换取低费率与可持续合规。

十四、与后续文章的衔接

这篇是”支付篇”的总纲，接下来四篇展开：

再往后是清算结算（11）、央行系统（12）、跨境（13）、数字货币（14）。本文建立的四方模型、通道分类、费率结构，是后续所有篇的基础词汇。

如果你只带一张图离开本文，应该是第九章那张”报文流 + 资金流”的 SVG。如果只带一句话，应该是：“支付”不是一种业务，而是二十种业务共享同一个词。厘清自己在哪一种里，是支付工程师的第一课。

参考资料

上一篇：《幂等、事务与一致性：SAGA、TCC、对账补偿》

下一篇：《卡组织收单链路：银联/Visa/Mastercard、ISO 8583、ISO 20022 迁移》

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / fintech

【金融科技工程】金融科技未来趋势与工程师路径

系列收官。从货币形态、即时支付、AI、隐私计算、DeFi、监管科技、云原生、后量子密码八大趋势出发，给出未来 5–10 年的工程判断；再给出从入门到专家的金融科技工程师成长路线，以及书单、论文、开源项目与 25 篇全景索引。

By .