资金视角看支付系统架构设计

在线支付是一个有近 20 年发展历程的行业，其背后系统的技术设计也随着时间、政策、技术的迭代，不断发生着变化。作为一个与钱直接打交道的行业，支付系统的准确性、安全性、稳定性要求都非常高，对程序员而言无疑是一个非常有挑战性的技术领域。 本文从资金的视角提炼了支付系统背后的业务与技术要点，帮助大家理清支付和资金的关系，文中多处架构示意图非常直观，相信能给大家一些全面的技术输入！

关注腾讯云开发者，一手技术干货提前解锁👇

01、前言

提起在线支付，大家一定不陌生，这个行业发展了快20年了，最近又推出了“碰一碰”支付等创新形态。但绝大多数人对支付的了解仍只浮在水面上，作为支付行业从业者，今天来带大家看看冰山下面的部分：欢迎走进“资金管理”这个神秘领域。

02、支付和资金的关系

这里所说的“资金”或“资金管理”不是特指某一个团队或某一款产品，你可以理解为支付一定要与钱打交道吧？我暂且把在支付流程中与钱相关的东西都放进一个黑盒子里，为了便于叙述，给这个黑盒子取一个名字叫“资金平台”，再一步步解密黑盒子里放了哪些东西。在正式解密之前，我们先看看这个黑盒子（“资金平台”）在支付流程中是如何与上下游交互的。

举个例子，小明口渴了，进711买了一瓶水，用微信支付向收银员付了5元钱。

整个流程大致上像是这样：

首先这个资金平台是服务于支付公司（比如微信支付）的，理论上每个支付公司都应当有个资金平台，架构上或许多少有些不同，但底层原理上是一致的。

那么资金平台需要做些什么呢？如果只从最浅显的角度看，应该至少完成这1件事：把小明支付的5元钱转给711。

问题就来了，就这么简单，支付系统不能自己做吗，为什么一定要交给资金平台？直觉告诉我们，银行、微信支付、711属于不同的体系，用户的钱不会乖乖的自己飞到711的账户里，这里面一定还有许多“猫腻”，不着急，下面就来一点点解密。

在此之前先插个题外话：上图向银行发起扣款看起来也是与资金相关的动作，为什么不是资金平台来完成？这是因为扣款是支付主链路的关键环节，支付强依赖扣款结果来确认支付状态，而且扣款指令只是完成了与银行的信息流交互，并未真正发生资金流转。

03、资金平台的职责

3.1 备付金账户管理

首先还是要回答这个问题：钱是怎么从用户银行卡转到711的?

银行当然不会直接对接711，中间需要经过微信支付进行中转，根据央行的规定，第三方支付的资金都需要受到两联（银联、网联）监管，微信支付需要在央行开设一个备付金账户，所有未结算的资金都会沉淀在备付金账户里。

资金平台需要负责对备付金账户进行管理，包括：

1. 账户开立。
2. 账户信息管理。
3. 冻结解冻。
4. 账户销户。

实际上一家支付公司不可能只开一个备付金账户，在断直连以前账户都是直接开在商业银行的，断直连后也仍有许多场景需要在商业银行开户。理论上说只有开在央行的账户才叫备付金账户，大家平时交流说习惯了会把普通账户也叫做备付金账户。

不管怎么样，这些账户里都是有存钱的，都是物理账户，为了便于管账，每一个物理账户还会在公司内部开设一个虚拟“影子户”或者叫“头寸户”。

3.2 （客户）账户管理

小明作为微信支付的用户，在微信支付里有个钱包账户，就是我们平时看到的这个：

每个用户在资金平台内都有一个“余额户”，充值、收到红包时账户就会加钱，使用余额支付时账户就会扣钱。

小明买水如果用银行卡支付，就不涉及余额户的变动；如果用余额支付，则余额-5。

所谓“客户账户”就是指提供给客户使用的账户，包括个人用户和商户。

与“客户账户”对应的叫做“内部户”，内部户不需要开放给客户使用，只用于内部记账。

至此，我们可以用一张图描述资金账户体系：

这里的账户体系所包含的，是企业自己需要管理的账户。像小明自己在工商银行开设的账户则不属于管辖范围。

3.3 结算

有了上面的准备工作后，我们就可以开始结算了。

结算，就是把资金结给商户的过程。

根据商户入驻时签订的合同，每个商户都有相应的结算周期和结算方式。

- 结算周期：例如实时结算，T+1 结算

- 结算方式：结算到卡，结算到余额

假设 T+1 结算，整个过程看起来像这样：

如果结算到余额，直接商户余额+20，如果结算到卡，根据行业规范要求信息流需要经过银网联，再由银网联进行统一清算。

3.4 对账

资金平台很重要的一个职责是保证资金安全。我们先来看看小明支付的5元是怎么进到微信支付的备付金账户的：

前面说到第三方支付的资金受到两联监管，每一笔交易都需要上报，网联在这里面还承担了资金清算的职责。它会算清楚工商银行和财付通的应收应付账款，一定时间内进行汇总后一次性打款。

可以看到清算的工作交给了网联，支付公司只是被动接受消息和收到账款，虽说网联是国家队，但有没有极小的可能性它也会算错？例如程序员写了一个bug之类的？

为了避免这种情况发生，我们就需要进行资金对账，使用标准的三层对账模式：

• 第一层：明细对账，我方的【交易明细】和网联的【清算明细】进行逐笔明细对账，对账的结果生成一个【汇总账单】
• 第二层：资金对账，【汇总账单】和备付金银行入账后会生成的【银行账单】进行汇总级的对账
• 第三层：余额对账，今天的银存日终余额 = 昨天银存日终余额 + 今日发生额

三层对账保证了每一笔明细、每一笔账款的准确性。

不只是小明的付款会有对账，前面提到的结算过程也会对账，只要发生了实体资金变动的都需要进行对账。因此有时也把对账称为账实核对。

3.5 记账

上面的支付过程有个小问题，如果是 T+1 结算，从小明支付成功到真正结算还隔着老长时间，在这中间买水的5元钱去哪了？

这就要分实体资金和虚拟资金来说明了。

实体资金，也就是真正意义上的钱在哪，这个要看网联的清算周期

1. 网联完成清算后，实体资金才会进到备付金账户
2. 备付金账户的钱，需要T+1结算后给商户（实际上这里也需要等网联清算完成才能真正到账）

实体资金的流转看起来像这样：

可以看到实体资金的流转并不总是那么实时的，有一些“真空期”：钱在路上了，至于到哪了咱也不知道。为了能更好地管理整个资金的生命周期，降低资金风险，就需要引入虚拟资金流，也就是我们所说的“记账”。

上面提到小明支付成功后，但还未结算前，资金就沉淀在“商户待结算”里面，类似于“商户待结算”这样的账户，就是内部户。

我们尝试还原一下完整的记账过程，注意记账是以支付公司的视角去记的（假定商户是结算到余额）：

细心观察可以发现，记账过程有这样的特点

1. 每次都记两个户，一个是借记(D)一个是贷记(C)，这是因为记账过程用的是复式记账法，需要遵循“有借必有贷，借贷必相等”
2. 内部户有个账户类型的属性，标在表格里了 D 表示借记账户，C 表示贷记账户。账户类型与记账方向，同号为增，异号为减
3. 记账全部完成后，最终备付金头寸+5，商户余额+5，这与预期相符。

上面提到了实体资金流，那是否有虚拟资金流？

当然有，我们按照借记指向贷记的顺序，把所有相关的内部户串联起来，就形成了虚拟资金流。

那么记账有什么用呢？

1. 更细粒度管理资金的流转，通过记账可以知道一笔资金现在到了哪个环节。
2. 通过账户沉淀资金，可以推断是否存在资金风险，例如“应收待清算”账户长期沉淀大量资金，说明可能有合作机构未完成资金清算。
3. 记账本身就是一种资金风险的防控手段，例如有人篡改了账户余额，通过余额和账务流水核对就可以发现。
4. 出财务报表。

3.6 会计核算

现在我们知道了一笔支付的钱怎么收进来，怎么结出去，怎么通过记账、对账来防范和识别风险，还有什么没做的吗？

确实还有一件事：如果账记错了怎么办？不仅会影响资金风险防控的效果，财务报表也会不准确，影响经营决策。

在会计学上是通过会计核算的方式来验证账本是否有问题。

简单来说，会计核算就是在做核对和统计。有这么几件事：

1. 借贷平衡校验。每一笔账需要保证满足“有借必有贷，借贷必相等”。
2. 对内部户进行归类，形成一颗多叉树结构，叶子节点是所有的内部户，不断向上汇总。我们把非叶子节点都称作“科目”，父科目的总额=子科目汇总金额。
3. 在总账上，必须满足借方余额=贷方余额。也就是会计恒等式：资产=负债+所有者权益。

感兴趣的可以进一步搜索【资产负债表】、【利润表】、【现金流量表】，本文就不再继续延伸了。

用一张图总结一下在支付流程中资金平台的职责和作用：

04、跨境业务的复杂性

文章的上半部分说的是境内一笔支付的场景， 在跨境场景下是否有什么区别呢？任何业务一旦加上了“跨境”二字，整个业务和系统的复杂度就不只是上升了一个量级。

1. 最直观的感受，好像啥都变多了：主体、银存、币种、时区……例如银存，在国内可能开两三个备付金账户就够用了，到了跨境业务，至少各大洲都要开设银存，还得覆盖至少10多个大币种。
2. 对资金的时效性更敏感了。在国内大家已经对资金立即到账已经习以为常，就连跨行转账都能做到秒级到账。跨境就不一样了，资金通常需要经过多个国家或地区，资金链路越长，到账时效也就越长。时效性对用户体验的影响是巨大的。
3. 需要了解每个地区当地的支付习惯，我觉得在所有复杂性里面，localization是最复杂的一个环节。每个国家，他们的消费习惯和支付习惯完全不一样，如果只是照搬国内的业务模式，大概率会失败。
4. 需要应对不同的监管政策。例如货币的出境限额，经营牌照，备付金的存管方式，数据隐私性要求等。
5. 需要敏锐地观察和应对国际局势，包括但不限于：xx 国大选、地缘冲突、政治博弈、货币政策等。我曾经历过美联储加息，通过购买理财“躺着把钱赚了”，也经历过俄乌冲突一夜之间卢布暴跌，俄罗斯账户全面冻结。是的，就是这么刺激！
6. 技术架构的复杂度大大增加。做国内业务可能只需考虑同城多机房，再复杂一点可能需要考虑 X 地 X 中心，国际业务中就不得不考虑每个国家对数据出境的政策要求，政策会影响机房的建立和部署，还会进一步影响容灾策略和性能，例如在对客业务中跨洲的调用延时是绝对无法接受的。

以上不同因素的叠加导致资金业务的复杂性也是指数级上升，但咱也别被这些就吓住了，看看在这样的背景下资金平台应该怎么做。

05、支付和资金的关系

从这个章节起，我们聊一聊跨境支付中的资金管理问题。

现在把场景换成跨境支付，小明去韩国旅游，进711买了一瓶矿泉水，价格是1000韩元（KRW），拿着微信扫码，随着“滴”的一声，付款成功5人民币（CNY）。

跨境业务确实有些复杂，上面的场景设置过于粗糙了，正式开始之前我们得补充一些必要的假设 （这个场景是虚拟场景，与微信业务无关）：

1. 二维码是怎么来的，微信中国钱包能识别吗？我们假设这个二维码是“微信支付-韩国”分公司提供的，韩国分公司在这里承担的是收单的角色
2. 小明拿着微信中国钱包去扫码，钱包的背后也得有家公司，假设叫“微信支付-中国”，这里是发卡的角色（关于发卡和收单，我会专门另开一期单聊）
3. 境内支付还涉及网联清算

把上面的图扩展一下，逻辑上的关系大概像这样：

06、资金平台做了哪些事

7.1 备付金和账户体系

备付金其实跟国内的备付金管理区别不大，也是要管理备付金账户的生命周期。但是需要注意：

1. 尽量把账户开到大银行上，因为国外的银行是真的会倒闭。
2. 出于风险考虑，不要把钱都放到一个篮子里。
3. 根据需要开设多币种账户。

账户体系也没什么区别，在上文已经介绍过了。

7.2 资金通路管理

资金从小明的银行卡到711商户要分几步？咱们来一步步分析：

1. 小明用微信中国钱包付了 5CNY，这部分根据境内支付行业规范，资金要先经过央行备付金账户。
2. 要出境的资金还需要经过跨境专户。
3. 在哪里做外汇兑换，也就是把 5CNY 换成 1000KRW？可能有几种方式：
   1. 在境内直接兑换成 KRW 再出境到韩国。
   2. CNY 先出境变成离岸人民币CNH，在香港或新加坡兑换成 KRW，这种情况为了更便于开展业务，就需要在香港或新加坡注册公司，暂且称为“微信支付-香港”和“微信支付-新加坡”。
   3. 或者有没有可能 CNH 先进入韩国，在韩国境内兑换成 KRW？这种基本不太考虑，因为韩国可能有货币政策的限制，而且香港和新加坡本就是亚洲的金融中心，在外汇方面有更多的自由度。
   4. 当然还有一种方式就是委托境外机构代发，但要这么说的话这篇文章就没有意义了。咱举例说明，就是要举最详细的例子，全流程都做。

完整的资金通路可能是这样（境内兑换）：

或这样（出境后兑换）：

现实情况可能比这还复杂的多，因此资金平台一个重要的作用就是把资金链路打通，某些情况下或许有不止一条资金通路，那就还需根据资金时效性、资金成本、监管政策等因素进行综合决策，选一条最合适的资金通路。

7.3 外汇兑换

小明支付的5CNY必须经过外汇兑换（FX：Foreign Exchange）才能转成KRW。但如果要展开聊外汇，估计一篇文章都写不下，这里还是聚焦说一说在支付关键链路下外汇的核心流程。

我们以上面的资金通路二进行说明：

1. 外汇报价（FX Quote）。用户在扫码支付的那一刻，就需要进行一次外汇报价，根据查询的即时汇率再进行一些加点报给用户，这样用户才能在支付时看到应付 5 CNY。
2. 外汇交易（FX Trading）。外汇交易的模式有很多种，在此不长篇大论，仅说本例，交易分成两阶段：
   1. 外汇锁价。因为汇率是实时变化的，小明扫码支付了5CNY，在此刻预期是能兑换1000KRW，但如果不锁价，发生汇率波动，真正兑换的时候也许只能兑换980KRW，也可能兑换1020KRW，若不愿意承担风险，通过锁价机制就可以保证交易时不多不少能换回1000KRW。
   2. 外汇交易。这一阶段是真正触发交易，按照约定的锁价汇率，把 CNY 付给兑换机构（如 BOCHK），兑换机构把相应的KRW兑换回来。
3. 头寸管理（Position Management）。在小明支付成功那一刻，意味着公司账户收入 5CNY（或者说是待收），同时也意味着公司对711产生一笔 1000KRW 的待付，虽说有锁价机制，但只要没真正去做兑换，这个风险敞口就一直存在。头寸管理就是要把风险敞口或风险水位控制在一定范围内，通过制定合理的交易策略，及时地完成外汇交割，消除风险敞口，这一过程通常也称作“平盘”。

大致上外汇的核心流程是这样的：

7.4 清算和对账

清算的重点就是分清参与清算的双方是谁，谁是主动清算，谁是被动清算。

阶段一：清分，主动清算的一方负责算账，算好了给对方出一份清算文件，被动清算的一方要明细对账，以免对方算错了。

阶段二：清偿，根据清分的结果进行打款。主动清算方通过调拨把钱转入被动清算方账户。这时双方的银行发生动账，会各自收到银行的账单通知，还需要进行一次账单对账。

清算和对账的大体流程如下：

实际上这里的复杂性并不来自于清算流程， 而是对清算关系的分析。我们以上面的资金通路二为例，来捋一捋整个链路中所有机构间的清算关系：

这里有两点稍做解释

1. 网联的清算特殊一些，叫做第三方清算模式。网联是第三方清算机构，负责支付渠道（工行）和 WeChatPay CN 之间的清算。
2. WeChatPay CN,HK,KR 之间存在比较复杂的委托兑换和委托代付关系：
   1. Wechat Pay CN 的视角：要付给 KR 1000KRW，但是我手里只有 5CNY，因此要委托 WeChatPay HK 做兑换，兑换后的KRW不急着要回来，后面清偿时再委托代付就好了。
   2. Wechat Pay HK 的视角：收到一笔 CNY-KRW 的兑换请求，并且把兑换完的 KRW 付出去。
   3. Wechat Pay KR 的视角：我只知道 WeChatPay CN 要付给我1000KRW，至于钱是从哪里来的我不关心，所以我感知不到 WeChatPay HK。

7.5 多主体账务管理

说到这里，你应该对实体资金流比较了解了，但资金平台还有一个重要职责就是管理虚拟资金流，也就是记账。

说记账之前又得先说一个名词：主体（Entity），或叫法人主体（Legal Entity），可以理解为在法律上独立注册的一家公司，享有法人权利和义务，例如签订合同等需要法人主体来签订。

还有一个词叫核算主体或会计主体（Accounting Entity），因为稍微大一点规模的公司，不会只做单一业务，不同业务的账需要分开管，而核算主体就是为了管账而设计的，我们平时说的“你这笔账要记到哪个主体下面？”这里就是指核算主体。

与境内支付单主体、单币种不同，跨境支付涉及到跨主体、多币种。为了能够说清一笔跨境支付，我就虚拟出了3个主体（微信支付中国 WPCN，微信支付香港 WPHK，微信支付韩国 WPKR），假设每个主体只做单一业务，也就是只有一个核算主体。

记账的要求是每个核算主体、每个币种都要有单独的账本。

OK，下面就到了资金管理领域最最最最最最难理解的部分了，我会把大致资金流画出来，但我并不打算立刻解释为什么账要这么记，设置这些账户的目的是什么。这部分需要比较深的业务背景和账务知识，外行看起来会很晦涩枯燥。

资金流并不是只有唯一一种画法（与业务流程设计有关），这里以资金通路二为例，仅供参考：

是不是很晕？没关系，对于没有账务背景的同学，目前只需知道两点就够了：

1. 资金流的箭头不代表记账顺序，只代表记账的借贷关系，顺序用数字标出来了。
2. 虚拟资金流就是物理资金流的展开，虚拟资金流的第一个节点和最后一个节点与物理银存对应，中间节点表示资金所处的中间态。

7.6 流动性管理

咱也问了一下 GPT，什么是流动性（Liquidity）管理？

资金流动性管理是指企业或金融机构对其资金流动性进行监控、分析和优化的过程，以确保在需要时能够迅速获取足够的现金或现金等价物，以满足短期的财务需求和运营支出。流动性管理的目标是平衡流动性风险与收益，确保企业在任何时候都能履行其财务义务。

害~这种专业术语，就是懂的人都懂，不懂的人问完也是一脸懵。

还是我来说吧。我们先来看看在支付业务，尤其在跨境支付中为什么需要用到流动性管理？

1. 跨境支付的资金交割链路比较长，中间任意环节卡住了都有可能影响资金交付时效，毕竟每个商户入驻都签订了结算协议的，未在约定的结算周期内完成结算，轻则影响商户的现金流，重则影响平台的声誉，可能面临赔偿
2. 某些场景下或许会通过垫资的方式加快资金交付效率，提升产品的竞争力。

不管是上述哪种场景，都是需要识别出哪些环节可能存在资金短缺，并及时通过其他手段（如资金调拨）填补短缺资金，以确保业务运营的稳定性，这就是流动性管理。

要达成这一点，我们就需要做到：

1. 对资金流量的预测。流动性管理需要熟悉全局的资金流动情况，并根据历史数据的分析，预测未来的资金流量
2. 对资金水位的监控。跨境业务需要在全球不同国家和地区开设许多银存账户，流动性需要监控每个账户的资金水位，识别潜在的流动性短缺
3. 要具备全球流动性调拨机制。例如现在需要紧急调拨1亿韩元进入韩国，可能某些银行在非工作时间，无法受理大额跨境请求，这时就要考虑从其他时区调入资金
4. 跨境业务还需多考虑一个外汇因素。避免因某个币种外汇储备不足导致业务受影响，但也不能储备过多的外汇，需承担汇率波动风险

07、总结

我们来总结一下，把资金平台这个黑盒子打开，看看里面到底长啥样。

跨境业务是非常复杂的，本文也只是走马观花，把主流程大致盘点了一下。后续还会展开更多技术架构和实现细节，可以关注公众号了解更多。

欢迎关注原文作者 Louis 的公众号：支付进阶之路👇

-End-

原创作者｜Louis