hello，我是彬彬，见字如面。本篇全部选材于《支付结算设计方法》，全套9部37章超80w字，公众号首页加微可获取全集。

先问一个问题：一笔 30 块钱的咖啡，从用户点下付款，到商户真正能把钱提走，中间经过几个系统、几步动作？

多数人能答出前半段：收银台、交易、路由、渠道。后半段可能会模糊——清分做了什么、记账在哪一步、对账凭什么卡住出款、结算单和对账的关系是什么样。再往深一层问：这些模块里，哪个动作是真的在搬钱，哪个只是记了一笔账？能答清楚的人就明显少了。

很显然这不是理解能力的问题，是因为分工让我们各自只看到一段。做收银台的同学盯转化漏斗，做清结算的盯到账时效，做对账的盯差异率，每个人手上都只有自己那一段，整张的图纸可能大部分都在某些个资深专家的脑子里。

这些平时其实没什么问题，但我们打工人其实最怕的就是被贴上标签，做账户的做不了清结算，做交易的不懂账户，所以只要开始跨域，只懂自己那一段就不够了，这些问题可能就会成为自己上升路上的一道坎。行业现在说实话这么成熟，想了解材料一大把，主要还是看自己是否有心想要去深入。

所以这篇想做一件事：把支付结算这套系统，从产业链位置一直讲到跨境对照，用一条主线串起来。全篇一共8个部分，23张图。绝大部分来自我整理的《支付结算设计方法》，还有三张引自公开行业研究（产业链、跨境角色、跨境架构各一张），每一张都可以单独拿出来看。

先说明下本文的大纲顺序，可以对照着找自己感兴趣的

  • 01行业全景与产业链分层

  • 02支付怎么挣钱

  • 03架构设计

  • 04核心依赖主链路

  • 05整体交互详述

  • 06支付中台设计思路

  • 07资金流与信息流

  • 08跨境整体对照

01 行业全景：钱从用户走到商户，中间站着四组人

先看人。支付这门生意里站着的，不只是支付公司和银行两家。一张行业全景图能一次看全：最左边是消费者，最右边是商户，中间那一片，是被拆成四组的角色。

这张图出自中信建投的行业研究，画的是境内支付的全流程。信息密度很高，但读法很简单：可以按这笔钱走到哪一段进行分组，不用刻意记是哪些公司名字。

图 1｜境内支付行业全景：从消费者到商户的全流程，中间是收单侧、清算侧、账户侧、服务侧四组角色（来源：中信建投，公开行业研究）

顺着图的箭头走一遍，四组就分出来了。

第一组是收单侧，图中间那块第三方支付收单机构。银行（工行、农行、中行、建行）、预付卡机构、银行卡收单机构、网络支付机构（支付宝、财付通、壹钱包、京东支付）都在这一组。这四类不是独立的，是同一件事的四类分工：把商户接进来，把用户的钱收上来。

第二组是清算侧，图右上方那一块。银联清算系统 CUPS 管银行卡跨行交易的信息转接与清算；网联清算系统管非银行支付机构与银行之间的转接清算，也就是断直连之后新长出来的那一段；央行支付清算系统管大额 HVPS、小额 HEPS、超级网银 IBPS。这三家也有分工，负责底层资金真实的流转和划拨。

第三组是账户侧，图左边的合作银行和右下的收款行。钱最终存放在银行；支付机构的客户备付金，则集中存放在备付金账户里。当然，某种程度上钱包，比如微信、支付宝某些场景下也承担了账户侧的一些角色。

第四组是服务侧，图下方那两条带子。聚合收单服务商负责最后一公里的地推与聚合；支付机构服务商提供硬件、软件、终端设备和网络。这一组不碰资金，赚的是服务费和分润。

图的上下两条边，是两个不参与交易却覆盖全程的角色：上方是监管机构（人民银行、支付清算协会），下方左侧是外汇局；最右侧分出境内商户与境外商户两个出口。

这虽然是一张早些年的图，但整体的角色和产业链情况，到现在依然如是。

这张图最容易被读错的地方，是把它当成组织架构。它不是。它是一条价值链，每一组都在为下一组解决一个具体问题。

监管解决的是谁能做、做到什么边界；消费者和商户是需求源头，也是所有收入的最终来源；服务商解决最后一公里的地推和工具；收单侧解决商户接不进来、用户付不出去；清算侧解决跨机构之间怎么传信息、怎么算净额；账户侧解决钱最终存在哪、头寸从谁账上出。

这里得提一下账户。因为账户是这条链的骨骼，因为它决定了钱停在哪、谁能动。这里就得提到行业里常讲的三层账户。

图 2｜账户三层结构（境内 · 断直连后）：业务账户层 / 备付金集中存管层 / 清算账户层，越往下越接近物理资金

三层里，最上面那层是我们日常打交道的：用户钱包余额、商户虚拟账户、平台的分账账户。这一层全部是债权记录，不是钱。

中间那层是备付金集中存管账户，2019 年之后 100% 缴存央行，支付机构碰不到、也挪用不了。

最下面那层是清算账户，是银行和支付机构在人行开立的账户，所有跨机构头寸的最终落脚点。

这里有一个特殊的点单独讲一下，清算账户和我们常说的清结算有关系但完全不一样，清结算是个业务术语，清算账户则是实实在在的一类资金载体。而且清算只发生在持牌金融机构之间，是资金净额的轧差与划付；清分是在机构内部算清谁该分多少；结算是把钱确认登记到最终收款人名下。三个词经常被合起来叫清结算，但它们在系统里是三件不同的事。

还有一个更细的分层，是监管给的：谁能做支付、能做哪一类。

2024 年《非银行支付机构监督管理条例》之后，牌照按业务类型重新划分：储值账户运营分Ⅰ类、Ⅱ类，支付交易处理分Ⅰ类。前者管的是能不能开账户、能不能留余额，后者管的是能不能做收单和通道。这个划分也就直接决定了产品边界：没有储值账户运营资质，就不能做钱包余额；没有支付交易处理资质，就不能碰商户收单。

所以看产业链，可以同时看两条线：一条是业务线，谁服务谁、钱怎么流，一条是资质线，谁能合法做哪一段。很多方案在业务上跑得通，卡在资质上，或者在系统上跑得通，但卡在业务边界上。

再往下一层，支付机构的业务本身还分三类：C 端钱包、B 端标准化收单、产业支付。三类业务的系统重心完全不同——钱包重账户与营销，收单重渠道与商户，产业支付重分账与对账。这也是为什么同样是支付系统，不同家的架构图可能会长得不一样。

虽然是一套产业链角色，但是六层之间也并不是和谐共处，它们的诉求天然冲突。监管要的是可追溯、可穿透；清算机构要的是标准统一、净额清晰；银行要的是头寸安全、存款留存；支付机构要的是转化率、成功率和费率空间；服务商要的是商户存量和返点；商户要的是到账快、手续费低；用户要的是体验好、别失败。

这些诉求在产品上就很可能会打架。比如用户要一键支付，合规偏要强验证；商户要T+0到账，资金方要控头寸；业务要多接渠道提成功率，财务却要控通道成本。所以所谓支付产品设计，本质是在这六层诉求之间找一个可执行的平衡点，并把它落到字段和流程上

02 支付怎么挣钱

支付怎么挣钱，可以简化的一句话回答的话就是：支付就是挣通道费。这句话不算错，但并不完整。

以开头那杯30块的咖啡为例。这笔钱在到商户账上之前，至少经过五拨人的手：商户、服务商（四方）、支付机构（三方）、清算机构（银联/网联）、银行。每一拨人切走的那一块，性质完全不同，当然也可能没有四方或者三方，比如三方的直连客户，或者银行直客。本篇按照最全的讲

先看最标准的一种：银行卡刷卡的手续费怎么分。

图 3｜一笔标准类商户手续费在三类持牌角色间的分润（比例以信用卡为例）

这就是业内说的 7:2:1：发卡行拿七成，收单侧留两成，清算机构拿一成。这个比例不是市场谈出来的，是卡组织定的规则——银联既是清算机构，又是银行卡品牌，有权定义发卡行服务费的框架。所以 7:2:1 本质上是卡组织+清算机构双重身份下的产物。

网联就不一样。它是断直连之后成立的纯清算机构，不发卡、没有卡品牌、不定义发卡行服务费框架，所以它不进 7:2:1 这个分成盘子。网联挣的是转接清算服务费，按笔或按金额向支付机构收一笔很薄的处理费，接近成本定价。

一句话对比：**银联既修路又定交规，网联只修路。**两家都是清算机构，都收过路费，但收法完全不同。

那五类主体各自靠什么活？

图 4｜五类主体收入结构对照（监管单列，不抽成）

把这张图读一遍，会发现一件事：**所有收入的源头只有一个——商户付的手续费。**支付机构赚价差，清算机构赚处理费，银行赚发卡服务费和存款沉淀，服务商赚分润和 SaaS 年费，大厂金融科技赚的是造支付系统的一次性建设费加年费。同一个盘子，切法不同。

这也是为什么支付怎么挣钱这个问题没有标准答案。你站在产业链的哪个位置，就决定了你能挣哪一笔钱。

再补一个经常被混为一谈的区分：一、二、三、四方，说的不是公司大小，是中介层数。

图 5｜四种支付形态对照（按介入的中介层数递增排列）

第一方是现金，没有中介；第二方是银行内部转账，银行是中枢；第三方是支付机构把发卡和收单合体，资金在体系内闭环；第四方是卡组织居中，发卡与收单解耦、清算外化。今天绝大多数线上收单，跑的是四方模式；钱包余额支付，跑的是三方闭环。这里和我们说的三方支付机构、四方聚合服务商其实不是一层意思。

还有一块收入常被忽略：备付金利息。断直连之前，在途资金沉淀在银行，利息归支付机构；2019年备付金100%集中缴存央行之后，这部分利差基本消失，后来按清算保证金给了一个很低的年利率0.35% ，还要计提行业保障基金。这笔钱的性质其实就是在说：备付金是客户的钱，利息是政策给的，不是经营所得。

再往上，还有一类不碰交易的玩家：把造支付系统的能力卖出去。银行要做手机银行支付底座、集团要搭收单清结算中台、连锁企业要统一对账，从0到1太慢，所以干脆直接买。这类生意收的是三笔钱：一次性建设费、年订阅与运维、以及增值模块（风控、营销、数据等）。它和四方的区别在于：四方在下游铺码牌，挣辛苦钱；这类玩家在上游造发动机，挣软件的钱。

跨境则是在同样的结构上多切两刀：跨境支付机构对应境内三方，挣费率和汇差；国际卡组织对应银联，收跨境转接费；境外收单行与本地清算网络对应境内银行收单；此外还多一笔外汇点差。所以跨境的钱来自三块——高费率分润、外汇点差、合规与牌照溢价。

角色 主要收入 成本结构 最怕什么
四方 / 服务商 渠道分润、SaaS 年费 地推人力、终端与运维 商户流失、分润被压
三方支付机构 手续费分润、通道价差、增值服务 通道成本、合规与风控投入 费率下行、通道故障
清算机构 转接清算服务费 系统与网络运维 量大费薄，单价被压
发卡行 发卡服务费、利息、存款沉淀 资金成本、信用风险 坏账、利差收窄
收单行 收单服务费、存款沉淀 商户拓展、终端补贴 商户风险与套现

把这张表看完，会发现一个规律：**越靠近资金的角色，越吃利差和沉淀；越靠近商户的角色，越吃分润和服务。**这也解释了为什么大家都想往上下游延伸——因为单一位置的利润率，都被压得很薄。

03 架构设计

做支付的人都画过或看过架构图。但如果把不同人画的图摆在一起，你会发现一个尴尬的现象：都叫架构图，说的却不是一回事。有人画的是系统分几层，有人画的是能卖哪些产品，还有人画的是部门怎么分工。

不是谁画错了，是架构这个词用得太宽。业务方谈架构，关心角色、商业模式、利润怎么分；产品谈架构，关心卖什么、货架怎么摆、能力怎么拆；技术谈架构，关心分层、隔离、链路怎么走。

先给一张行业通用的全景图，定一个基准。

图 6｜行业通用六层架构：接入层、产品层、核心领域层、公共支撑层、数据基础设施层、底层网络与资金底座

这张图有三个用处。

第一是定位：拿到任何一个系统或模块，先问它坐在哪一层，职责边界和相邻关系大致就清楚了。

第二是定流向：请求自上而下穿过各层，资金结果自下而上回流，两条流方向相反。

第三是定边界：上面五层处理的都是信息流，只有最底层真正发生资金划付。这个区分决定了后面所有关于到账的讨论该以谁为准。

然后是三个视角。它们不是详略关系，也不是上下级关系，是同一套系统的三个投影。

图 7｜三个架构视角：业务、产品、技术，各看什么、交付什么、不碰什么

有个很实用的判据：把图里所有技术名词删掉，如果还能读懂，那是业务架构；把商户名和产品名删掉、只剩系统模块，那是技术架构；两边都得留着才读得懂，那就是产品架构。

三者之间是逐层决定、反向约束的关系：业务架构划定边界和商业模式，产品架构把业务诉求翻译成能力清单，技术架构把能力清单落到分层实现；而技术架构的边界，又会反过来限制产品能卖什么、业务能走多远。

图 8｜三个视角的逐层决定与反向约束：业务 → 产品 → 技术，技术边界再回头约束业务边界

业务架构：这栋楼给谁建、谁出钱

业务架构最容易被跳过，但它最该先画。很多公司的业务架构不是一张图，而是一份市场调研、一份 MRD，或者一份商务合同。它回答的是角色、组织和商务关系：谁提供资金、谁承担风险、谁负责拓展、利润怎么分。

业务架构没画清楚，最典型的症状是需求永远在变。因为边界没定，业务方每提一个需求，产研都要重新判断这是不是我们该做的事。反过来，业务架构清楚的团队，需求评审很快，大部分需求在第一句话就能判断，因为不在边界内。

画业务架构，至少要回答四个问题：为谁服务（客户是谁）、谁出钱（收入从哪来）、凭什么能做（资质与合规）、出了事谁担（风险归属）。四个问题里，最容易被漏的是最后一个，而它恰恰决定了后面所有的对账与争议设计。

图 9｜业务架构：角色、关系与商业模式的边界，先对齐「为谁服务、谁出钱、凭什么能做」

产品架构：把业务诉求翻译成能力清单

产品架构的核心不是画出多少产品，而是找到可售卖的产品单元、追溯它们依赖的原子能力，再找到底层核心依赖。

图 10｜产品架构：货架—产品单元—原子能力—核心依赖，四层追溯关系

这里面有一个关键中枢，很多图可能都不会画：配置与编排引擎。它在货架和原子能力之间，决定一个产品由哪些能力组装、费率怎么配。新产品、新方案、新组合，尽量都通过它配置、验证、跑通之后再上架。这就是支付中台思想的起点，后面会展开。

产品架构要落三件事：产品单元、能力、依赖。产品单元是对外卖的产品，收款、付款、分账、资金管理等；能力是能复用的，比如下单、路由、计费、记账、对账；依赖是最底层的基础，渠道、账户、清算网络。三者之间的关系不是画着好看，本质上其实是是要回答这个产品能不能上、上了要改哪几层。

还有一个常被漏掉的维度：定价。产品架构不只是功能货架，还要标清楚每个产品单元怎么计费——按笔、按比例、按月、还是按阶梯。定价方式决定了计费引擎要支持哪些维度，也决定了清分时分润怎么拆。把定价排除在产品架构之外，最后一定会在清分环节返工。

技术架构：能力清单怎么落地

技术架构回答的是技术栈、实现簇、项目与代码隔离、数据库、外部依赖、网络链路。它通常比业务和产品架构细得多，所以常常是一张总图之外，再加若干关键模块的详细设计。

图 11｜技术架构：分层、隔离与链路，从接入网关一路落到数据与基础设施

三张图缺一张会怎样？只有技术分层、没有业务和产品约束，系统也能跑，但范围会无限扩大，最后什么需求都往里塞；只有产品货架、没有落地实现，方案评审时讲得天花乱坠，说不清这些能力落在哪个系统、被谁调用。

技术架构里有一组东西最值得拿出来单独讲：四种隔离。项目隔离（不同业务线的版本互不影响）、代码隔离（核心账务不允许被业务代码直接依赖）、数据隔离（多租户、多法人、多辖区的数据边界）、网络隔离（生产与办公、内网与外联）。支付系统的稳定性，很大程度上不是靠「写得好」，而是靠这四道隔离把故障约束住。

三种架构各自的交付物也不一样：业务架构交付的是边界与关系（角色、资金、风险、分润），产品架构交付的是能力清单与货架关系（产品单元、能力、依赖），技术架构交付的是分层与实现约束（技术栈、部署单元、数据模型、外部依赖）。评审时最容易犯的错，是拿技术架构的细节去回答业务架构的问题——比如讨论要不要做这个行业，却一直在讲表结构怎么改。

04 核心依赖主链路

支付系统模块很多，但真正常驻主链路的核心依赖，其实只有五个：交易、渠道与路由、清结算、账务、对账。其余的风控、商户、计费、通知、文件，都是围绕这五个转的支撑件。

图 12｜核心依赖主链路：从接入到出款，五个核心域依次咬合，支撑能力挂在链路两侧

为什么是这五个，而不是别的？因为它们各自负责一件不可替代的事：

（图上落到具体链路是八步：用户/商户 → 收银台 → 交易引擎 → 渠道路由 → 收单/清结算 → 账务 → 对账 → 出款）

交易负责的是这笔支付存在：建单、状态、幂等、结果回收；

渠道与路由负责的则是这笔支付走哪条路：能力、成本、降级、超时；

清结算负责的是另一回事，是这笔钱怎么分：算费、分润、净额、结算单；

账务负责这笔钱怎么记：复式记账、科目、余额；

对账则用来专门验证这笔钱对不对：逐笔、净额、差异、挂账。

把这五件事排一下，会发现一个顺序：**先有对象，再有路径，再有钱的数，再有账，最后有校验。**顺序不能乱，因为后一个的输入是前一个的输出。

还有一个架构上的关键点：这五个域之间，并不是直接互相调用的。主流做法是领域事件 + 总线解耦——交易成功之后广播一个事件，清结算和账务各自订阅，谁需要什么自己取，而不是交易去挨个调用。这样加一个下游，不用改上游代码；代价是链路的可观测性要单独做，不然出了问题找不到人。

解耦之后，判断一个模块是不是主链路，标准就变了：不是看它重不重要，而是看它不在，业务能不能闭环。风控很重要，但风控挂了可以降级放过（有额度、有兜底）；对账看起来最不显眼，可它不在，钱对不对就永远没有答案，所以在所有支撑件里，对账是唯一一个省不掉的。

支撑件也有分工：

风控决定这笔能不能放，商户收单准入决定这个人能不能接，计费决定这笔收多少，通知决定对方知不知道，文件服务决定对账拿什么比。它们都不在主链路上，但每一个都能让主链路停下来——这就是为什么生产事故里，很多根因在支撑件上。

再说容量。主链路的容量瓶颈通常不在应用层，而在三处：数据库的写入，比如支付单与流水、外部渠道的并发限额、以及账务的锁。所以真正的容量设计，是围绕这三处做削峰、排队、异步和降级，并不是简单地多加几台机器就行。

05 整体交互详述：一笔钱从成功到可提现，走了 25 步

模块知道了，接下来是最容易含糊的部分：它们之间到底怎么串。

先给一张简图，把骨架立住。整条链可以分两段看：上半段是交易侧，解决这笔支付成不成；下半段是资金侧，解决这笔钱算给谁、什么时候能提。

宽图，建议点开放大看细节

图 13｜核心流程简图：10 个模块、13 条交互，上半段交易、下半段资金

上半段大家都熟：用户下单 → 收银台 → 提交交易 → 建支付单 → 路由选渠道 → 渠道调外部 → 结果回调。这一段的关键词是快和准，秒级返回。

下半段是分水岭。支付成功那一刻，钱其实一分都没动，只是系统知道这笔成了。真正的资金处理，一般从第二天对账文件到达才开始。

下面这张详图，是整篇文章最值得放大看的一张。图上每一个数字，对应一个动作的顺序。

宽图，建议点开放大看细节

图 14｜模块交互链路详图：14→25 的完整时序，对账在前、清分在中、结算在后

前面交易段的就不再详细赘述，主要说差异和后续的处理，尽量按编号走一遍：

**14T+1 文件到达。**外部渠道把前一天的对账文件送到，对账中心通过渠道网关去 SFTP 拉取或接口下载。每一家的地址、格式、拉取方式都要单独配。

**15对账中心三路取数。**很多人以为对账就是拿文件比一比的地方，实际要取三路：一是渠道侧的本地流水，二是账务侧的内部记账流水，三是清结算侧算出来的渠道手续费。三路对完，才能确认钱数、笔数、费用三件事都没有问题。

**16差异进差错处理。**对不上的那几笔，不是直接退回，而是进差错池，由差错处理中心定性：是时间差、口径差，还是真差错。

**17对账后有两个出口。**处理完的回流对账中心，标记已对平；当天处理不完的，先挂账，等下一批。这里有一个特殊强调点：**挂账不影响其余部分继续走。**逐笔差异只卡那一笔，只有文件没到或总额不平，才卡整批。

**18通知清结算。**对账中心把哪些已经对平告诉清结算，这是清分的前置条件。清分不会在没对平的数据上跑。行业内也有更乐观的做法，以渠道文件为准，先跑清分，后对账，看各自取舍，图中是我我个人更推荐、也更保守的一种做法。

**19清分。**清结算按自己的交易流水、费率、参与方信息，算出每个参与方该分多少、渠道手续费该扣多少，汇总成结算明细。

**20复式记账。**清分流水推给账务，账务按科目拆成多借多贷的条目。一笔 100 元的收单，资金到账时记渠道待结算 -100、银存（或备付金）+100；清分结果出来后再记商户待结算 -100、商户可用余额 +99.4、渠道手续费收入 +0.6。

**21余额可用。**记账完成，账户侧更新余额与流水，商户的可用余额到了这一步才真正变了。在这之前，一切金额都还只是待结算。

**22结算单。**清结算按商户的结算规则和场次出具结算单，到结算时点推进出款。

**23出款。**走底层通道完成实际划付：支付机构走银联/网联到备付金，再出到商户；商户提现走银行代付。这是整条链上唯一不可逆的外部动作。

**24结算通知。**出款结果回调，通知商户。注意已出款不等于已到账，我方通知只能描述确知的事实。

**25挂账重清分。**那些当天挂了账的交易，事后处理完成后，如果已经错过本次结算场次，就重新清分、并入下一个批次再结算。

在详细把对账拆开看，它其实是三层，而且是三个正交维度，不是三道流程：

**交易账 / 渠道账，逐笔对。**拿我方交易流水和渠道流水一笔一笔比，比的是有没有这一笔、金额对不对、状态对不对。这一层还要检查三道：金额、状态、手续费。手续费核对不是独立的第四层，而是这一层里的一块：渠道报的手续费要和我方计费引擎算出来的比，差一分都要找出来。

**资金账，按批对。**拿渠道给的清算文件（或银行流水）和我方资金流水对净额，比的是这一天该到多少钱、实际到了多少。特别注意这一层是卡批的：总额不平，整批不放行。

**内部账，自洽对。**拿账务的分录和账户余额对，比的是借贷平不平、余额与流水对不对。这一层只卡日结，不卡出款——因为内部账是拷贝，不是底账，晚到不影响库里的数。

这就解释了批次放行为什么有三态：整批放、部分放、不放。**只等渠道账和资金账，不等内部账。**渠道账逐笔平、资金账总额平，就放；逐笔有差异但差额可冻，就部分放；文件没到或者总额不平，才整批不放。

差异也不是处理方式都一样，按性质分三类：时间差，比如今天没到明天到，这种不干预，等就行了、口径差，比如两边算法不同，这种改规则不用动账、第三种是真差错，确实错了，就得挂差错账、走冲正。三类里只有第三类要动账，前两类动账就是把对的改错了。

差错账有自己的生命周期：发现、挂账、定性、处理、核销，处理不了的转入人工或者按规则计提损失。

它最怕两件事：一是不定性就动账，二是跨期不消化。前者的后果是账越改越乱，后者的后果是差错池越来越大，最后没人敢碰。所以差错处理的核心指标不是处理得快，而是每一笔都有归属，要么销案，要么挂账并指定责任人，不能悬着。

跨期消化还有一个容易被忽略的规则：**本期挂账的差异，不能靠下期多出来的钱去平。**长款和短款必须分开走，长款要找到来源退回，短款要找到原因补记，两边对冲看起来平了，实际是把两个错误藏成了一个。

还有一条容易被忽略的边界：**出款是整条链上唯一不可逆的外部动作。**扣款可以退，记账可以冲，对账可以重跑，出款出去了就收不回来。所以出款前必须过闸门：余额够不够、头寸够不够、争议额要不要扣、合规名单过没过。这也是为什么出款系统要比交易系统保守得多，因为它宁可慢，不可错。

既然是说整体交互，所以把前半段交易环节也放上来，看一看细节，以收银台为例。它看起来只是选择了几个支付方式和确认密码，实际是一次跨多个系统的协同。

图 15｜收银台整体交互详细时序：从渲染、选方式、下单到结果回收，每一步的失败分支都要有出口

这张图里最值得注意的不是主路径，是失败分支：渲染时渠道不可用怎么降级、提交时幂等键怎么保证、渠道超时怎么查询、用户回跳但没收到通知怎么兜底。收银台的设计水平，基本体现在这些分支上。

顺着这张图往后，就是路由与渠道域。路由表面上是选一条通道，实际是在四个约束下求一个解：能力（这条通道支持不支持这个币种、这个卡种、这个国家、支持哪些银行、卡种、支付方式，前面那些跨境才会涉及，国内主要看卡种和银行，以及支付方式）、成本（费率、固定费、汇差）、成功率（历史可用性、当前限额）、合规（这个主体能不能走这条通道）。四个约束里，合规是硬约束，其余三个是可权衡的排序问题。

路由有两件事必须固定好。第一，明确失败才换道：渠道明确返回失败，可以换一条重试；超时或未知，只能查询原单，不能换道重发。第二，幂等键要覆盖重试：同一笔业务在多次重试中必须用同一个键，否则换了通道就会变成重复扣款。

再往后是退款。退款看起来是反向一笔，实际是七个环节：受理、校验可退额、路由回原渠道、提交、渠道处理、结果回收、账务冲减。**退款不重新路由，**原路退回是铁律，因为资金必须沿原债权债务关系退回；原路不通才走替代路径，而替代路径要单独设计合规与凭证。可退额也不是原支付金额，而是原支付 − 已退 − 在途占用，三个数缺一个就会超退。

再往下沉一层，看清结算域自己的标准动作。

图 16｜清结算七步标准流程与流水状态机：算费、分润、汇总、出单、出款，每一步都有状态兜底

七步是骨架，状态机是保险。很多出款事故不是算错了，是某一步的状态没落、重跑时找不到断点。

账务侧的核心是什么时候记、按什么规则记。

图 17｜记账的三类触发源与统一落账：交易成功、渠道受理、清结算结果，最终都收敛到同一套分录规则

三类触发源里，只有清结算的结果决定金额。渠道受理那一步只回填渠道流水号，渠道报的手续费要另存、不能直接入账，必须过计费引擎重算。这条边界守不住，账就会和计费对不上。

对账侧则是两条链一起跑。

图 18｜对账的双链模型：交易账与资金账并行核对，一条卡笔、一条卡批，最后在差异池汇合

为什么是两条链？因为笔数对不对和总额对不对是两个问题。逐笔对得上、总额对不上，说明有笔数之外的差错（比如手续费、汇率、退款冲抵）；总额对得上、逐笔对不上，说明有串户或者重复。两条链都过，才叫对平。

06 支付中台设计思路

讲完链路，再讲一个所有支付公司或者大型平台机构迟早要面对的问题：业务线越铺越多，系统是不是要一套一套重写？

中台就是对这个问题的回答。但它经常被理解成把系统拆细、做成服务，这只说对了一半。中台的本质不是拆，是把会被多条业务线重复使用的能力收编成共享层，让前台只管差异化的部分。

图 19｜支付中台总图：前台薄、中台厚、底座稳；中台把七大域能力收编为共享层

三层各自的分工：

**前台薄。**收银台、行业解决方案、商户门户这些贴近场景的部分，允许每条业务线不一样，也允许快速试错。薄不是简陋，是不承载核心逻辑。

**中台厚。**交易、账户、清结算、渠道、对账、风控这些能力收编成共享服务，对外只暴露能力接口，不暴露实现。厚的意思是稳定、可复用、有统一口径。

**底座稳。**清算网络、资金账户、数据与基础设施，这一层不能天天动。

中台能不能真的快，关键在一个东西：产品工厂。

图 20｜产品工厂：从能力货架挑选并组装，靠配置而非编码上线新产品

产品工厂的价值，是把上线一个新产品从一次研发项目，变成一次配置动作：从能力货架上挑能力、用规则引擎配策略、跑通验证、发布。做到按天级交付，而不是月级。

但中台有边界。三类东西不该硬塞进去：一是强属地差异的合规逻辑，每个辖区都要单独裁决，二是还在快速变化的创新业务，收编太早会拖慢所有人，三是只服务一条业务线、复用率为零的能力，那叫共享，实则负债。

中台不是一步建成的，通常是三个阶段：先是组件化，把重复代码抽成公共组件；再是服务化，把能力拆成独立服务、定好接口与边界；最后是能力化，把服务包装成可被业务方按需取用的能力，配上计量、权限、SLA。

中台失败的典型姿势有三种，都很常见：一是把中台做成大前台，什么需求都往里塞，最后中台变成最慢的那一环；二是把中台做成数据同步，各业务线不动，只把数据往中间一拷，表面上统一了，实际各算各的；三是把中台做成审批机构，接入一个能力要过五道评审，业务方宁愿自己写。

配置编排这件事，还需要一层治理。谁能改费率、谁能加能力、改了怎么验证、出问题怎么回滚——这些不是技术问题，是权限与流程问题。很多中台的稳定性事故，不是代码写错，很可能是某个运营同学在配置界面点错了。

07 资金流与信息流，支付系统的设计本质

回到开头那个问题：一笔支付，什么时候算完成？

顺着产业链问下去，会得到四个不同的答案，而且每一个都不算错。

商户说：收到支付机构的成功通知，我的交易系统就完成了；第二天对账文件逐笔对平，我在自己的虚拟账户里给卖家记一笔，就算到账。

支付机构说：收到银网联的支付成功，信息流就完了；第二天拿到清算文件、逐笔核对没问题，完成资金对账，就认为资金到了备付金账户。

清算机构说：转接完成，信息流走完；等我把清算文件作为划拨依据提交给央行，央行执行完、回传处理结果，我才认这笔资金走完。

央行不需要表态，因为钱是在它这里真正移动的。

四个答案的差别，本质是四层账户的差别。

图 21｜一笔 100 元收单交易：信息流（细线，T+0，自左向右）与资金流（粗线，T+1，自右向左），下半部分是支付公司账务体系与外部清算银行体系

这张图上有几个点值得逐条说：

**第一，真正搬钱的只有一个角色。**清算机构一分钱不经手，它出的是净额和划付依据；银行扣的是持卡人的账，钱还在行内；真正让钱从一个机构的账户到另一个机构账户的，是人行。

**第二，从收单到结算，钱其实只动了两次。**一次是支付成功后从发卡行搬到支付机构备付金，一次是从备付金搬到商户的银行对公户。中间所有的待结算、冻结、在途、挂账，都是记账，不是搬钱。

**第三，四层账户是同一笔钱的四个视角，不是四个步骤。**商户的虚拟账户是债权映射，支付机构的账户是过程性记录，备付金是真实存放，清算账户是机构间头寸。看的时候要能对上，但不能混为一谈。

**第四，信息流和资金流永远错开。**信息秒级返回，资金要跨一天甚至几天。系统里的待结算、冻结、在途、挂账，全是为了接住这两条流之间的落差。有落差就有错漏，所以必须有对账兜底。

关于待结算、冻结、在途、挂账，值得单独说清楚，因为很多人把它们混成一个中间状态：

待结算是钱算清楚了，但还没到结算时点；冻结是钱在账上，但暂时不能用（风控、争议、保证金）；在途是钱已经出去了，但对方还没确认到账；挂账是这笔对不上，先放着等处理。四个词对应四种责任，也对应四种对账口径，混着用就没法追责。

记账这件事，底层其实就三组话术：借与贷（方向）、科目（性质）、余额（结果）。一笔业务拆成多借多贷，借贷必须相等；科目决定这笔钱记在资产、负债还是收入；余额是科目累计的结果，不是一个独立的账。理解了这三组，再看任何一张分录表都不会晕。

还有一条边界要守住：**账户是主体视图，账务是过程底账。**账户回答这个主体现在有多少钱，账务回答这些钱是怎么变成现在这样的。只改账户不记账，账就不自洽；只记账不更新账户，余额就查不到。两边必须由同一笔分录驱动，不能各改各的。

把两条流放到同一条时间轴上，会看到三个很普遍的错觉。

**错觉一：支付成功，钱就到了。**支付成功只说明渠道受理了，钱还在发卡行。真正到支付机构备付金，要等清算净额划付；真正到商户可用，要等结算出款。

**错觉二：清分完，就该结算了。**清分算的是谁该分多少，结算做的是什么时候、用什么通道、把钱给谁。中间还隔着对账放行、结算单、出款闸门三道关，任何一道没过，清分算得再准也出不去。

**错觉三：对账是财务的事。**财务对的是账，系统对的是：笔、额、状态、费用四件事。对账对不出来，往往不是账错了，是交易状态没回填、渠道流水号没落库、手续费口径不一致。这些都得在产品设计阶段就埋好字段，财务事后补不回来。

对于资金流信息流，简单总结来说的话：支付的业务含义或许是资金的搬运工，系统含义却不是搬钱，而是把资金和信息两套关于同一件事的说法，最终收敛成一套。这个收敛不会自动发生，是靠层级、字段、文件、对账、责任分工，一层一层设计出来的。

08 跨境的整体对照

最后一部分讲跨境。这个题目单独写一本书都不够，这里只是想做一件事：把跨境和境内放在一起，比两张图。一张比角色，一张比架构。这两件事看清楚了，剩下的细节可以在实际工作中慢慢体会，但整体感还是需要先立住的。

角色：

先看角色。下图是艾瑞研究院画的全球跨境支付产业链图谱，视线从付款方出发，一路走到收款方。

图 22｜全球跨境支付产业链图谱：付款方到收款方之间的角色分层，底部一行是共用地基（来源：艾瑞研究院，公开研究）

把它和前面那张境内全景图并排放，主干是一模一样的：付款方、收单与钱包、支付机构、银行、清算网络、收款方，一个都不少。区别在三个地方。

**第一，多了一层换汇。**境内一笔人民币收单，从头到尾一个币种，金额不会变；跨境每一段都可能换汇，报价、锁汇、平盘、损益是一整套独立系统，也是跨境机构真正的利润来源和风险来源。

**第二，多了两条境内没有的通道。**一条是专业汇款机构这条老链路——西联、MoneyGram 这一类，走网点交款、网点提现，和卡组织、钱包完全平行；另一条是底部的虚拟币机构，只在部分市场、部分平台被接受。

**第三，多了账户开在哪这个问题。**境内收单，商户的钱进自己的对公户，账户这件事根本不用设计；跨境要先在境外开立本地账户（VA，虚拟账户），用当地账户收当地的钱，才能把一笔跨境付款变成当地语境下的本地支付。图上第三方支付公司（收款为主）那一整列，其实卖的都是这件事。

还有一层容易被忽略：图最下方那行小字——跨境支付系统（SWIFT、CHIPS、CIPS）、跨境支付监管机构、国际卡组织、技术支持商。它们不画成角色，因为它们是所有角色共用的地基。境内这张图里，地基是银联、网联和央行清算系统；跨境这张图里，地基是每个辖区各一套，没有全球统一的那一家。

架构：

再看架构。下图是一家三方跨境支付机构内部的业务体系架构，横向分五层：业务层、支付层、清算层、通道层，上面再压一个中台层。

图 23｜一家三方跨境支付机构的业务体系架构：业务层、支付层、清算层、通道层，外加一个中台层（来源：墨玉.L11跨境支付全能营）

把这张图和境内支付机构的架构图并排放，差异非常集中，可以一条一条数。

**中台层多了两块：外汇系统和资金调拨。**境内中台一般是风控、计费、资金三件套；跨境在这里多出外汇（取价、报价加点、锁汇、平盘、损益）与资金调拨（多账户、多币种、多辖区之间的头寸归集与水位）。原因很朴素：跨境机构的钱散在几十个银行账户里，不调拨，账上有钱也出不去款。

**通道层从两类变成八类。**境内通道层主要就是收单和付款，对接银联、网联、银行；跨境的通道层是收单、收付款、换汇、VA账户、VCC发卡、结汇申报、物流信息校验、KYC鉴权。可以看到，这八类里有一半不是我们常规理解的支付通道，而是合规与证明类通道，这就是跨境通道对接为什么慢。

**清算层多了一个财务软件出口。**境内结算到商户对公户就结束了；跨境要出结汇申报、要给财务系统做账、要满足外汇核销。钱出得去，不等于这笔业务结得掉。

**业务层和支付层基本没变。**商家网关、开放平台、收银台、交易核心、统一支付，还是原来那些东西，连相对位置都没动。

所以两张图可以合成一句话：**跨境的改造量，主要落在中台和通道，不在支付核心。**这也是很多团队评估跨境时估错的地方，支付核心要重写去排期，会排得很重；按中台加两块、通道加六类、清算加一个出口去排，才会看见真正的成本在通道对接和合规资质上，不在代码量上。

最后总结

写到这里，八个部分其实在讲同一件事：支付系统的复杂度，不在模块数量，在模块之间的接缝。

境内如此，跨境更是如此。境内是把一条链跑顺，跨境是把同一条链按辖区、按币种、按主体各跑一遍，再把它们接起来。所有让人觉得难的地方，几乎都在这条接缝上：对账对不上、退款退不回、结算结算不了、状态说不清。

这一篇如果调重点讲的话，我想优先保留下面这几句。

**第一，先分清信息流和资金流。**任何一句到账了，都要追问一句：谁说的到账、凭据是什么、钱停在哪一层账户。因为只有真正知道钱在哪一层，就几乎可以解决一半的沟通问题。

**第二，先分清清算、清分、结算。**机构之间轧差划付是清算，算清谁该分多少是清分，把钱确认到收款人名下是结算。三个词不能混着用。

**第三，跨境的改造，可以区分一下这是“加字段”的问题，还是要单独“加一份”的问题。**加字段是改表，加一份是改主键、改流程、改责任边界。跨境的改造量，九成其实来自后者。

这套材料我整理了 9 部 37 章、198 节，配了 640 多张线框图、900 多张表。这篇只是一个入口，把这套体系里最关键的主要核心几段串起来。真正要落地，可能不能直接实际落地，但理解先行，落地在后，不清不楚的做，我个人觉得是南辕北辙。

如有表述错误和问题，也欢迎指正沟通。想要全套材料的，可以到公众号首页加微。

本文采集自 彬彬不倦，作者：Wetoo，原文发布于 2026年11月9日。原文版权归原作者所有，此处仅作学习与记录之用。