都说“字不如表，表不如图”，在支付系统这种专业领域，有时候能起到“一图胜千言”的效果。本文作者通过60张手绘图片，和大家分享了支付系统最核心的概念，供大家参考。
支付系统因其专业性，术语或概念稍为晦涩不好懂。而我向来喜欢“一图胜千言”，所以为支付系统相关的概念画了300多张手绘风格的图，摘录部分供各位参考。
极致简化，真实的实现会复杂非常多。
在账务系统中，通常包含以下几种账户类型：
说明：
1）账户类型与借贷方向，相同为加，相异为减，也就是所谓的：DD+，DC-，CC+，CD-。
2）示例：用户提现100元，记账如下：
一般来说，客户账户的记账需要是实时的，比如用户充值、提现，商家提现，用户退款等。
这些账户如果不做实时记账，一来有损用户体验，二来有资损风险。比如用户充值100块，如果延时不到账，用户可能会投诉。如果提现不实时记账，用户有可能重复提现成功。如果退款不实时记账，有可能在退款场景下被透支。
假设记账需要几十毫秒（数据库性能决定的），一个账户最高也就只支持几十个TPS的记账请求，对于一些高并发的账户（也称为热点账户）一定是性能不足的。这个时候一般使用缓冲记账，以提高性能。开通缓冲记账的，通常是内部账户或允许商户透支的流出场景。
缓冲记账通常就是先记录流水，然后起定时任务去捞取流水，汇总后进行记账。前提是一定要做好资损防控。
除了缓冲记账外，还有拆分账户的方式来解决热点账户问题。
还没有画好，占个坑。
会计科目就是把会计要素进行分类，比如资产、负债等。通常都会有多级分类。
会计科目示例：
说明：
有了账户和会计科目，发生一笔交易时，如何让系统自动去记账？这个是记账方案做的事。其中一个解决方案就是给不同的交易场景制定不同的交易码，通过交易码来驱动记账。
下面是一个典型的支付系统的记账方案示例。
会计日，也称为会计结算日或账务结算日，是支付平台在会计周期中进行账务处理和结算的特定日期。比如在分布式环境下，各机器可能存在时间差，一笔交易在零点时有可能跨天处理，如何判断一笔交易归属于哪天，就依据会计日来计算。
所谓日切，简单理解就是切换到下一个会计日。主要做的工作：
日切试算平衡核心逻辑：
对账一般有几种结果：
因为我方和渠道之间有一定的时间差，所以长短款在T+1对账对不上时，往往先进入存疑清单里面，第T+2对账还是对不上，才会进入差异处理。
还没有画好，占个坑。
第一层是信息流明细对账。我方流水和银行清算文件的流水逐一核对。可能会存在长短款情况。
第二层是账单对账。就是把我方流水汇总生成我方账单，然后把银行流水汇总生成银行账单，进行对账。可能会存在银行账单和我方账单不一致的情况，比如共支付100万，渠道分2次打款，一笔98万，一笔2万。
第三层是账实对账。就是我方内部记录的银行头寸和银行真实的余额是否一致。可能存在我方记录的头寸是220万，但是银行实际余额只有200万的情况。
我们通常说的记账，哪怕是一笔简单的支付，也会有多次记账。具体在什么节点记什么账，一般由财务人员决定。
下面是一个典型的使用银行通道进行支付的记账，会涉及网关过渡户，渠道待清算，商户待结算，手续费，银行头寸等多个内部户。
说明：
商户结算和用户支付是两个独立流程。
以典型的商户结算到卡记账为例，通常涉及商户待结算户，网关过渡户，渠道应清算，渠道已清算，银行头寸等内部户。
说明：
金融机构的记账一定是基于复式记账法。下面以用户通过支付平台使用银行支付500块为例做个简要说明。
假设：支付平台使用CMB做为收单行，在CMB开设有备付金账户。
涉及的支付平台内部账户：
记账步骤：
说明：
1）持牌支付机构的记账一定是复式记账法。内部开设了很多账户和科目。
2）借贷简要公式（不太严谨，但是够用）：
3）复式记账的专业书籍很多，这里只摘录几个重要的说明：
支付平台尤其是持牌的收单机构通过都会提供非常多的服务，除了常见的支付、退款、提现等业务外，还会提供个人账单查询，商户账单下载等服务。
这里只介绍对客（包括个人客户和商户）感知的最核心的几个服务。
一个持牌支付机构的系统一般会提供以下几个核心的对客能力：
一些跨境场景下，支付系统还需要提供外汇服务，比如中国商家在多多的海外品牌temu卖货，用户在美国支付的是美元，但是中国商家需要在中国拿到人民币。
除此之外，还会有很多辅助能力，比如商户入驻，商户自助服务，个人自助服务等。
任何一个业务在支付系统内部都是由多个子域经历很多操作步骤才能完成。比如支付业务的下单子流程，先是入口网关的验签，解密，然后请求商户平台的权限校验，再请求风控系统做风控校验，产品中心做产品校验等，最后在收单域保存入库。
说明：
资金流在后面的账务章节会详细介绍，这里只做个简单说明。
首先是虚拟资金流，也就是支付平台内部的资金流，以即时到账模式为例，如下：
说明：
实体资金流就是外部银行之间的资金流转。
说明：
比如：收到商户的退款请求后，需要先查询历史合约，检查合约是否支持退款，是否过了退款有效期，是否满足最小退款金额，全部通过后，就创建退款单并保存。接下来会进入退款资金准备阶段，因为从资损防控的角度，除非另有合约约定，否则支付平台一般是不会做垫资退款的。在退款资金准备阶段，需要实时扣减商户待结算户的钱，这是与支付流程很大不同的点。当然，有些支付公司可能和商户约定从独立的退款账户进行扣款，那也需要保证这个退款账户余额充足。
说明：
外部渠道支付成功、或退款成功，都会涉及清算流程，简单地说，就是外部渠道把当天的支付、退款交易数据先进行轧差，然后生成一个清算文件，支付平台拿到这个文件后，解析并与内部的交易进行对账，对账成功后，从待清算户到应清算户，在渠道真实打款后，查到账单，再从应清算到银行头寸。
更详细的可以参考后面的账务域内容。
说明：
在收单机构（支付平台）里，结算就是把帮商户收进来的钱，按约定的结算规则、准确、及时地结算给商户。
结算前需要先做清分，就是把一笔支付的钱，根据当初签订的合约分成若干份。比如支付100块，平台手续费1块，商户99块。
根据合约，可以结算到余额，也可以结算到卡，结算还有结算周期，也就是所谓的T+n，其中的T是指交易时间，n指第几天结算。比如T+0就是当天的交易当天结算，T+2就是当天的交易在第3天才结算。
充值就是把用户的钱充到支付平台余额账户。余额因为涉及到资金安全，所以无论国内国外基本上都是需要持牌经营。
很多持牌机构都想让用户做充值，好处也很明显，比如：
充值的核心只有2个点：
转账、代发、调拨的本质就是把资金从一个账户转到另一个账户。三者之间有一些细微的区别：
还有两种比较特殊的转账，就是发红包和AA收款。一对一的红包，本质就是一对一的转账，一对多的红包，本质就是一对多转账。AA收款的本质就是多对一的转账。
以转账到银行卡为例，用户A把自己的余额100元转给B用户在招行的银行卡，如下：
说明：
提现的本质也是转账，只是用户把支付平台余额账户的钱，转到自己在外部渠道的账户里。
与一般意义上的转账的区别在于，通常情况下说的转账是不同用户或商户之间的转账，而提现默认是自己余额账户的钱提到自己开设在外部银行的账户。比如支付宝或微信余额提现到自己在招行的账户里。
外汇业务表面上只是把一种货币换成另外一种货币，但是实际情况下是非常复杂的。比如需要区分自由流动货币和管制货币，交易有即期、远期、掉期等，涉及跨境电商有结汇入境和入境结汇。另外，外汇市场是全球最大的金融市场。
无收单机构模式
这就是小时候去小卖部买糖的模式，一手交钱一手交货。
好处：足够简单。不足：无法完成线上交易。
行内收单模式
所谓行内收单，就是发行卡和收单是同一家银行。
好处：手续费低，成功率高。不足：业务比较受限，以线下收单为例，商户无法部署所有的银行POS机。
发卡行与收单行分离模式
大部分情况下，用户的发卡行和商户的收单行是不同的银行。
不过，这种情况基本也已经灭绝，因为需要发卡行和收单行两两对接，形成一个巨大的网状结构，维护成本高昂。
清算机构模式
发卡行和收单行之间不再直连，而是通过清算机构。清算机构通常是央行下面的特许经营的金融机构。这样围绕清算机构形成一个星形架构，所有银行只需要和清算机构对接就行。
当前银行间的交易基本上是这种形态。比如中国的银联，国外的VISA，MASTERCARD等，是卡组，也是清算机构。
第三方支付（电子钱包）形态
随着互联网支付的兴起，以第三方支付为中心形成另外一个星形结构。
上图做了很大的简化。在中国因为断直连的关系，支付宝、微信支付背后的财付通等这些第三方支付机构都是对接银联、网联，而不是直连银行。但是在国外仍然是允许直连银行的。
支付前需要调用收银台查看用户可用的支付方式，简称支付咨询，或支付方式咨询。
上面的图分别是电商（京东）的收银台，支付平台（微信支付）的收银台。说明收银台是有多种存在形式的。
支付咨询阶段，需要做以下几个工作：
最后把支付方式返回给用户，供用户在支付时选择。
用户选择好支付方式，点击“确认支付”，就到了支付受理阶段。主要做以下几个工作：
特别说明一下：为什么轮询结果是从收单平台而不是支付引擎？因为对用户而言，收单的结果代表最终的支付结果。比如用户支付回来后，支付引擎是成功的，但是收单平台因为已经订单过期关闭，就会发起资金退回操作，这样收单平台的订单实际是没有支付成功的。就会提示用户：“订单已关闭，如果已经扣款，支付款项预计在X个工作日内原路退回。”
有些公司称为通道，有些公司称为渠道，都是一个意思。下面统一称为渠道。
渠道类型在各个公司的定义是不一样的，没有一个行业标准，且持续在发展。先讲几个当前仍然通用的分类。
从资金流转的角度，渠道分为四大类：支付渠道、流出渠道、外汇渠道、信息渠道。
支付渠道
这类渠道的核心作用是实现用户资金的流入。具体来说，它们将用户在银行账户中的资金转移到支付平台在银行的备付金账户。这个过程在我们日常生活中极为常见，典型的场景包括用户的充值操作和在线支付。
例如，当你使用手机应用进行购物支付时，资金从你的银行账户流向支付平台的账户，最后再结算给商户，就是通过这类渠道完成的。
流出渠道
相对于资金的流入，流出类渠道则处理资金的流出。这包括两种主要情形：
流出类渠道确保了资金在用户和商户之间的顺畅流动，是整个支付系统的重要支撑。
外汇渠道
这类渠道涉及货币兑换和跨国资金转移，支持不同货币间的转换和结算。在跨境电商、国际旅游等场景中，外汇渠道提供了跨币种资金转换的关键服务。且随着全球化贸易的增长，跨境支付需求日益增加，外汇渠道的作用变得更加重要。
信息渠道
这类渠道不涉及资金流转，比如个人实名认证（KYC），银行卡绑卡（纯绑卡）等。
支付类渠道
随着业务和技术的发展，支付类的渠道定义也是千奇百怪，或者说是与时俱进，下面是一些通用的分类。
卡渠道
借记卡/信用卡支付：这是最传统且广泛使用的支付方式之一。用户通过输入卡信息进行支付，资金直接从其银行账户扣除。其中信用卡还有预授权、请款，2D、3D等场景。
还有所谓的预付卡，就是提前充值的支付卡，用户支付时，资金从预付卡余额中扣除。这个在支付平台一般不感知。
欧美国家的信用卡支付普遍使用得比较多。
除了使用卡明文直接支付外，现在很多渠道还支持先绑定后使用token支付的模式：
支付流程和卡明文支付差不多，只是在发给渠道的报文中使用token替换了卡明文。
卡支付的交易有所谓的四方模式：商户、收单行、卡组、发卡行。这里的四方指的是四种类型的机构。
网银渠道
通过跳转到银行网站完成支付。这个操作麻烦，可能还需要密码控件，成功率不高，在中国已经很少使用。国外还有不少。
快捷支付渠道
用户事先在支付平台绑定银行卡，支付时无需重复输入卡信息，便捷快速。在中国率先被支付宝发明出来并被推广，支付成功率从网银的60%左右提升到了96%以上。
国外有些叫“一键支付”，差不多一个意思。
代扣渠道
代扣支付是一种银行或第三方支付平台在用户授权的基础上，直接从用户的银行账户或关联的支付账户中自动扣除款项的支付方式。
这种方式和快捷支付最大的区别在于：快捷支付是用户实时参与交易过程，有可能出风控挑战，比如OTP（短信验证码），或者密码等。代扣是提前授权，交易过程用户不会实时参与，也就没办法出挑战，要不成功，要不失败。
代扣广泛用于周期性支付场景，如水电费自动缴纳、会员服务费、订阅服务等，还有就是滴滴打车这种，下车就走。这种方式免去了用户每次手动支付的麻烦。
第三方钱包渠道
基于第三方钱包账户基础之上的支付。在中国有支付宝、微信支付等，在国外有PayPal，GCash等。
第三方钱包通常是一个综合支付工具，除了钱包余额，钱包里面可能还绑定了银行卡。
钱包通常提供两种交互模式：
VA渠道
Virtual Account, 虚拟账户。用户通过银行生成的虚拟账号进行支付，常用于无卡支付场景。在东南亚用得特别多。
简单地说，就是用户没有银行卡，但是又要在网上购物，那么支付平台调用银行生成一个VA，并把这个VA和订单绑定，再展示给用户，用户拿着这个VA，去银行的ATM或银行柜台把现金存进去，银行通知支付平台这个VA入账成功，支付平台通知商户发货。
VA还会用于商家的收款（VA来账），这个是另外一个范围，不归属于支付类渠道。
OTC渠道
Over-The-Counter，柜台支付。在支付场景下，和VA很类似，也是生成一个支付码，只是这个支付码是由7-11，肯德基等这些连锁店生成的，而VA是银行账户。用户拿着这个OTC码去线下连锁店，给店员现金，店员给这个OTC码充值，连锁店系统通知支付平台支付成功，支付平台通知商户发货。
信用付渠道
渠道根据用户的信用授予一定的额度，可以先消费，后还款。国外通常叫BNPL（Buy Now Pay Later)。
国内有支付宝的花呗，京东的白条。国外也有很多第三方金融机构提供类似的服务。
支付流程和第三方钱包差不多，只是需要先做开户和额度授权。
信用付与信用卡分期的区别：信用卡分期是以银行发行的信用卡为基础，而信用付基于第三方金融机构的账户授权（没有卡，非银行也能提供服务）。
在一些银行卡普及率不高的国家地区，信用付很有优势。
渠道路由核心作用是当有多个渠道同时满足业务诉求时，综合支付成功率、支付成本、用户体验、渠道状态等多种因素挑选出最优的一条渠道。具体如下：
说明：
说明：
说明：
说明：
如果换成时序图，如下：
说明：
我们以最典型的电商购物举个例子（只是举例）：小明使用PayPal在拼多多电商（海外）通过多多钱包（海外）支付了50美金。
经过简化后的交互图如下：
说明：
说明：
在支付流程中，就是商户委托收单机构（支付平台）把用户的钱收回来，然后再把钱结算给商家。
下面以典型通过外部渠道的卡支付为例说明。
说明：
说明：
说明：
说明：
支付安全核心关注点：
支付安全是一个很大的范畴，但我们一般只需要重点关注以下几个核心点就够：
对个人和商户/渠道的敏感信息进行安全存储。
个人敏感信息包括身份证信息、支付卡明文数据和密码等，而商户/渠道的敏感信息则涉及商户登录/操作密码、渠道证书密钥等。
确保客户端与支付系统服务器之间、商户系统与支付系统之间、支付系统内部服务器与服务器之间、支付系统与银行之间的数据传输安全。这包括采用加密技术等措施来保障数据传输过程中的安全性。
确保交易信息的完整性和真实性，防止交易信息被篡改或者被抵赖。一笔典型的交易，通常涉及到用户、商户、支付机构、银行四方，确保各方发出的信息没有被篡改也无法被抵赖。
识别并防止欺诈交易，包括套现、洗钱等违规操作，以及通过识别用户信息泄露和可疑交易来保护用户资产的安全。这一方面通常由支付风控系统负责。
防范DDoS攻击，确保支付系统的稳定运行和服务可用性。通过部署防火墙、入侵检测系统等技术手段，及时发现并应对可能的DDoS攻击，保障支付服务的正常进行。
所有支付公司都对资损（资金损失）看得很重，轻则钱没了，重则舆论风波，要是引起监管介入，更是吃不了兜着走。
常在河边走的支付人，如果想少湿鞋，一定要了解资损防控体系建设。
资损本质
资损防控本质
资损防控全生命周期
资损风险分类
资损场景有很多种，但分类只有下面几大类：
资损场景及应对
过于庞大，略过。
一图胜千言，希望这精选出来的60张高清大图对大家学习支付系统设计与实现有所帮助。
内容主要包括支付系统核心业务，支付流程，结算流程，跨境收单，信息流与资金流，账户设计，记账，对账等。
相关的概念大部分做了极致简化，用于入门是极好的，对于理解概念也是够用的。不过真实的实现会复杂非常多。
这些概念如同支付核心系统拼图的一些小碎片，串起这些小碎片，对理解支付系统大图是大有裨益的。
深耕境内/跨境支付架构设计十余年，欢迎关注并星标公众号“隐墨星辰”，和我一起深入解码支付系统的方方面面。
这是《图解支付系统设计与实现》专栏系列文章中的第（50）篇。
作者：隐墨星辰，公众号：隐墨星辰
本文由 @隐墨星辰 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。