您是否对各种支付架构图感到困惑？ 本文为大家总结了一张清晰的支付架构图，让你快速了解一个支付系统是如何工作的。 让我们来看看。

您是否因为工作中需要画支付结构图而苦恼如何表达清楚？ 您是否对各种支付架构图感到困惑？ 今天我将向您介绍一个简单明了的支付结构，以便您快速掌握支付系统的工作原理。 【老规矩，只想看精华的同学直接看第四章总结】

01 支付系统简介 1.1 什么是支付系统

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

这种交易方式大大提高了产品销售的效率。 他也是电商业务和平台经济崛起的核心基础设施，因为顺利收款是任何商业模式成功的前提。

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

1.2 支付系统分层

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

图2：支付系统架构分层

1.2.1 一个系统

为了实现买卖双方之间的跨行收付款，支付平台将支付产品封装成接口或支付页面供客户使用，并通过层层实现资金跨行划转至收款人账户。系统的层转换。 因此，一个最简单的支付系统由以下八个模块组成。

图3：支付中心主要模块

1.2.2 两个通道

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

它是支付系统的“接入终端”，通过接口、页面、终端设备向用户提供支付产品，进行支付、开户、认证。 同时，在访问网关或使用终端设备时，您必须安装“密钥和证书”，以确保您的支付安全。

2）通道（出局端）

是支付系统的“输出端”。 负责连接第三方、银行、清算机构的支付接口，转换为标准支付产品供上层产品使用。 如果他选择连接多个银行的相同支付产品，他可以根据“订单、渠道和稳定性”进行动态路由选择。

1.2.3 三层架构

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

产品层是适应不同场景的支付需求，将基础支付产品包装成针对不同场景的销售产品，满足各行业的特殊支付需求。 例如针对个人用户的B2C、C2C支付，针对企业的B2B支付，针对金融机构的消费支付等。 因此，产品层是对交易层的深度封装，使其更适应不同场景的需求，方便用户使用。

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

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

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

“核心层”也称为“支付层”，为交易层提供原始记账、渠道、清算结算服务。 它侧重于内部记账逻辑和支付通道处理逻辑，核心层也代表了一个系统。 核心能力决定了上层产品是否好用、好卖、好管理（人们常说产品好看但不好用，通常是核心能力不足造成的）。

02 支付业务架构

图4：支付业务架构

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

从支付业务架构中我们可以看到，相比层次架构图，实际的业务架构有很多辅助系统来支持支付业务的运行。 但支付业务的核心闭环仍然是支付服务中的八个模块。 下面我们分别介绍一下。

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）回调返回结果 当用户完成支付时，通道会主动向收单机构发起回调通知，收单机构将结果发送给商户。 若久不回。 有两种处理方法来同步最终结果。 一种是主动发起支付结果查询，另一种是设置倒计时超时，直接发起取消或退款（类似购买机票）。 从这里我们可以看到“交易”和“支付”作为流程调度器的优势就出来了。 他们可以任意定制支付流程，满足复杂场景的支付处理需求。

3.4 余款支付

余额支付是指根据账户余额进行的“充值、取款、转账到账户、转账到卡”的交易。

3.4.1 账户充值（充值接口）

图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 八个模块

支付平台一般由八个模块组成。 承载支付业务核心闭环功能，能够适应不同场景的支付需求。

图17：支付系统的八个模块

4.3 装配线作业

图18：支付系统流水线运行

1）实时管道：从“网关”到“通道”形成一条支付请求处理链路。 系统各模块对管道传递过来的信息进行处理，最终进行跨行支付操作。

2）日终流水线：从其结算系统开始，处理日常的渠道资金结算、商户资金结算、会计核算流程。 这样才能完成当天的交易闭环。

4.4 付款流程

图19：支付系统流程图

1）两个主要链接：水平实时交易链接处理交易请求以及银行间收据和付款，以及垂直的日期结算链接链接处理会计和结算工作。

2）白天双驱动程序：实时交易链接，两个过程调度程序“交易和付款”协调每个模块以处理付款请求。

3）从清算和结算系统开始，进行日常清算和日末交易链接，并完成一天的最终会计处理，直到一天结束清算和结算系统以及付款和付款和帐户模块。