1.4　支付架构

先有树木，再有森林。

随着支付业务的发展，需要处理的支付业务场景越来越多、交易量越来越大，逐渐衍生出各个支付模块，从而有了越来越丰富、越来越健壮的支付系统及架构。系统里的模块就像森林里的树木一样，树木多了，种类多了，自然就形成了一个生态丰富的“支付”森林。

这一节，我们一起看看一个支付系统是如何从简单到丰富地演进而来的。

在早期阶段，支付用来承接商户（包括内部和外部商户）交易，组织报文，上送给银行，进行交易，用来获得中间收入。

起初最简易的支付系统结构如图1-9所示。后来接入业务越来越多，支付逐渐演进，支付系统也越来越健壮。

图1-9　简易支付系统结构

凡是用到支付的业务场景，我们称之为“支付场景”，比如零售、用车、机票、酒店等。为了满足各行各业的支付需求，为了符合行业特性，更多支付工具和支付产品被开发出来，用于收单业务。

支付工具是进行货币债券转移的媒介。常见的支付工具有API、SDK、移动端、二维码、电话语音支付（Interactive Voice Response，IVR）、POS（Point Of Sale）支付等。

支付产品是根据支付方向和一定特性所提供的服务。支付中常见的产品有代付产品、鉴权产品、主扫产品、被扫产品和收款产品。

支付系统开始有了更多的商户、更多的调用请求，有了很多新要求需要思考与处理。比如接入问题，接入的时候要考虑接入安全，拒绝恶意或者未授权的调用，做好准入控制；流量大了，请求多了，要进行分流与队列处理，以保证交易的高可用；逐渐就有了支付网关（网络的关隘），支付网关就像门卫一样对前端调用后端服务进行验证，进行流量控制、准入控制、安全控制等。

支付请求进来后，系统需要从支付成本、支付体验、支付风险、支付成功率等维度以及灾备处理方面进行综合考虑，以保证实现交易处理的最优解。比如，在接入多个支付通道后，要考虑该怎么分配流量请求，于是有了路由系统；当银行、卡组织或者第三方支付愿意贴补营销费用时，要考虑如何扣减和展示，于是有了营销系统；当一笔订单有多个商品或者多种支付方式时，要考虑对于组合订单或者组合支付如何分账，于是有了订单系统、分账系统；当用户的一些支付要素已经保存时，在保证安全的前提下，要考虑用户再次支付时如何进行反显或者省略输入以避免用户重复填写，进而提升转化率，于是有了常用卡系统。

考虑点与服务多了后，就有了统一的产品服务层。

商户和通道多了后，要考虑如何高效、及时、准确地处理对账问题。人力的增长赶不上业务的增长，系统从最初的手工拉取账单变成系统自动生成系统，从每月对账变成每日对账，开始有了各种各样的系统来处理账单，比如计费系统、对账系统、结算系统、会计系统、差错处理系统、清分系统、对账文件服务等。这些系统一起构成了清结算系统，于是有了清算核心层。

消息的推送与数据的统计和监控需要依赖各类服务来实现，如短信服务、通知服务、数据监控、数据统计，于是有了支撑服务。比如，为了方便一些业务查询与问题处理，如商户后台、报表后台、资金管理后台、业务运营和客服查询后台，于是有了内部运营后台；为了方便一些服务的基础信息配置，如联行号、地理信息、行业信息、支付品牌、支付方式等，于是有了基础信息服务。

支付系统逐渐从简单走向健壮，从一棵树发展成整片森林，演进成如图1-10所示的结构，其中涉及的主要模块会在后续章节具体介绍。

图1-10　支付架构