你是否被五花八门的支付架构图搞得眼花缭乱？本文为你总结了一套清晰的支付架构图，让你快速了解支付系统是如何运作的。一起来看看吧。
工作中需要画支付架构图，又苦恼于如何表达清楚？面对五花八门的支付架构图，你是否眼花缭乱？今天就给大家介绍一种简单明了的支付架构，让你快速了解一个支付系统是怎么运作的。【照例，只看精华的同学可以直接翻到最后第4章看总结】
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等方式进行。由于移动终端支付应用广泛，所以在企业场景中网银支付使用比较普遍。
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）回调返回结果。当用户完成支付后，渠道方会主动发起回调通知给收单机构，收单机构再把结果给商户。如果长时间没有回应，有两种方式来同步最终结果，一种是主动发起支付结果的查询，一种是倒计时超时直接发起取消或者退款（类似购票）。从这里我们可以看出使用“交易”和“支付”作为流程调度器的优势，它们可以任意定制支付流程，满足复杂场景的支付处理需求。
3.4 余款支付
余额支付是基于账户余额进行的交易，如“充值、提现、转入账户、转入卡”。
3.4.1 账户充值（充值API）
图12：账户充值流程
1）非合约产品，充值、提现均为账户默认功能，产品层面只需要读取账单信息即可。
2）充值必须使用同名卡，开立的账户和绑定的银卡必须是同一个人，并且要进行实名认证，所以在充值过程中进入客户系统时，一定要验证您的资金账户是否实名，绑定的卡是否与账户同名。
3）客户待结算充值账户记录在交易发起人的钱包账户中，由于跨行支付D1到账，先记录客户待结算或冻结支付的余额，当日结束后才可以释放资金。
4）快捷支付虽然是充值产品，但是底层通道采用的是快捷支付扣款，因此整个支付处理流程和快捷支付是一样的。
3.4.2 账户提现（支付API）
提现是充值的逆向交易，因此获取账单信息、验证卡绑定姓名与充值基本一致，区别在于记账方式不同。
图13：账户提现支付流程
1）先冻结，后提现。现金提现的底层渠道是跨行支付通道，与收款不同，是“实时结算”。为防止客户在银行未入账前动用资金，提现方式是先冻结账户余额，再通过该通道向开户银行发送支付申请。
如果支付成功，余额会解冻并转入清算账户进行日终对账，收单机构完成跨行清算。如果支付失败怎么办？只要解冻并释放余额即可。
3.4.3 转入银行卡（支付API）
转卡也叫“代付业务”，在支付、账户、渠道处理等方面与“现金提现”类似，只是收款人不是本人。另一个区别是，这种API代付是支付产品，支付金额也有限制，因为金额大的代付产品容易被当做清算接口，从而带来业务风险。
图14：转卡支付流程
3.5 清算及结算流程
日间实时支付交易完成后，日终结算就开始了。收单交易、充值交易等跨行收款交易的资金必须结算给客户和商户，商户必须提供账单，当天的业务才算完成。现在我们来介绍一下日终结算的流程。
图15：日终结算流程
1）系统对账下载渠道、支付系统、交易系统对账文件进行对账，先对接渠道账，再对接交易账，并按照商户账户维度进行交易清算和扣费。
2）错误调整 若对账后出现错误，将通过此渠道在“账户体系”中调整账务错误。
3）渠道结算日对账无误后，根据当日应收应付净差额与渠道银行存款账户期末余额，在账户体系中记录当日结算账户。（我会在后续的清结算文章中详细介绍这一点）。
4）结算日商户对账无误后，按照各商户、客户待结算资金进行结算，收款即可在其账户中使用。（因为是以渠道方为单位，所以渠道结算与商户结算没有必然的先后顺序，只要账户平衡即可进行）
5）商户提现商户结算完成后，若商户设置了自动提现，系统将于T+1日自动完成商户的付款操作，并生成商户结算账单。
6）账户结算渠道清算、商户结算完成后，账户体系的会计模块会计算当日总额及子账户，汇总平衡，最后生成报表。当日的交易也会进行处理。（后续的清算及会计文章会详细介绍）
04 总结：支付架构四张图
4.1 三层架构
支付体系分为三层，外三层为“场景、系统、渠道”，内三层为“产品、交易、核心”。我们讲的支付架构，主要是系统层面对内三层的划分。它由三部分组成：
图 16：支付系统层级
1）A平台：承载支付服务。
2）两种渠道：网关接入适应不同的场景，渠道接入适应不同的财力。
3）三层架构：产品、交易、核心三层架构，采用流水线方式处理源源不断的支付请求。
4.2 八个模块
支付中台一般由8个模块组成，承载着支付业务的核心闭环功能，可以适应不同场景的支付需求。
图17：支付体系八大模块
4.3 装配线操作
图 18：支付系统管道运行
1）实时管道：从“网关”到“通道”形成支付请求处理链路，系统各模块对管道传输的信息进行处理，最终完成跨行支付、收款操作。
2）日末装配线：从其结算系统开始，它处理渠道资金清算，商家资金和解和会计的日常处理程序，以便完成当天的交易封闭循环。
4.4付款过程
图19：支付系统流程图
1）两个主要链接：水平实时交易链接处理交易请求以及银行间的付款和收据，以及垂直的日期结算链接链接处理会计以及清算和结算工作。
2）白天双驱动器：实时交易链接，两个过程调度程序“交易和付款”协调各种模块以处理付款请求。
3）从清算和结算系统开始，每天进行清算和日末交易链接。