四张图搞懂支付架构

刚哥 2023-12-01 15:41:45

你是否因为工作中需要画支付架构图，为怎么清晰的表达而烦恼呢？你是否对五花八门的支付架构图看的云里雾里？今天我给大家介绍一套简单又清晰的支付架构，让你快速掌握一套支付体系是怎么运转的。【老规矩，只看精华的同学直接翻到最后第四章看总结】

01 支付系统介绍

1.1 什么是支付系统

能够实现货币交换的软件系统都可以被称为支付系统，而我们这里介绍的是伴随着电商业务而兴起第三方支付机构所使用的“收单支付系统”。它和传统的“信汇、电汇、银企直联、商业汇票”等支付结算系统最大的区别就是“买卖交易和资金转移都可以在线上完成”。

这种交易方式极大地提升了商品销售的效率。他也是电商业务和平台经济能兴起核心基础设施，因为顺畅的收钱是任何商业模式成功的前提。

白话支付架构

图1：支付系统是电商经济的核心基础设施

1.2 支付系统分层

支付系统的定位就是根据客户商业订单完成跨行的收付款，将资金最终转移到收款人的账户里。因此整套系统按照“一个系统、两个通道、三层架构”来进行划分。

白话支付架构

图2：支付系统架构分层

1.2.1 一个系统

为了实现买卖双方的跨行收付款，支付平台会把支付产品包装成接口或支付页面提供给客户来使用，并通过系统的层层转换来实现资金的跨行转移到收款人账户里。因此，一个最简单的支付系统由如下八个模块组成。

白话支付架构

图3：支付中台主要模块

1.2.2 两个通道

1）网关/终端（接入端）

它是支付系统的“接入端”，将支付产品通过接口、页面、终端设备的形式提供给用户进行支付、开户和认证。同时访问网关或者使用终端设备还要安装“密钥和证书”，以此来保证你支付的安全。

2）渠道（接出端）

它是支付系统的“接出端”，他负责对接三方、银行、清算机构的支付接口，把他转换成标准支付产品提供给上层的产品使用。如果选择对接了多家银行相同的支付产品，他能根据“订单、渠道、稳定性”进行动态的路由选择。

1.2.3 三层架构

1）产品层（深度支付包装）

产品层是为了适应不同场景的支付需求，把基础支付产品包装面成向不同场景的销售产品，满足各行业各对于支付的特殊需求。例如面向个人用户的B2C、C2C支付，面向企业的B2B支付，以及面向金融机构的消金支付等。因此产品层是对交易层的深度包装，让他更加适应不同的场景的需求，方便用户使用。

2）交易层（基础支付包装）

为使用者提供基础的支付产品，包括充值、提现、收款、分账、付款等支付服务，满足多场景对支付的基本需求。他主要包括了收银台、交易系统、客户系统三部分。

收银台：通过页面形式让用户顺畅的完成支付操作，无需关注支付的技术实现。
交易系统：交易层的“流程调度者”，它对业务场景提供方便的接口或页面操作，让使用者无需关注底层的复杂的处理逻辑，专注业务场景的支付需求的实现。
客户系统：为用户提供所需要APP或网站，让用户可以对自己的交易、账户、资金进行管理。

3）核心层（原始支付服务）

“核心层”又叫“支付层”，是为交易层提供原始的账务、渠道、清结算服务，他专注于内部账务逻辑和支付渠道的处理逻辑，并且核心层也代表了一个系统的核心能力，他决定了上层产品是否好用、好卖、好管（人们常说产品看着挺好，用着很差，一般是核心能力不足造成的）。

支付引擎：核心层的“流程调度者”，为交易系统提供账务处理、渠道调用、对账明细等处理。让交易系统无需关注底层逻辑的使用，支付引擎全权负责了后端和事后的管理。
账户系统：持牌机构由于要做清结算，因此会把会计账务和资金账户放在一起进行账务登记。他在支付引擎的驱动下，完成记账、核算等账务操作。
清结算：负责与渠道的对账和客户资金结算的处理，也是对资金管理的核心模块。

02 支付业务架构

白话支付架构

图4：支付业务架构

业务架：构顾名思义就是面向业务场景提供的架构图，他主要目的就是让非技术人员了解系统具有哪些能力，以及系统提供产品和管理能力是否符合期望。业务架构一般分为两张图“架构图、流程图”，架构图负责展示系统的功能结构，流程图负责展示功能之间关系。

从支付的业务架构我们可以看到，相对于分层的架构图，实际的业务架构有许多的辅助系统来支持支付业务的运行。不过支付业务核心闭环的还是支付服务中的8个模块当主角，下面我们来分别介绍下。

2.1 收银系统

收银台系统就是以页面的形式提供给用户进行收款操作，同时它也会面向不同的支付终端提供各种类型的收银台，我们按终端类型把它们分为五类。

1）H5收银台：这种是适配移动终端类型最多的收银台，由于它能够实现快捷、公众号、H5、钱包、数币等多种支付方式的聚合，因此也叫聚合收银台。支付方式能够根据参数进行展示和折叠，页面样式也支持自定义。

2）SDK收银台：这种是针对APP场景提供收银台，支持的支付方式与H5相同，不过体验能够做的更好，还能支持生物识别。当然这种支付方式需要和客户的APP进行集成，使用起来比较复杂。

3）小程序收银台：这种主要是适配小程序场景，例如微信、支付宝、数币等，但是由于小程序依赖于APP的运行环境，因此各种小程序支付方式要独立分开。

4）WEB收银台：这种主要适配PC场景，分为个人网银和企业网银两类，并且支付的额度比较高，相对安全性也有所提高，需要通过证书、UKey等方式进行支付。由于现在普遍使用移动端进行支付因此网银支付的用在企业场景会比较多。

5）聚合收款码：这类分为两种，一种是码牌他是基于收款账户包装成一个收款二维码，然后根据用户扫码的APP类型来适配调用微信还是支付宝的收银台，这种支付方式需要用户自己手动输入金额。另一种是商品码，这种就是根据用户购买的商品订单的金额生成一个聚合码，根据用户APP类型来适配不同的渠道支付产品。这种支付方式用户不需要输入金额直接可以进行支付。收银台的形式有很多种了，主要还是看产品经理对于渠道支付产品特性的了解来包装出多种多样的形式。

2.2 交易系统

通过前面的介绍我们知道，交易系统是面向支付场景和用户提供的服务，因此他主要职责是处理业务场景复杂多变的支付处理需求。交易系统在交易层扮演以下角色：

白话支付架构

图5：交易系统核心能力

1）产品的提供者交易系统负责给外部使用收银台，收款、付款、余额支付等交易方式，并且根据不同的场景提供担保交易、合单支付、组合支付等分账交易把资金分给交易的参与方。因此我们使用的支付产品其实都是交易系统提供的服务。

2）流程的调度者交易系统是处理客户请求的流程调度者，他根据客户提交的支付订单进按照流程的先后顺序调用收银台、客户系统、支付引擎来完成支付处理。

2.3 客户系统

顾名思义是为客户提供服务的，因此他对内对外提供的功能会比较多，他主要会是面向客户各种使用和登录的入口来提供服务的。

1）服务端：服务端就是通过接口或者页面向客户提供服务，因此他是一种开放能力。可以通过客户或者服务商以接口对接的形式，将客户服务嵌入到外部平台的App、网站、小程序中，让外部平台具可以使用持牌机构的账户能力进行交易。

2）会员端（钱包）会员端是面向支付产品使用者（一般是消费者，买方）提供的支付服务，通过开通会员钱包账户存放自己的资金，并且也能通过钱包账户进行充值、提现和转账。

3）商户端：商户端是面向商家的服务端，由收单机构提供商户APP或者商户网站给商家提供，交易管理、账单和回单、账户和资金管理等服务。

2.4 产品中心

产品中心是包装对外销售产品的一个配置中心，并且商户相关的签约产品、计费信息、交易限额等都可以通过的灵活的模版来进行配置。它的作用如下：

1）提高配置效率通过模板化的配置工具来提高商户产品的配置效率，让商户快速的使用产品。

2）快速组装新产品其实一个新的支付产品，需要重新开发的新特性不会太多，其中大部分都是基础支付产品的复用。所以通过组件化的配置工具，通过少量的新特性开发就能快速搭建一个新的销售产品出来。这样一方面减少了产品的重复开发，另一方面成熟的功能多，新产品也比较稳定。

2.5 支付引擎

支付引擎顾名思义是支付的发动机，他负责所有系统与账户、渠道的支付流程处理。

白话支付架构

图6：支付引擎核心能力

1）支付提供者它对交易层的“交易系统”、“客户系统”、“收银台”等屏蔽了底层支付账务、支付渠道管理的复杂性，让交易层可以专注于业务场景，即使底层渠道更换，账务进行调整，交易层也不会受到影响。

2）流程调度者有了支付引擎这个大当家，流程处理相关的“脏活累活”都由他来负责。账户、渠道、清结算就可以各司其职做好本职工作，如果涉及其他系统协作，通知“支付引擎”去干就可以了。

2.7 账户系统

账户系统又叫账务系统，账户系统。他一般系统包含了账务和账户两部分，其中账务部分负责为支付引擎提供记账服务、记录资金变动情况，账户部分用来对账户进行管理，记录并呈现账户的余额情况。

1）账务管理

记账服务：该服务面向支付引擎提供记账、余额更新、查询和账户控制等服务。并将自身的账务流水提供给清结算系统进行核对。
会计服务：按照会计规范设置科目和分录，为记账服务提供反应账户间资金变动的会计数据。
核算服务：按照会计准则核对当天的资金账务和库存现金情况，确保账务准确和真实。

2）账户管理

是对资金账户的管理，他分为“客户账户”和“内部账户”两部分，客户账户是存放客户自有资金的账户，他是提供给客户使用的。内部账户是用来给持牌机构内部登记资金账务的账户，也叫内部户、过渡户等。

2.8 清结算系统

又称为对账系统，结算系统，他负责与支付渠道进行账务核对，差错处理、手续费的清分和客户资金的结算。同时对于资金归集、划拨等无法在实时交易中完成的结算操作，也是由清结算系统负责处理的。

03 支付架构流程

支付系统对于交易处理性能和资金结算效率要求都比较高，因此它采用的是流水线作业方式，在支付架构的流程上表现出来的是两条主干交易链路，实时交易链路和日终结算链路。

3.1 流水线作业

整个支付系统就像一个工厂车间一样，他通过实时和日终两条流水线分别处理实时交易和日终资金结算，这样的处理方式很好平衡了交易指令和资金到账时间不平衡的问题。

白话支付架构

图7：支付流水线作业

1）实时流水线实时流水线，通过“网关”到“渠道”的交易流水线，处理源源不断从网关发过来的支付请求，最终发往支付渠道完成客户的跨行收付款处理。

2）日终流水线日终流水线又叫清结算流程，它针对日间的实时交易，进行对账和清结算等处理，只有日终处理完了，一天的交易才算完毕。

3.2 支付架构流程

白话支付架构

图8：支付系统流程图

3.2.1 两条主链路

1）实时交易链路

实时交易链路从“网关”到“渠道”形成一条支付请求的处理流水线，客户、收银台、账户和清结算各节点按部就班的处理流水线传递过来的信息，完成客户信息校验，资金账号获取，收银台展示，账务登记，渠道路由和跨行收付款操作。

2）日终结算链路

以清结算系统为起点，通过自动任务获取渠道和交易层的数据进行对账与差错核对，然后通过支付核心与账户系统交互完成渠道清算、商户结算、内部核算操作，最终为客户生成对账单后完成一天的业务处理。

3.2.2 实时双驱动

为了既能处理业务的复杂场景，又能处理渠道和账务的复杂支付逻辑，系统采用了“双发驱动”的模式，脏活累活全都给“交易”和“支付”去处理，两者配合让整条流水线上的各个模块有效的协作起来。

1）交易系统（交易发动机）

是交易层的交易流程调度者，他负责业务场景中的各种复杂交易场景的流程处理。

2）支付系统（支付发动机）

是核心层的支付流程调度者，他负责支付账务、渠道调用的流程处理。

3.2.3 日终做日清

负责日终后的对账和结算处理的流程，驱动支付系统完成渠道清算，商户结算，最终为商户生成结算账单和回单，完成整个支付业务的闭环。

3.2.4 其他保持独立

其他的“客户”、“账户”、“收银台”、“渠道”四个模块接受这两个流程的驱动去各自完成自己的事情就可以了。这样就这样可以保持交易链路清晰，避免多模块之间调用不清造成混乱。

下面我们通过几个典型业务，对支付系统模块间的协作关系进行详细的介绍：

3.3 收单流程

收单业务是第三方支付的核心业务，他场景化比较丰富，因此系统流程也会相对复杂些。我们针对“API收款”、“收银台收款”和“小程序收款”几种典型场景进行介绍。

3.3.1 快捷支付（API直接支付）

白话支付架构

图9：快捷支付收款流程

快捷支付：又叫“协议支付、签约扣款等”（俗称为代扣，因为比较容易和早期的裸代扣混淆，因此这么说的人并不多）。快捷产品的特点就是，持卡人需要先四要素签约绑卡（姓名、手机号、身份证、银行卡）进行四方签约（持卡人、收单机构、清算组织、发卡银行）

上图是一个快捷API扣款的流程，他的主要特点如下：

1）首笔短验，后续可免首次签约需要输入短信验证码来确认用户授权，后续扣款短验和直接扣款都支持。因此首笔签约时通过“客户系统”向“渠道”发送请求，通知“发卡银行”向客户手机发送短信验证码。

2）先渠道扣款，再账户记账为了保证资金的安全收款交易普遍采用，第三方扣款成功后，再给客户账户或者商户账户记账。这样可以确保渠道未支付成功的时候，资金不被客户挪用。因此，“支付系统”先通过“渠道”进行跨行扣款，如果返回结果为成功就去“账户系统”完成记账处理。

3）流程顺畅，渠道可路由整个过程从签约、短验、支付，按照产品、交易、支付、渠道的按照线性化的流程处理，因此支付过程虽然较多，但是比较顺畅。同时，由于渠道完全按照收单机构的指令执行，因此在用户主动支付的场景下（用户每次都可会输入验证码）渠道是可以路由的。

3.3.2 收银台支付（本地收银台支付）

收银台支付包含H5支付、SDK支付（集成在APP内），由于他可以包装比较多的支付方式在收银台上，因此又叫“聚合收银台”。我们这里介绍的场景是用户在收银台上选择在收单机构绑定的银行卡，这种场景收单基本通过快捷支付就能完成扣款，无需跳转到第三方。

白话支付架构

图10：本地收银台支付流程

该流程的特点如下：

1）跳转收银台完成支付用户（付款人）下单后，收单机构给客户返回收银台地址，客户跳转到收银台上完成支付。因此交易系统负责按照用户下单和使用的支付产品生成收银台地址，返回给用户完成下单后的支付操作。

2）在客户系统获取“绑卡协议号”如果用户选择银行卡付款，需要去“客户系统”检查绑卡信息，并获“绑卡协议号”（短信签约时渠道返回的协议号）然后通过渠道扣款。

3）通过协议号完成扣款交易系统拿到协议号之后，通过支付引擎、支付渠道将协议号传给开户行，开户行完成扣款后原路返回，将结果通知给客户。需要说明的是，这里的协议号按照“用户、收单机构、清算机构、开户银行”四者关系生成，任何一方出现变化都需要重新签约。

3.3.3 小程序支付（渠道收银台支付）

以小程序支付为代表的，APP支付、微信H5支付、公众号支付、扫码支付等，都需要跳转到渠道方收银台上输入密码并完成支付。这种支付方式对客户来说比较安全，但是也比较封闭，因此在交互体验上也复杂了不少。

白话支付架构

图11：渠道收银台支付流程

该流程的主要特点如下：

1）下单获取参数首先通过用户下单向渠道方（微信、支付宝）获得收银台的参数，以便后续跳转准备。

2）跳转收银台根据下单获得参数返回给商户端后跳转到渠道方的收银台，用户在渠道方的收银台上完成支付。此时商家对于用户的操作情况是一无所知的，只能等待渠道方的通知。

3）回调返回结果当用户完成支付后，渠道方会主动发起一个回调通知给收单机构，收单机构把结果给商户端。如果长时间没有返回。有两种处理方式来同步最终结果，一种是主动发起查询支付结果，另一种是做个倒计时超时直接发起撤销或者退款（类似12306购票）从这里我们就可以看到以“交易”和“支付”为流程调度者的优势就出来了，他们可以任意的定制支付流程，从而满足复杂场景对于支付的处理要求。