面对五花八门的支付架构图，是否看得云里雾里？本文为大家总结了一套清晰的支付架构图，让你快速掌握一套支付体系是怎么运转的，一起来看看吧。
你是否因为工作中需要画支付架构图，为怎么清晰的表达而烦恼呢？你是否对五花八门的支付架构图看的云里雾里？今天我给大家介绍一套简单又清晰的支付架构，让你快速掌握一套支付体系是怎么运转的。【老规矩，只看精华的同学直接翻到最后第四章看总结】
能够实现货币交换的软件系统都可以被称为支付系统，而我们这里介绍的是伴随着电商业务而兴起第三方支付机构所使用的“收单支付系统”。它和传统的“信汇、电汇、银企直联、商业汇票”等支付结算系统最大的区别就是“买卖交易和资金转移都可以在线上完成”。
这种交易方式极大地提升了商品销售的效率。他也是电商业务和平台经济能兴起核心基础设施，因为顺畅的收钱是任何商业模式成功的前提。
图1：支付系统是电商经济的核心基础设施
支付系统的定位就是根据客户商业订单完成跨行的收付款，将资金最终转移到收款人的账户里。因此整套系统按照“一个系统、两个通道、三层架构”来进行划分。
图2：支付系统架构分层
1.2.1 一个系统
为了实现买卖双方的跨行收付款，支付平台会把支付产品包装成接口或支付页面提供给客户来使用，并通过系统的层层转换来实现资金的跨行转移到收款人账户里。因此，一个最简单的支付系统由如下八个模块组成。
图3：支付中台主要模块
1.2.2 两个通道
1）网关/终端（接入端）
它是支付系统的“接入端”，将支付产品通过接口、页面、终端设备的形式提供给用户进行支付、开户和认证。同时访问网关或者使用终端设备还要安装“密钥和证书”，以此来保证你支付的安全。
2）渠道（接出端）
它是支付系统的“接出端”，他负责对接三方、银行、清算机构的支付接口，把他转换成标准支付产品提供给上层的产品使用。如果选择对接了多家银行相同的支付产品，他能根据“订单、渠道、稳定性”进行动态的路由选择。
1.2.3 三层架构
1）产品层（深度支付包装）
产品层是为了适应不同场景的支付需求，把基础支付产品包装面成向不同场景的销售产品，满足各行业各对于支付的特殊需求。例如面向个人用户的B2C、C2C支付，面向企业的B2B支付，以及面向金融机构的消金支付等。因此产品层是对交易层的深度包装，让他更加适应不同的场景的需求，方便用户使用。
2）交易层（基础支付包装）
为使用者提供基础的支付产品，包括充值、提现、收款、分账、付款等支付服务，满足多场景对支付的基本需求。他主要包括了收银台、交易系统、客户系统三部分。
3）核心层（原始支付服务）
“核心层”又叫“支付层”，是为交易层提供原始的账务、渠道、清结算服务，他专注于内部账务逻辑和支付渠道的处理逻辑，并且核心层也代表了一个系统的核心能力，他决定了上层产品是否好用、好卖、好管（人们常说产品看着挺好，用着很差，一般是核心能力不足造成的）。
图4：支付业务架构
业务架：构顾名思义就是面向业务场景提供的架构图，他主要目的就是让非技术人员了解系统具有哪些能力，以及系统提供产品和管理能力是否符合期望。业务架构一般分为两张图“架构图、流程图”，架构图负责展示系统的功能结构，流程图负责展示功能之间关系。
从支付的业务架构我们可以看到，相对于分层的架构图，实际的业务架构有许多的辅助系统来支持支付业务的运行。不过支付业务核心闭环的还是支付服务中的8个模块当主角，下面我们来分别介绍下。
收银台系统就是以页面的形式提供给用户进行收款操作，同时它也会面向不同的支付终端提供各种类型的收银台，我们按终端类型把它们分为五类。
1）H5收银台：这种是适配移动终端类型最多的收银台，由于它能够实现快捷、公众号、H5、钱包、数币等多种支付方式的聚合，因此也叫聚合收银台。支付方式能够根据参数进行展示和折叠，页面样式也支持自定义。
2）SDK收银台：这种是针对APP场景提供收银台，支持的支付方式与H5相同，不过体验能够做的更好，还能支持生物识别。当然这种支付方式需要和客户的APP进行集成，使用起来比较复杂。
3）小程序收银台：这种主要是适配小程序场景，例如微信、支付宝、数币等，但是由于小程序依赖于APP的运行环境，因此各种小程序支付方式要独立分开。
4）WEB收银台：这种主要适配PC场景，分为个人网银和企业网银两类，并且支付的额度比较高，相对安全性也有所提高，需要通过证书、UKey等方式进行支付。由于现在普遍使用移动端进行支付因此网银支付的用在企业场景会比较多。
5）聚合收款码：这类分为两种，一种是码牌他是基于收款账户包装成一个收款二维码，然后根据用户扫码的APP类型来适配调用微信还是支付宝的收银台，这种支付方式需要用户自己手动输入金额。另一种是商品码，这种就是根据用户购买的商品订单的金额生成一个聚合码，根据用户APP类型来适配不同的渠道支付产品。这种支付方式用户不需要输入金额直接可以进行支付。收银台的形式有很多种了，主要还是看产品经理对于渠道支付产品特性的了解来包装出多种多样的形式。
通过前面的介绍我们知道，交易系统是面向支付场景和用户提供的服务，因此他主要职责是处理业务场景复杂多变的支付处理需求。交易系统在交易层扮演以下角色：
图5：交易系统核心能力
1）产品的提供者交易系统负责给外部使用收银台，收款、付款、余额支付等交易方式，并且根据不同的场景提供担保交易、合单支付、组合支付等分账交易把资金分给交易的参与方。因此我们使用的支付产品其实都是交易系统提供的服务。
2）流程的调度者交易系统是处理客户请求的流程调度者，他根据客户提交的支付订单进按照流程的先后顺序调用收银台、客户系统、支付引擎来完成支付处理。
顾名思义是为客户提供服务的，因此他对内对外提供的功能会比较多，他主要会是面向客户各种使用和登录的入口来提供服务的。
1）服务端：服务端就是通过接口或者页面向客户提供服务，因此他是一种开放能力。可以通过客户或者服务商以接口对接的形式，将客户服务嵌入到外部平台的App、网站、小程序中，让外部平台具可以使用持牌机构的账户能力进行交易。
2）会员端（钱包）会员端是面向支付产品使用者（一般是消费者，买方）提供的支付服务，通过开通会员钱包账户存放自己的资金，并且也能通过钱包账户进行充值、提现和转账。
3）商户端：商户端是面向商家的服务端，由收单机构提供商户APP或者商户网站给商家提供，交易管理、账单和回单、账户和资金管理等服务。
产品中心是包装对外销售产品的一个配置中心，并且商户相关的签约产品、计费信息、交易限额等都可以通过的灵活的模版来进行配置。它的作用如下：
1）提高配置效率通过模板化的配置工具来提高商户产品的配置效率，让商户快速的使用产品。
2）快速组装新产品其实一个新的支付产品，需要重新开发的新特性不会太多，其中大部分都是基础支付产品的复用。所以通过组件化的配置工具，通过少量的新特性开发就能快速搭建一个新的销售产品出来。这样一方面减少了产品的重复开发，另一方面成熟的功能多，新产品也比较稳定。
支付引擎顾名思义是支付的发动机，他负责所有系统与账户、渠道的支付流程处理。
图6：支付引擎核心能力
1）支付提供者它对交易层的“交易系统”、“客户系统”、“收银台”等屏蔽了底层支付账务、支付渠道管理的复杂性，让交易层可以专注于业务场景，即使底层渠道更换，账务进行调整，交易层也不会受到影响。
2）流程调度者有了支付引擎这个大当家，流程处理相关的“脏活累活”都由他来负责。账户、渠道、清结算就可以各司其职做好本职工作，如果涉及其他系统协作，通知“支付引擎”去干就可以了。
账户系统又叫账务系统，账户系统。他一般系统包含了账务和账户两部分，其中账务部分负责为支付引擎提供记账服务、记录资金变动情况，账户部分用来对账户进行管理，记录并呈现账户的余额情况。
1）账务管理
2）账户管理
是对资金账户的管理，他分为“客户账户”和“内部账户”两部分，客户账户是存放客户自有资金的账户，他是提供给客户使用的。内部账户是用来给持牌机构内部登记资金账务的账户，也叫内部户、过渡户等。
又称为对账系统，结算系统，他负责与支付渠道进行账务核对，差错处理、手续费的清分和客户资金的结算。同时对于资金归集、划拨等无法在实时交易中完成的结算操作，也是由清结算系统负责处理的。
支付系统对于交易处理性能和资金结算效率要求都比较高，因此它采用的是流水线作业方式，在支付架构的流程上表现出来的是两条主干交易链路，实时交易链路和日终结算链路。
整个支付系统就像一个工厂车间一样，他通过实时和日终两条流水线分别处理实时交易和日终资金结算，这样的处理方式很好平衡了交易指令和资金到账时间不平衡的问题。
图7：支付流水线作业
1）实时流水线实时流水线，通过“网关”到“渠道”的交易流水线，处理源源不断从网关发过来的支付请求，最终发往支付渠道完成客户的跨行收付款处理。
2）日终流水线日终流水线又叫清结算流程，它针对日间的实时交易，进行对账和清结算等处理，只有日终处理完了，一天的交易才算完毕。
图8：支付系统流程图
3.2.1 两条主链路
1）实时交易链路
实时交易链路从“网关”到“渠道”形成一条支付请求的处理流水线，客户、收银台、账户和清结算各节点按部就班的处理流水线传递过来的信息，完成客户信息校验，资金账号获取，收银台展示，账务登记，渠道路由和跨行收付款操作。
2）日终结算链路
以清结算系统为起点，通过自动任务获取渠道和交易层的数据进行对账与差错核对，然后通过支付核心与账户系统交互完成渠道清算、商户结算、内部核算操作，最终为客户生成对账单后完成一天的业务处理。
3.2.2 实时双驱动
为了既能处理业务的复杂场景，又能处理渠道和账务的复杂支付逻辑，系统采用了“双发驱动”的模式，脏活累活全都给“交易”和“支付”去处理，两者配合让整条流水线上的各个模块有效的协作起来。
1）交易系统（交易发动机）
是交易层的交易流程调度者，他负责业务场景中的各种复杂交易场景的流程处理。
2）支付系统（支付发动机）
是核心层的支付流程调度者，他负责支付账务、渠道调用的流程处理。
3.2.3 日终做日清
负责日终后的对账和结算处理的流程，驱动支付系统完成渠道清算，商户结算，最终为商户生成结算账单和回单，完成整个支付业务的闭环。
3.2.4 其他保持独立
其他的“客户”、“账户”、“收银台”、“渠道”四个模块接受这两个流程的驱动去各自完成自己的事情就可以了。这样就这样可以保持交易链路清晰，避免多模块之间调用不清造成混乱。
下面我们通过几个典型业务，对支付系统模块间的协作关系进行详细的介绍：
收单业务是第三方支付的核心业务，他场景化比较丰富，因此系统流程也会相对复杂些。我们针对“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购票）从这里我们就可以看到以“交易”和“支付”为流程调度者的优势就出来了，他们可以任意的定制支付流程，从而满足复杂场景对于支付的处理要求。
余额支付就是以账户余额为基础的“充值、提现、转账到户、转账到卡”的交易。
3.4.1 账户充值（充值API）
图12：账户充值流程
1）它不是签约产品充值和提现都是账户默认具有的功能，因此在产品层只读取计费信息即可。
2）同名卡才是充值充值必须要开通的账户和绑定的银卡为同一个人，明确要经过实名认证。因此流程中访问客户系统既要验证你的资金账户是否实名，也要验证你的绑卡是否账户同名。
3）记账入客户待结算充值的账务是入交易发起者的钱包账户，由于跨行收款D1到账的原因，因此先计入客户待结算或者冻结收款余额，等到日终结算的时候才能释放资金。
4）渠道走快捷支付虽然是个充值产品但是底层通道走的是快捷支付扣款，因此整个支付处理流程与快捷是一样的。
3.4.2 账户提现（代付API）
提现是充值的反向交易，因此他获取计费信息、校验绑卡同名与充值基本是相同的，区别在于它记账方式不一样。
图13：账户提现支付流程
1）先冻结，后出款提现底层走的是跨行付款通道，他与收款不同是“实时结算”的，为了避免在银行未入账的情况下客户使用资金，因此提现采用先冻结账户余额，再通过渠道向开户行发送付款申请的方式。
如果付款成功，则将余额解冻后划入清算账户待日终对账后，由收单机构完成跨行清算。如果付款失败该怎么办呢？解冻并释放余额就可以了。
3.4.3 转账到银行卡（代付API）
转账到卡又称为“代付业务”，它和“提现”在支付、账务和渠道处理上是类似的，区别在于它的收款人不是本人。另一个区别是这种API的代付属于是支付产品，并且支付的额度也是受限的。因为代付产品额度较大的容易被作为清算接口使用，会造成业务风险。
图14：转账到卡支付流程
日间实时支付交易完成后，日终清结算开始上场了。我们前面收单交易、充值交易等跨行收款交易资金还要结算给客户和商家，并且要给商家提供账单，这天的业务才算完成，下面我们来介绍下日终的清结算处理流程。
图15：日终清结算流程
1）系统对账下载渠道、支付系统、交易系统对账文件进行对账。先核对渠道账务，再对交易账务并按商家账户维度进行交易清分和手续费扣收。
2）差错调账完成对账后如果有差错，以渠道为准在“账户系统”内调平本方账务差错。
3）渠道清算当日对账无误后，根据当日的应收应付的轧差金额和渠道银存账户的期末余额，在账户系统内登记当日清算账务。（后续清结算的文章中我将会详细介绍）。
4）商户结算当日对账无误后，根据每个商户、客户的待结算资金进行结算，收款资金在他们账户上就可以使用了。（因为是以渠道方为准，渠道清算和商户结算没有必然的先后顺序，所以只要账务对平就可以进行）
5）商户提现商户结算完成后如果商户设为自动提现，系统在T+1日自动完成商户的打款操作，并生成商户结算账单。
6）账务核算渠道清算和商户结算完成后，账户系统的核算模块对当天的账务进行总分核算、汇总平衡，最终生成报表。当日的交易也就处理完成了。（后续清结算和会计文章中会详细介绍）
支付系统采用三层架构来划分，外三层是“场景、系统、渠道”，内三层是“产品、交易、核心”，我们所说的支付架构主要是系统层面内三层的划分，他由三部分组成：
图16：支付系统分层
1）一个平台：承载支付业务。
2）两个通道：网关接入适配不同场景，渠道接出适配不同金融资源。
3）三层架构：产品、交易、核心三层架构，采用流水线方式处理源源不断的支付请求。
支付中台一般由八个模块组成，他承载了支付业务核心的闭环功能，可以适应不同场景的支付需求。
图17：支付系统八个模块
图18：支付系统的流水线作业
1）实时流水线：从“网关”到“渠道”形成一条支付请求的处理链路，系统各模块处理流水线传递过来的信息，最终的跨行收付款操作。
2）日终流水线：从其结算系统开始，处理每天渠道资金清算、商户资金结算、账务核算的处理流程，这样才算完成一天的交易闭环。
图19：支付系统流程图
1）两条主链路：横向的实时交易链路处理交易请求和与跨行收付款，纵向的日终结算链路处理账务和清结算工作。
2）日间双驱动：实时交易链路，由两个流程调度者“交易、支付”来协调各个模块来处理支付请求。
3）每天做日清日终交易链路，以清结算系统为起点，每天日终清结算系统和支付、账户模块完成一天最终的账务处理。
公众号：刚说产品
本文由 @刚哥 原创发布于人人都是产品经理，未经授权，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。