注：这是二次修订版，重发，已读请忽略。
我喜欢马斯克经常挂在嘴边的第一性原理，探寻事务的本质，所以这篇文章也尝试化繁为简，讲清楚在线支付系统最核心的一些概念。
进入正题前，先讲个小故事。
那天早上，我穿上最帅的衬衣、笔挺的西装裤、贼亮的皮鞋，推开房门，清风徐来，朝阳灿烂，一如我的心情，意气风发。那是我进入蓬勃发展的第三方支付行业的第一天。艺术来源于生活，电影里美好的开幕往往也是悲剧的开始，我和支付行业的相爱相杀也是如此。
入职当天老板扔了很多文档给我，看了一周，没看懂。想起老祖宗说的“读书百遍，其义自见”，继续看了一周，仍然是雾里看花，不知所云为何物。不幸中的万幸，是挺过了试用期。直到多年后，突然有一天，回顾那些资料，如打通仁督二脉一样，悟了：这些资料写得如此晦涩难懂，还不如我来操刀。
于是我就自己写起来。这是第一篇。
1. 基本概念
下面描述的概念大部分做了极致简化，只是用于入门，对于理解概念应该是够用的。真实的实现会复杂非常多，后面的系列文章会展开做详细说明。
后面的描述中，经常混着用“支付系统”、“支付平台”，本质是一个东西。在内部来说，就是一个支付系统，但从和外部机构交互来说，就是一个支付平台。
1.1. 最简支付流程
说明：
这是一个最简化的支付流程。真实的交互比这个复杂得多，单收银台渲染就可以写一整篇文章。但对于讲清楚支付系统的作用，已经足够。
从图中可以引申出支付系统最核心的作用：帮商户收钱。
有支付当然就有退款、撤销等逆向操作，复杂的跨境支付还会有外汇交易，跨境结算等业务。这些全部在后面的系列文章中细讲。
1.2. 最简清结算流程
说明：
这里画的是信息流。
银行和支付平台之间是机构对机构的关系，通常使用清算概念，因为金融机构之间大部分情况下会有独立的清算机构做清算服务。
支付平台和商户之间，通常使用结算概念，由支付平台直接打款给商户。
上面画的是结算到商户开在支付平台的内部账户余额，所以需要商户手动提现，支付平台通常也支持直接结算到卡，这样就不需要商户手动提现。
清结算三个字还有另外一层含义：清分 + 结算。前者是把钱算清楚，后者是真实打款。
1.3. 最简本对本收单流程
说明：
所谓本对本收单，就是指商户的商品标价币种、向支付系统的下单币种、用户支付币种、商户结算币种都是同一个币种。不涉及到外汇交易。
一个中国人拿着中国招商银行信用卡在淘宝或京东买东西，就是标准的本对本收单。
1.4. 最简跨境收单流程
说明：
所谓跨境收单，就是结算给商户的币种和用户支付的币种不一样，需要经过外汇机构换汇。
在扣款EUR成功后，支付平台会调用外部的外汇机构进行锁汇（HA）。
在银行清算后，支付平台再调用外部的外汇机构进行真正的换汇（TA）。
最后支付平台结算给商户USD。
如果换成时序图，如下：
1.5. 最简信息流与资金流
说明：
用户在支付平台充值10元，支付平台向银行发起扣款请求，这些指令操作归属于信息交互，属于信息流。
真实资金流：银行账户余额的变动。比如：银行在内部把用户的余额减10元，给支付平台备付金账户加10元。
虚拟资金流：支付平台内部账户余额的变动。比如：支付平台内部把银行应收账户加10元，给用户余额账户加10元。
为什么会有真实资金流和虚拟资金流之分？因为我们真正能拿到钱的地方是银行，在支付系统内看到的只是一个数字，如果想变成真实世界的钱，还得发给银行提现。
1.6. 跨境收单的协议关系
说明：
这只是跨境收单的一种协议关系，真实场景存在多种形态。
上述的收单机构是持牌的，但是没有跨境结算的能力，所以需要委托有跨境结算牌照的金融机构代为处理跨境结算业务。
跨境电商平台只是一个商户平台，没有收单资质，所以需要委托收单机构给它下面的供应商结算打款。
剩下的协议关系都是一目了然的，只是我们日常没有注意。比如用户和电商平台之间在注册时就会有会员协议要签署。
特殊的情况下，一些实力雄厚的机构，比如蚂蚁或财付通，下面会成立多个实体（不同的法律主体），然后用不同的实体去申请不同的牌照（收单、银行、外汇、跨境代发等），这样表面上全部是一家公司搞定，但是实际的协议关系仍然是上面这样的，在各实体之间仍然需要签署各种协议。
如果是本对本收单场景就简单很多，没有外汇和跨境结算这一层关系，如果跨境电商的货品全部是电商实体自营的，那就更简单，没有供应商委托结算的协议。
一般电商平台在没有牌照情况下是不能开设余额账户的，如果电商想开通余额，可以委托第三方有牌照的公司托管（通常也是收单机构，收单机构一般会同时申请PA、PG牌照），这种情况下，电商平台和收单机构还会签署账户委托协议。
1.7. 跨境资金方案
说明：
这是一个典型的跨境资金流案例。用户支付USD，收单机构收到的是USD，但是需要结算RMB给中国境内的商户。
收单机构（也就是支付平台）需要先将USD兑换成CNH（离岸人民币），再由入境代发机构把RMB结算给中国境内商户。这是所谓的“结汇入境”。
如果采用“入境结汇”的方式，则收单机构直接结算USD给商户在境外的银行账户中，由商户以USD汇入境内，再兑换成RMB。或者收单机构先把USD汇入境内备付金账户，再兑换成RMB，然后再结算RMB给中国境内商户。
以上这些不同的资金处理方案，统称为资金方案。
1.8. 简明复式记账
金融机构的记账一定是基于复式记账法。下面以用户通过支付平台使用银行支付500块为例做个简要说明。
假设：支付平台使用CMB做为收单行，在CMB开设有备付金账户。
涉及的支付平台内部账户：
账户类型 | 账户 | 备注 |
借记账户 | 应收-渠道-CMB | 应收归属借记账户 |
贷记账户 | 应付-过渡-网关过渡户 应付-平台托管-商户待结算 应付-平台托管-商户余额 手续费收入-商户-消费 | 应付归属贷记账户 手续费意味着所有者权益增加，归属贷记账户 |
记账步骤：
阶段 | 操作账户 | 金额 |
第一步 资金从渠道到网关过渡户 | 借：应收-渠道-CMB 贷：应付-过渡-网关过渡户 | 500 |
第二步 扣除手续费 | 借：应付-过渡-网关过渡户 贷：手续费收入-商户-消费 | 10 |
第三步 网关过渡户到商户待结算账户 | 借：应付-过渡-网关过渡户 贷：应付-平台托管-商户待结算 | 490 |
第四步 结算给商户 | 借：应付-平台托管-商户待结算 贷：应付-平台托管-商户余额 | 490 |
说明：
支付系统的记账一定是复式记账法。内部开设了很多账户和科目。
【借记类】账户：资产，应收款等；
【贷记类】账户：负债，所有者权益，应付款等；
借贷简要公式（不太严谨，但是够用）：
【借记类】账户（如资产，应收款），【增加】为【借】，【减少】为【贷】；
【贷记类】账户（如负债和所有者权益，应付款），【增加】为【贷】，【减少】为【借】；
复式记账的专业书籍很多，这里只摘录几个重要的说明：
复式记账法定义：对每项经济业务按相等的金额在两个或两个以上有关账户中同时进行登记的方法。
记账原则：有借必有贷，借贷必相等。
记账依据：会计恒等式：1. 资产 = 负债 + 所有者权益；2. 利润 = 收入 - 费用。
账户：具有一定格式和结构，能够用来连续、系统、全面的记录反映某种经济业务的增减变化及其结果。
科目：同类财务交易的分类，比如资产、负债、所有者权限、收入或费用等都属于科目。一般科目会分为多级。
账户和科目的区别：科目只有名字，账户包括结构和格式，每个账户对应一个特定的科目。
2. 概要设计
2.1. 简明产品架构图
说明：
这个图画得比较简单，但是已经涵养一个支付系统最核心的产品能力。
上面部分是会员或商户感知的产品能力，包括门户、收银台，收单产品，资金产品等。下面部分是支付系统最核心的服务，用于支撑对外的产品能力。
2.2. 极简支付系统架构图
说明：
这个图很精简，但是基本已经够用，应付本对本交易这种简单的业务是完全没有问题的。
一些复杂的支付系统可能还有外汇、额度中心、产品中心、卡中心等，甚至一个子系统可能会拆分为多个应用独立部署，比如收单结算就可以拆成收单和结算两个独立的应用。
2.3. 完整支付系统架构图及各子系统简介
说明：
这是一比较完整的系统架构图，属于逻辑划分。在单体应用中，就是一些模块，在分布式应用中，就是一些子域、子应用或子系统。
以下是各子系统简单介绍：
开放网关：主要对接商户，比如下单、支付等接口入口。通常要求有比较高的安全性。部分公司可能会把移动端网关、PC门户网关、商户通知等能力集成在开放网关，也可能会单独拆出部署。
收单结算：负责把商户的单收下来，并给商户发起结算。承担的收单产品包括有：线上收单，线下收单，担保交易、即时到账等，每个公司的商业策略不同，开出的收单产品会有差异。
资金产品：承担无买卖标的的纯资金转移能力。典型的有：充值、转账、提现、代发。和支付的区分在于支付是有买卖标的，而资金产品没有。也就是在系统中没有买卖记录发生，但在线下可能有。
收银核心：渲染可用支付方式。包括查询账户是否有余额，查询营销是否有营销券，查询渠道网关是否有可用的外部渠道，最后组合成可用支付方式，供前端渲染。
支付引擎：负责真正的扣款或转账。有些公司叫支付核心，或资产交换。个人认为资产交换更合适，因为无论对于支付、退款、充值、转账等各种交易，本质都是把资产从一个账户交换到另外一个账户。
渠道网关：负责去外部渠道扣款。通常还会提供渠道路由、渠道咨询等能力，做得细的公司可能下面再细分为渠道产品，报文网关和文件网关。
会员平台：管理会员的注册、登录、密码、实名认证等。
商户平台：管理商户的入驻、登录、交易管理等。
产品中心：管理平台对外提供的产品能力。一般大的支付系统才会独立成一个子系统。
资金账务：负责账户开立，记账等。
会计中心：会计科目管理、分录管理、日切管理。
对账中心：负责明细对账和资金对账。
营销平台：提供满减、红包等营销工具。
风控平台：针对账户和交易，提供实时、离线风控，控制平台的风险。
运营平台：订单管理、渠道管理、产品管理等综合运营工具。
数据平台：主要用于数据汇总和分析。分布式部署后，数据都在各子系统中，需要汇总到数据平台用于经营分析。
卡中心：负责管理用户的绑卡信息。需要经过PCI认证。
额度中心：累计用户、商户的额度，通常有日、月、年等各种分类。
外汇平台：负责外汇报价和兑换。
流动性与调拨中心：一些跨境支付公司，在多个国家多个银行有头寸，各头寸之间经常需要做流动性管理，提高资金利用率。
差错中心：负责差错处理。比如渠道退款失败，需要通过其它的方式退给用户。
拒付中心：处理用户的拒付和举证。在跨境支付场景下，信用卡用户联系发卡行说卡被盗刷或商品没有收到，或商品有问题等，拒绝支付给商户。
2.4. 核心系统依赖图
说明：
图中画得比较清楚了，没有太多需要补充的。
其中红色线为支付主链路。
3. 常见术语索引
内容太多，已经独立出去，具体参考“图解支付系统设计与实现”电子书的附录部分。
4. 结束语
所谓提纲挈领，就是先掌握核心主干，有了这个前提，再去深入了解细节，才不至于“乱花渐欲迷人眼”，解决问题时才能如庖丁解牛，行云流水。
本文主要讲了一些支付相关的基本概念，支付系统的概要设计框图，部分核心流程，以及一些常见的术语，希望能为大家在学习在线支付系统相关知识时能提供一些有益的参考。
这是《图解支付系统设计与实现》专栏系列文章中的第（1）篇。欢迎和我一起深入解码支付系统的方方面面。
专栏系列文章PDF合集，以及电子书《图解支付系统设计与实现》不定时更新，欢迎关注我的公众号获取：隐墨星辰。
有个支付小群，有兴趣的小伙伴可先加微信（yinmon_sc）后进入，添加微信请备注：666。
