从上帝视角看支付——支付总架构解析

如何高效地把握支付业务？或许我们可以从宏观角度入手，先对支付总架构有所认知。在这篇文章里，作者就从交易服务层、支付服务层、清算服务层等几大维度，对支付总架构进行了解析，一起来看看吧，或许对你建立支付业务的宏观视角会有所帮助。

不识庐山真面目，只缘身在此山中；如何完整高效的把握支付，不妨先从宏观入手知其全貌，了解都有哪些参与者，这些参与者有什么样的关系，信息在它们之间如何流动等一系列问题；然后再去深究每个环节的细节，都有哪些系统组成，这些系统之间的架构关系如何，数据如何传输，数据结构如何；如此以来我们才能系统的把握好支付。

为了更好的认识支付——下面我们就从用户出发，跟着一笔支付遍历整个互联网支付网络，建立起对支付最大宏观视角的认知。

一、支付全局分层

一笔支付以用户为起点，经过众多支付参与者之后，到达央行的清算账户，完成最终的资金清算。那么我们研究支付宏观，可以站在央行清算账户位置，俯视整个支付金字塔，如图1所示：

图1：支付金字塔

• 整个电子支付依靠众多参与者协同完成，这些参与者包括以下几类：
• 为用户提供线上交易场所的各类服务平台；
• 为这些服务平台提供支付服务的三方支付机构；
• 为支付机构提供支付通道的清算机构或者商业银行；
• 为支付业务提供收付款清算服务的网联银联；
• 做最终资金清算的央行等。

所以，一般场景下的支付都不是在一个平台完成的，而是通过在上述众多机构的系统之间传递支付信息共同完成的。对整个互联网支付按照参与者进行分层，可以得到一个支付总架构图，如图2所示：

图2：按照参与者分层的支付体系总架构

二、交易服务层

作为亿万互联网用户中的一员，我们都愿意为好的服务，好玩的产品买单。既然要买单，就需要付钱，当下互联网支付已经非常成熟，各种支付方式、支付应用琳琅满目；我们可以选择用微信、支付宝、银行卡、或者账户余额进行支付。

比如，618期间，我在京东用招商信用卡买了一本书，线上支付场所就是收银台，收银台是用户发起支付的起点，如图3所示。

图3：京东收银台收银台

而支付不是凭空发生的，往往需要发生在一定的交易场景中，例如我们常在京东购物，在美团点外卖，用支付宝转账，到去哪儿网买机票，这些都是交易场景，这些好产品让生活变得更加便捷。我们将这些平台称为互联网应用层。

这一层为用户直接提供商品、服务的交易场所和完成交易所需要的支付能力，是直接面向用户的互联网应用；用户在平台上购买服务，平台就需要有自己的支付体系来协助用户完成支付，例如收银台、交易体系、服务履约等。

1. 服务平台的支付架构

刚才我们说从电商平台买了一本书，那么一个典型的电商平台的支付架构是怎么样的呢？一笔支付在这样的平台内部是如何流转呢？我们进行逐一的分析。如图4是一个比较典型的电商平台的支付架构。

图4：电商平台的典型支付架构

从上图中可以看出来，一个电商平台的支付架构有非常多的部分组成，从使用视角看整个支付过程大致是这样的：

• 用户选好商品提交订单；
• 平台在订单中心完成订单的创建；
• 在交易中心完成账单的创建；
• 用户操作去支付；
• 交易请求支付获得收银台链接，反馈给订单；
• 订单再将收银台链接返回给用户端；
• 用户到了收银台页面选择了用招商信用卡支付，输入支付密码；
• 一瞬间支付就成功了。

这个过程可能就几秒钟。然而，这几秒钟整个支付经历了非常长的链条，经过非常多环节和复杂的处理，接下来我们就来分析如何还原这个过程，做出一个通用的交易平台应该具备的支付架构模型。

2. 架构的支付部分

我们看上面的架构图，对于一个服务平台的支付架构，其支付部分一般由如下部分系统组成：

• 直面用户的收银台；
• 记录业务的订单系统；
• 推动交易的交易系统；
• 对支付指令进行处理的支付系统；
• 付指令传送通道的支付通道子系统；

我们将上述系统按照数据的流转顺序连接到一起，可以得到交易和支付模块的架构部分，用户在购物车下单，通过订单系统创建订单以及交易系统生成交易账单，交易系统通知支付系统完成支付单的创建，最后由用户在收银台完成支付，如图5所示。

图5：支付过程的架构部分

3. 架构的清结算部分

支付成功后还有一条线需要考虑，就是清结算线，清结算部分主要是对本次交易中各方利益进行计算和分割，谁应该获得多少收益，简单地说就是算清楚应该给谁多少钱的过程。这个过程大概由以下几个环节组成：

• 交易系统将数据提交给清算中心进行数据的清分计算；
• 然后再由清算系统提交账务系统进行记账；
• 账务系统通知会计核心完成内部账的记录；
• 最后对商家进行结算付款。

将上述过程涉及到的系统按照顺序连接到一起，就可以得到清结算部分的架构图了，如图6所示：

图6：清结算过程的架构部分

4. 完整的架构

我们将上述的支付部分和清结算部分的架构合并到一起以后，就可以得到一个交易平台的典型支付架构了，如图7所示：

图7：交易平台的典型支付架构

这个业务架构模型适用于像美团、去哪儿、滴滴、京东等这样的交易平台，当然这些平台的实际情况要比这个架构复杂的多，但是其核心骨架高度抽象以后基本如此。如果你要从零到一做一套支付体系，就可以参考这个架构图进行规划，并依托于所在企业的业务特点和交易诉求，进行架构的丰富和调整。

一个交易平台如果要实现线上支付，都需要接入一些支付机构，通过接入的支付通道将支付请求提交给支付机构，那么支付提交给支付机构以后，这些机构内部又是怎么处理的呢？接下来我们就进入支付宏观的支付服务层——三方支付机构。

三、支付服务层

对于一个支付机构来说，他们的支付架构是什么样的呢？比如在图7中，支付请求提交到了支付机构，这笔请求在支付机构内部系统之间会怎么流转和处理呢？

支付机构作为拥有支付牌照，为交易平台提供支付解决方案的企业，也有着自己复杂而庞大的支付体系，其中常见的部分包括各类收银台、支付产品、支付路由、支付通道、支付核心、账务核心、清算核心、风控核心、商户入网等等。

支付机构以银行支付通道为业务基础，封装出适用于各类交易场景的支付产品，为商户提供支付能力，这是支付机构的产品主线，围绕该主线又会产生其他类系统的诉求，例如资金处理、对账、计费等。如图8所示，就是典型的支付机构的支付架构图。

图8：典型三方支付机构支付架构

• 接入层：是三方支付机构直接面向客户的入口，包括个人客户、商户、渠道商等，为个人客户提供消费支付产品，为商户提供支付能力服务，为渠道商提供分销合伙的平台。
• 业务层：是支付机构所打造出来的适用于各类支付场景的支付产品，例如航旅支付解决方案、生活缴费支付解决方案、银行卡支付、资金合规、分账类产品、商户结算类产品等。
• 交易层：是对各类业务交易请求的处理层，处理上游各业务线下发的支付订单，例如收款类交易、付款类交易、鉴权类交易等。
• 支付处理层：提供收银台和支付核心，还将构建各类支付的核心处理流程，例如快捷支付、网关支付、分账支付等。
• 风控层：对支付安全负责，包括客户信用安全、交易安全、支付安全、数据安全等等。
• 通道层：是集中管理接入的各类支付通道，以及为支付层筛选最佳通道的路由系统。
• 渠道层：是底层对接的提供各类支付通道的服务商，其中包括一些消金类机构、银行、清算机构等。

上面的架构图基本涵盖了一家支付机构应该具备的全部支付能力。对比发现，其实支付机构的支付架构跟3.2小节中的交易平台支付架在某些角度看大同小异；只不过是服务的对象一个是用户另一个是商户，支付通道一个是三方机构提供，一个是银行提供。下面我们对支付机构的支付架构进行拆解分析。

1. 支付接收部分

支付请求到了三方支付机构后，第一个门槛就是到达支付机构的网关层，通过一系列的风控校验通过后，来到开放平台。开放平台将支付请求提交给交易处理层进行处理，首先到达订单处理中心，创建订单后请求支付系统获得收银台链接，返回给开放平台；上述过程如图9所示，这就是支付机构支付接收部分的架构：

图9：接收支付请求架构部分

2. 支付处理部分

支付处理中心对支付请求进行处理，通过路由选择合适的支付渠道，然后由封装支付指令，将清算指令通过支付通道提交给清算机构或者银行，该部分如图10所示：

图10：提交支付请求的处理架构部分

3 清结算部分

清算机构返回清算成功后，支付处理中心通知订单中心支付成功，订单中心将订单提交给清算中心进行清结算处理，完成计费、清分、记账等操作，如图11所示：

图11：清结算架构部分

将接收部分、支付处理部分和清结算部分的架构合并到一起以后，就可以得到一个支付机构典型支付架构了，如图12所示：

图12：支付机构典型的支付架构

断直联以前，支付机构直接接入银行通道，将支付请求提交给接入的银行；断直连以后，支付机构接入清算机构提供的支付服务，支付时将支付指令提交给清算机构。那么，支付指令到了清算机构之后会怎么样的呢，清算机构都包含哪些支付处理业务呢？

四、清算服务层

支付机构的支付处理和信息转接离不开清算机构，同样银行与银行之间的跨行清算也不离不开清算机构，清算机构在整个支付业态下具有非常重要的枢纽作用。

清算机构是随着金融市场的快速发展、信息技术的不断进步和支付服务的分工细化，而逐渐兴起的专业化从事支付清算服务的组织。它们是依据相关法律法规设立的，取得《支付清算业务经营许可证》，并向参与者提供支付清算服务的组织。

清算组织的主要职能是建立和维护支付信息交换网络，向会员机构提供信息交换、清算和结算等服务，例如为办理票据和结算凭证等纸质支付指令提供交换和计算服务，为银行卡支付业务的支付指令和电子支付指令提供交换和计算服务。其中：

• 支付清算是指支付指令的交换和计算；
• 支付指令是指参与者以纸质、磁介质或电子形式发出的资金转账命令;
• 指令的交换是指提供专用的支付指令传输路径，用于支付指令的接收、清分和发送；
• 指令的计算是指对支付指令进行汇总和轧差；
• 参与者是指接受支付清算组织章程制约，可以发送、接收支付指令的机构。

1. 常见清算组织

常见的支付清算组织和从事的主要清算业务如下：

中国银联股份有限公司，主要运营全国的银行卡跨行信息交换网络系统、提供银行卡跨行信息交换的支付服务，另外也同网联一起为网络支付提供收付清算服务。

网联清算有限公司，（NetsUnion Clearing Corporation，简称NUCC）是经中国人民银行批准成立的非银行支付机构网络支付清算平台的运营机构，于2017年8月在京注册成立，主要处理非银行支付机构发起的涉及银行账户的网络支付业务，提供公共、安全、高效、经济的交易信息转接和资金清算服务。

城市商业银行资金清算中心，成立于2002年10月，是有多家城市商业银行发起成立的会员制组织，主要经营城市商业银行等中小金融机构的银行汇票资金清算等业务。

农信银资金清算中心，是有30家省级农村金融机构共同发起成立的全国性股份制非金融企业，向全国农村信用社、农村商业银行、农村合作银行及其他地方性金融机构，办理实时电子汇兑业务、银行汇票业务的异地资金清算和个人存款账户通存通兑业务的资金清算等业务。

另外，还有其他支付清算组织，例如为全国银行间债券市场提供等级、托管、交易结算的中央债券登记结算公司，为证券市场提供证券交易清算和算服务的中国证券登记结算公司。

清算组织机构与各银行业金融机构和其他非金融机构服务组织为社会提供多样化的支付清算及结算服务，像常见的银行卡跨行清算、收单清算、网络支付清算、汇票清算等，如图13所示我国支付清算体系全貌：

图13：我国支付清算体系全貌

2. 银联清算业务

银联是我国最大的也是唯一的卡组织，是我国银行卡产业的核心和枢纽地位，通过银联跨行交易清算系统实现银行卡的跨银行、跨地区使用。银联的支付清算包括跨行清算和收单清算。跨行清算是针对收单机构和发卡机构的清算；收单清算是代替收单机构针对商户和收单专业化服务机构的清算，在整个清算业务中，各参与者之间形成了如图14所示的利益分配关系。

图14：银联清算参与者的利益关系

• 用户花了p购买了商品或者服务，
• 发卡行从用户卡账户中扣除p，
• 发卡行将扣掉交换费a以后的剩余部分p-a支付给收单行，
• 收单行向商户收取m的费用后将剩余的p-m结算给商户；
• 发卡行和收单行都向银联支付转接服务费。

3. 网联清算业务

断直连以后支付机构开展互联网支付业务，需要接入网联或者银联，由网联和银联进行支付指令的清算和转发，支付机构的备付金也将全额缴存至央行集中存管，而支付业务也不再直接提交给银行。

支付机构的指令到了网联以后，网联进行实时清算，实时的对支付指令进行轧差变更可用余额，简单的说就是支付机构将人行备付金的余额映射分配给网联和银联形成映射虚拟额度，用于交易周期内的实时清算；然后网联定期将一定周期内的清算结果提交人行进行资金的结算，断直连后各支付参与方之间的关系如图15所示。

图15：网联清算模式下的各机构连接关系

其中，备付金热点账户前置系统（RCMP）为了解决备付金集中存管所形成的热点账户问题，管理已映射额度，并用于支付机构通过网联平台（EPCC）的业务处理。前置系统分为额度管理模块和账户管理模块，并为各支付机构建立账户，进行可用额度的监控和已映射额度的管理。

与断直连之前直接接入银行通道存在一定的差异，特别是在付款业务上，下面分别介绍网联向支付机构提供的相关业务以及网联的支付清算模式。

1）网联支持的业务

网联提供的可接入业务包括信息类和支付类两大类，具体业务功能和适用场景如表1所示。

表1：网联支付业务种类

2）支付清算模式

网联和银联采用“实时清算、定时结算”的模式受理来自支付机构的收付业务，通过支付机构备付金集中存管账户完成资金结算。收付时，通过实时增减网联前置系统的可用账户余额完成清算，在固定时间点提交央行完成最终的结算。以入金业务为例，整个支付业务流程如图16所示。

图16：网联入金业务流程

在上述的入金业务清算过程中支付机构备付金集中存管账户的余额并不会发生变化。在清算场次内虽然支付机构发生了收付业务，但是网联的清算处理仅在前置系统内通过实时增减可用余额完成，并不会改变支付机构备付金账户的余额。提交结算以后备付金账户余额才会根据清算净额发生变化。

这里有一个明显的好处，那就是付款效率的提高，断直连之前支付机构通过在各银行开通的收付户进行对外付款，但需要账户中有足够的资金，当日的收款在银行没有结算至备付金账户之前是无法用于付款的，而现在的实时清算模式下，出金业务并不依赖实际的账户资金到账，而是可以基于可用余额进行，入金业务会增加可用余额，可以直接用于付款，极大的提高了资金的使用效率。

3）业务案例：协议支付

协议支付即原来的快捷支付，是银行与特定商户共同为客户提供的电子支付方式。协议支付需要先通过三方签署协议进行签约，将客户在银行开立的银行账户与客户在特定商户的用户ID进行绑定，并生成协议号，银行在收到商户发送的以协议号标识的交易指令后完成支付交易，从而实现客户在商户网站完成直接付款业务或者查询业务。

签约过程包含身份认证和签约2个过程，如图17所示：

图17：签约认证流程

• 签约时用户通过支付机构提供签约信息；
• 由支付机构向网联发起认证申请；
• 网联向签约行转发身份认证申请；
• 由签约行完成用户身份认证处理
• 向用户发送身份验证授权信息；
• 用户提交身份验证授权信息后由支付机构向网联平台发起签约申请；
• 网联受理并向签约行转发签约申请；
• 由签约行完成签约处理。

支付流程是这样的，用户通过支付机构提交协议支付，由支付机构通过此报文向网联发起协议支付申请，网联受理并向付款行转发协议支付申请，由付款行完成协议支付付款处理

若付款行处理成功，网联异步向收款行发起协议支付申请，收款行完成支付协议收款处理，该过程如图16所示。

五、金融服务层

支付业务当然也离不开银行，无论是我们日常使用的银行卡还是支票，或者在各平台绑定的快捷支付，都是以银行为基础。

1. 银行业务

银行是金融机构，向个人及企事业单位提供基础的金融服务。相对于服务平台、三方支付机构以及网联这样的清算机构有很大不同，银行除了提供互联网支付通道以外，还有线下实体门店、ATM、银行卡、存款业务、贷款业务、理财业务等等金融业务，如图18所示：

图18：银行业务一览

银行的客户除了面向个人和企事业单位以外还包括其他机构，银行的核心业务包括存款、贷款、以及理财类业务，同时也具备强大的资金管理能力、信贷风险管理、利率风险管理等。银行是结算账户等各类金融账户的主要提供机构，围绕银行账户看银行的主线业务会更加接近我们日常对银行的了解，更容易理解银行的业务，如图19所示。

图19：银行账户与银行业务之间的关系

2. 银行内部系统架构

从银行系统架构看银行体系，其中包含交易、账户，支付核心，通道，前置系统、客户管理等一系列的信息化系统，典型的银行系统架构如图20所示：

图20：银行业务系统架构

六、支付基础层

几乎所有的支付业务最终都会到达人民银行，人民银行为支付业务提供最基础的政策法规以及支付清算系统。其中二代支付系统最核心的系统包括清算账户系统、大额支付系统、小额支付系统、网上支付跨行清算系统、支付管理信息系统、支票影像交换系统等，他们之间有如图21所示的关系：

图21：二代支付系统

以清算账户管理系统为核心，大额支付系统、小额支付系统、支票影像交换系统、网银互联子系统为业务应用子系统，公共管理控制系统和支付管理信息系统为支持系统，共同构成了二代支付体系。

1. 主要系统介绍

清算账户管理系统(SAPS)是支付系统的核心系统，通过集中存储和管理清算账户，完成支付系统各类业务的资金清算，并为中央银行办理现金存取、再贷款、再贴现等业务提供清算服务；各银行、支付机构、网联、银联都会在这里开通清算账户，进行资金的清算，例如银联卡跨行交易时通过即时转账业务办理的资金清算的账务处理过程如图22所示：

图22：银联卡跨行交易的资金清算

大额支付系统，小额支付系统，网上支付跨行清算系统接受参与者的清算支付指令，进行指令的处理并提交给清算账户管理系统完成资金划拨。在网上银行端发起跨行的付款请求，假设金额较小走了小额支付系统，业务流程如图23所示：

图23：跨行小额支付流程

支付信息管理系统是中国现代化支付系统的辅助支持系统，由行名行号管理子系统、参数管理子系统、计费管理子系统、支付业务统计分析子系统、支付业务监控子系统等六个子系统组成，是一个多功能模块的、集中式的支付信息共享平台，其结构如图24所示：

图24：支付信息管理系统

2. 系统的运行控制

以上这些系统之间是有序运行，依靠公共控制实现全流程的有序安排如图25所示：

图25：支付系统运行控制

整个控制从SAPS开始营业到中间的场次控制，大小额系统的日切控制，清算窗口安排，排队与排队解救，到最后的日终处理，控制着整个支付体系的有序运转。

3. 支付清算处理

网联将结算请求提交给人行支付系统之后，支付系统对指令进行处理之后提交清算账户系统完成最终的资金结算；这个时候开始买书的那笔钱才真正从招商的清算账户进入到网银在线的备付金账户中，如图26所示：

图3-26：最终支付清算处理

七、支付的全局架构图

通过分析和拆解，整个支付体系的每一层参与者的架构和核心业务都做了一个宏观的认识，一笔支付要经历如此漫长的处理链条，才能最终完成。将所有的参与者架构融合到一起，就构成了整个互联网支付的总支付架构如图27所示：

图27：支付宏观架构

​Read More