支付系统设计白皮书：核心的 7 个要点
一、支付前置
着业务定制化对交易支付需求复杂度的增加，交易系统保证系统稳定的同时，亦需灵活性以支持业务。但系统设计时，灵活和稳定是矛盾的，稳定意味着剥离变化，灵活意味着可配置化。
支付前置的职责即：解决支持业务变化的扩展性，将交易通过支付前置的配置转化为后端支付系统能统一处理的模式，方便后端多样化的记账需求。
支付前置的定义
- 支付前置包装后端支付核心系统的接口，包装后对外提供的服务包括余额、 现金、网银、快捷支付、出款及相关订单的退款和控制接口；另提供后台系统调用的服务包括确定性入款、登账、冻结解冻、退票等，所有的支付行为都会以业务支付订单的形式落地；
- 用户在前端发起一次支付行为后，交易系统基于原始的交易订单，对应生成一条付款订单，通过这笔付款订单和支付核心进行交互。
业务产品码：
交易系统各类交易接口包装成业务产品（提现、充值等）后，将对应的支付请求发送到支付前置系统，前置系统根据业务产品编码和本身的支付业务配置关系，生成对应的业务支付订单并处理后续流程。
支付产品码：
由于即时到账、担保交易在业务规则上不同，但支付渠道侧判断均为支付，因此支付产品码相同，但业务产品码不同。这里的支付产品编码配置来自于支付协议的配置，一个支付产品编码代表着一个支付协议。
二、支付协议
支付协议即对支付模式、支付服务的封装。
以收单支付为例，某个业务方在支付系统开设支付权限后，可理解为与支付系统本身签署了收单支付协议，即可通过交易系统对外输出担保交易产品、即时到账产品来使用收单支付的能力。
此时交易侧定义的两个业务产品码，与支付侧的收单支付产品编码为多对一关系，交易系统调用前置系统时，根据交易产品代码和支付协议的配置，对应生成一条收单支付的请求，前置系统根据该请求转化为对应的付款订单（支付协议的明细项，比如通过网银、现金、快捷等方式发起支付），然后根据对应支付模式、业务支付类型生成业务支付订单，且将业务支付订单转化为支付指令去执行下游系统的流程。
提现协议：
- 以秋秋老师的提现协议为例，提现的明细项关联着业务方所传递的外部订单号，代表着这次业务支付行为的原始订单请求，对应着收付款人的信息；
- 调用支付服务层的时，会有客户权限校验等判断，通过的情况下此时去调用支付协议的配置信息落地一笔支付订单，并基于该订单生成对应的一笔或者多笔支付指令，接下来由指令去执行调用下游系统的具体方式，若是调用清算通道则生成清算类的操作指令（调用通道，调用时间，通道需要的信息等），可称为外部指令，若是要操作账户金额则生成账务类的操作指令（具体账户、金额、借记还是贷记），可称为内部指令。
定义支付的原子级支付形态，所有的支付行为都是账户资金的流转，可梳理出以下几个支付类型：
- 充值：资金从外部资金源向内部资金源转移的支付动作；
- 提现：资金从内部向外部资金源转移的支付动作；
- 内转支付（转账）：资金在内部账户转移的支付动作，这里的定义和产品中定义的转账概念不同；
- 退款：充值的反向操作。
指令即支付核心的工单号，前置的每笔支付订单对应着一笔甚至多笔指令。指令里包含了这笔支付订单是原始支付类型（充值、提现、转账、退款，指令一定是基于原始支付类型来生成的，任何支付行为都能被原子类型所支持），对应着的业务请求类型、支付方式、支付产品编码、参与方信息（交易中收付款人的信息）、相关联的支付指令信息（退款时用于关联原支付指令）、支付服务流程等相关信息；由支付指令去调用支付服务流程时，再根据流程编排环节去确定何时生成账务类操作指令和清算类操作指令。
举例：用户在电商网站购买一本书价格 100 元，通过支付宝付款，交易类型为担保交易，在交易核心生成一笔担保支付的订单，调用支付核心系统时支付系统判断该业务调用方对应已经配置了「收单支付协议」，且根据对应协议生成一笔业务类型为第三方支付的支付订单，基于此订单生成了第一条充值的支付指令。
