解密支付系统，来看如何构建理想的支付系统架构
货币是人类发展史上一个极为重要的角色，它不仅是市场上物品交换的媒介，更是人类文明发展史上里程碑式的代表物。
几千年前人类在贸易市场上使用实物交换，可以想象一下我们的祖先进行市场贸易：一个人手上有羊奶，另一个人手上有牛肉，如果两个人都需要对方的物品，那么交换一下就可以了，这是最早的贸易。
但是随着人类文明的发展，这种实物交换已经无法满足人类的市场需求，比如拥有牛肉的人不喜欢羊奶，交易就无法进行。
这时候智慧的古人学会了使用媒介，大家所熟知的古时候的媒介是金、银、铜等。使用媒介给每种物品定价，所有的物品都可以通过媒介来购买和出售。
到了近代，金、银、铜的弊端也逐渐浮现出来，比如携带不便，大量金银放在身上会有安全隐患。在这种情况下，纸币应运而生，纸币的诞生解决了大部分金属货币的弊端，成本也非常低，并且携带方便。
随着科技的飞速发展，人类更加依赖电子产品，就出现了电子货币。货币发展经历的四大阶段如图1所示。
图1
每一种货币的发展都经历了漫长的过程，每一种货币能够生存下来都经历了严格的考验。现在电子货币深入我们生活的方方面面，我们去商场购物，去餐厅吃饭，搭乘交通工具等，带一部手机就可以解决所有的支付问题。使用手机支付需要依靠互联网，通过互联网实现支付能力催生出了一大批支付机构。
支付牌照的诞生
支付机构诞生之初市场是非常混乱的，没有统一的管理，没有统一的规范，所有的支付机构可以直接对接银行，可以实现资金留存，这样操作存在极大的风险，比如支付机构“跑路”了会造成很多人的资金损失。
所有行业的发展都要经历从混乱到有序的过程，2005年6月中国人民银行（简称央行）出台《支付清算组织管理办法（征求意见稿）》，在一定程度上规范了支付行业。2010年6月《非金融机构支付服务管理办法》的出台使整个支付行业终于有据可依，行业发展得以规范化。2011年5月央行开始发行支付牌照，从事支付行业的人士都非常了解支付牌照（也称支付业务许可证）的重要性，有支付牌照的机构做三方支付业务才是合规的，不然就是所谓的无证机构，是央行严厉打击的对象。
目前全国有支付牌照的企业只有200多家，这200多家在央行是有备付金账户的，即客户资金是安全有保障的，且支付机构可以在此基础上为客户提供资金清算和管理的服务。
是不是只有有支付牌照的企业才能做支付业务？
答案是否定的，没有牌照的也可以，但是没有央行的备付金账户，所以不能进行资金的清算和管理，只能做支付信息服务，我们称之为聚合支付。
这样做的目的是保护消费者的财产安全，使市场更加合规稳定。有支付牌照的支付机构的业务流程如图2所示。
图2
没有支付牌照的支付机构的业务流程如图3所示。
图3
可以看出，有牌照和没有牌照的业务处理流程是不一样的，没有牌照的支付机构需要通过有牌照的支付机构实现资金的流转，并且有牌照的支付机构直接把钱结算给商户，资金不经过聚合支付机构。接下来出现的“支付机构”指的都是有支付牌照的三方支付机构。
支付业务架构
支付机构核心的两个职责一个是帮助商户把钱收上来，另一个是把收到的钱结算给商户。
这两个职责对应的两个过程分别是入金和出金，入金是指能够支撑客户的支付能力，把钱从C端客户的账户入账到支付机构的账户，出金是把收到的C端客户的钱结算给商户。
通俗地讲，支付机构就是帮助商户管好钱。支付的过程一定要做到高效且安全，C端客户在支付的过程中按照一般人的习惯不会等待超过7秒，7秒之内一定要支付完成，否则会给客户造成很不好的体验。
一笔支付要经过商户、支付机构、银联/网联，接着到达银行，然后银行再把结果返回，最终展示给用户，这个过程是非常漫长的。如果订单量比较少，几秒内完成这些工作完全没有问题，如果支付机构每天有上千万或者上亿的支付单量（比如支付宝、微信），保证支付的高效就非常难了。
支付的过程中有很多影响支付速度的因素，比如带宽、硬件设备等，这些因素对于开发人员来说应该考虑，但是并不能起到决定性的作用，开发人员能做的是使用最少的资源，实现最高的效率。
如何设计一套高效且安全的支付体系呢？
首先业务架构要清晰，支付体系的业务架构如图4所示。
图4
我们常使用的支付方式除了微信、支付宝，还有快捷支付（即绑定银行卡支付）。
微信支付包含扫码支付、JSAPI支付、Native支付、APP支付、H5支付、小程序支付等。
支付宝支付包含手机网站支付、APP支付、电脑网站支付等。
聚合支付机构要具备这些支付能力就需要对接对应的接口。合规的支付机构之间不能相互对接，只能和银联/网联对接。如果要具有微信、支付宝支付能力，则需要通过银联/网联来对接微信和支付宝。
支付系统架构发展历程
随着支付业务的发展，线上支付单量的增加，支付系统架构也经历了几次演进。早先使用线上支付的人非常少，一个支付机构的日单量可能只有十几万甚至几万笔。这时候不需要太多的系统资源，也不需要太复杂的架构设计，一个系统基本“搞定”所有的事情，如图5所示。
图5
同一个系统里的业务分不同的模块来处理，支付系统不外乎API接入、交易逻辑处理、商户维护、账务记录等。如果订单量小，那么这个架构没有问题，但是随着支付业务复杂性增加，订单笔数增多，系统的弊端就逐渐暴露出来了。
系统容灾能力弱：所有的模块都在一个系统中，某一个模块出现问题，会影响其他的模块，比如退款本身是可以异步执行的，如果因为退款业务的原因把正常支付的资源使用完或者拖垮系统就得不偿失了。
开发成本高，团队协作不灵活：所有的开发者都用同一套代码，编码版本维护成本高，调优发布风险大。
复杂业务扩展性差：随着业务复杂性的增加，系统的业务扩展能力会受到架构的严重影响，无法灵活修改系统的业务模块。
基于这些问题，流量大的支付机构就开始思考设计扩展性更好的支付架构来支撑不断增长的业务量和业务复杂度，首先考虑的是如何把系统拆得可用性强一些，系统的模块中的账务管理、商户管理、渠道对接是非常重要并且独立的，可以拆分出来，拆分后的系统结构如图6所示。
图6
这样拆分后系统扩展性相对来说就比较高了，但技术永远都是向前发展的，微服务思想大大提升了系统的可扩展性，接下来分析使用微服务设计支付系统架构的思路。
理想的支付系统架构
微服务的核心思想是把复杂的系统拆分为多个简单的子系统。明确了支付业务模型之后，需要把确定的支付产品转化为系统，以支撑我们的业务需求。支付体系架构经过多次演进，根据业务架构我们需要把系统拆解一下，每个小系统只负责一个业务模块。按照微服务的思想把支付系统拆分为多个小模块，如图7所示。
图7
每个模块都可以单独作为一个微服务的小系统，每个小系统负责不同的业务，某一个模块出现问题不会影响其他的业务模块。
支付网关是支付的入口，所有的交易都要经过支付网关再分发给各个系统，对支付机构起到门户的作用，给接入的商户提供统一的入口，方便商户的接入。
商户中心负责管理商户信息，商户想要使用支付平台，就要先提交入驻申请，把营业执照、法人信息、收款账户等上传到支付机构，支付机构存储并管理这些信息，在支付、结算的时候都需要用到这些信息。
支付核心系统（简称支付核心）负责处理业务逻辑，相当于一个系统的Service层，交易经过支付网关之后首先到达支付核心，支付核心根据交易报文的内容去“商户中心”收集信息，去请求“渠道”完成支付或者退款，去调用“账务”完成记账等。
账务系统负责管理商户的资金，商户入驻支付机构的时候，需要开通一个或多个管理资金的账户，商户使用支付渠道支付的每一笔资金都会在账户中体现，最终结算的时候也从账户中把资金结算给商户。
清结算系统负责把收到的资金结算给商户，结算的时候以支付、退款的明细为依据，把商户在支付机构的余额账户中的资金划转到商户的银行卡中。
计费系统负责收取渠道的手续费，一方面银联和网联要收取支付机构的手续费，另一方面支付机构会从中获利，是支付机构收入的主要来源。
渠道系统负责对接入金和出金的渠道，所有的支付机构不能和银行直接交互，需要通过银联/网联与银行交互。聚合支付机构可以对接三方支付机构。
一笔支付单在支付系统之间流转的过程如图8所示。
图8
所有的交易都要先经过支付网关，支付网关收到交易报文之后会进行验签、解密等相关的操作，校验完成之后转发报文到支付核心，支付核心会对业务字段进行验证、数据落库，然后请求渠道系统进行路由筛选，筛选出外部的交易渠道（使用银联还是网联），选定之后转发报文到银联或者网联，然后把支付结果返回到支付核心，支付核心把支付结果通过支付网关返回给商户。支付核心发送支付成功消息，清结算系统监听支付成功消息并把支付成功的记录落入数据库，等待发起结算。账务系统接收支付成功消息进行记账。支付的各个系统拆分之后，每个系统负责不同的职责，系统划分之后，就可以进行技术选型了。
本文节选自《支付架构实战》一书，欢迎阅读本书继续了解技术选型等支付架构设计的内容。
扫码了解本书详情
扫描下方二维码
参与抽奖赠书