支付系统设计白皮书：支付核心的 7 个要点

2019-04-06 22:19:00

本文跟大家探讨一下支付核心的七个要点，一起来看看~

一、支付前置

着业务定制化对交易支付需求复杂度的增加，交易系统保证系统稳定的同时，亦需灵活性以支持业务。但系统设计时，灵活和稳定是矛盾的，稳定意味着剥离变化，灵活意味着可配置化。
支付前置的职责即：解决支持业务变化的扩展性，将交易通过支付前置的配置转化为后端支付系统能统一处理的模式，方便后端多样化的记账需求。
支付前置的定义

支付前置包装后端支付核心系统的接口，包装后对外提供的服务包括余额、现金、网银、快捷支付、出款及相关订单的退款和控制接口；另提供后台系统调用的服务包括确定性入款、登账、冻结解冻、退票等，所有的支付行为都会以业务支付订单的形式落地；
用户在前端发起一次支付行为后，交易系统基于原始的交易订单，对应生成一条付款订单，通过这笔付款订单和支付核心进行交互。
业务产品码：
交易系统各类交易接口包装成业务产品（提现、充值等）后，将对应的支付请求发送到支付前置系统，前置系统根据业务产品编码和本身的支付业务配置关系，生成对应的业务支付订单并处理后续流程。
支付产品码：
由于即时到账、担保交易在业务规则上不同，但支付渠道侧判断均为支付，因此支付产品码相同，但业务产品码不同。这里的支付产品编码配置来自于支付协议的配置，一个支付产品编码代表着一个支付协议。
二、支付协议
支付协议即对支付模式、支付服务的封装。
以收单支付为例，某个业务方在支付系统开设支付权限后，可理解为与支付系统本身签署了收单支付协议，即可通过交易系统对外输出担保交易产品、即时到账产品来使用收单支付的能力。
此时交易侧定义的两个业务产品码，与支付侧的收单支付产品编码为多对一关系，交易系统调用前置系统时，根据交易产品代码和支付协议的配置，对应生成一条收单支付的请求，前置系统根据该请求转化为对应的付款订单（支付协议的明细项，比如通过网银、现金、快捷等方式发起支付），然后根据对应支付模式、业务支付类型生成业务支付订单，且将业务支付订单转化为支付指令去执行下游系统的流程。
提现协议：
以秋秋老师的提现协议为例，提现的明细项关联着业务方所传递的外部订单号，代表着这次业务支付行为的原始订单请求，对应着收付款人的信息；
调用支付服务层的时，会有客户权限校验等判断，通过的情况下此时去调用支付协议的配置信息落地一笔支付订单，并基于该订单生成对应的一笔或者多笔支付指令，接下来由指令去执行调用下游系统的具体方式，若是调用清算通道则生成清算类的操作指令（调用通道，调用时间，通道需要的信息等），可称为外部指令，若是要操作账户金额则生成账务类的操作指令（具体账户、金额、借记还是贷记），可称为内部指令。

三、支付引擎

1. 支付引擎的类型

定义支付的原子级支付形态，所有的支付行为都是账户资金的流转，可梳理出以下几个支付类型：

充值：资金从外部资金源向内部资金源转移的支付动作；
提现：资金从内部向外部资金源转移的支付动作；
内转支付（转账）：资金在内部账户转移的支付动作，这里的定义和产品中定义的转账概念不同；
退款：充值的反向操作。

2. 指令

指令即支付核心的工单号，前置的每笔支付订单对应着一笔甚至多笔指令。指令里包含了这笔支付订单是原始支付类型（充值、提现、转账、退款，指令一定是基于原始支付类型来生成的，任何支付行为都能被原子类型所支持），对应着的业务请求类型、支付方式、支付产品编码、参与方信息（交易中收付款人的信息）、相关联的支付指令信息（退款时用于关联原支付指令）、支付服务流程等相关信息；由支付指令去调用支付服务流程时，再根据流程编排环节去确定何时生成账务类操作指令和清算类操作指令。
举例：用户在电商网站购买一本书价格 100 元，通过支付宝付款，交易类型为担保交易，在交易核心生成一笔担保支付的订单，调用支付核心系统时支付系统判断该业务调用方对应已经配置了「收单支付协议」，且根据对应协议生成一笔业务类型为第三方支付的支付订单，基于此订单生成了第一条充值的支付指令。
该指令在根据支付类型去调用服务流程时，先通过流程编排生成清算指令并调用（这里值得注意的是，先生成清算指令的原因在于需要先调用外部支付渠道，把钱收进来），用户付款成功后再生成账务指令并调用账务核心，执行内部账务入账。

3. 服务流程

定义支付指令的执行流程，将支付拆分成原子级支付类型，并对支付类型的流程进行编排，任何一个交易的请求，都能被上述四种基础支付类型组合进而完成支付行为。
例如：一笔担保收单的交易，用户用支付宝等第三方支付完成了这笔交易，并在 7 天后确认收货，平台侧 7 天后根据用户的行为应该将该笔货款打给了商户。
这里我们将用户的行为分为支付和确认收货两个动作，对应着在交易侧这也是两次请求，一次支付，一次结算：

在支付层对应收单支付协议；
在前置系统被拆分成了两笔业务支付订单，一笔是快捷支付（业务类型，类型自定义，可以叫第三方支付），一笔是余额转账（将资金从担保账户结算到商家账户）；

而后分别生成两条支付指令（充值和转账），充值代表着用户的支行为，转账代表着用户的确认收货行为，因为从但保护结算到商家账户，可以定义为这是一笔账户之间的资金扭转。

四、风控

风控是风险交易防范与控制的简称。支付系统设计中，提升自身的风控意识，在必要时为交易增加风控模块，可以有效减少风险交易造成的资金损失。支付核心的风控模块，一般位于交易处理的最前端，每笔交易通过风控模块的检验后，才允许支付核心进行后续的交易处理。
是否设置风控模块，需要评价投入产出比。当支付系统内积累了一定量风险交易数据，并且已经产生实际经济损失的情况下，则需考虑在支付系统内设置风控模块。

1. 业务规则

为支付核心设计交易流程和业务规则时，了解交易中可能发现的风险因素并注意异常环节，是拦截风险交易的有效途径。对于一些常见的支付产品设计中，已经形成了一些能够有效防范风险交易的通用业务规则。
余额账户：
用户使用余额账户进行首次充值时，必须通过账户信息的实名认证。由于用户在银行办理银行卡时，银行一定会对持卡人的身份进行实名认证，所以对平台余额账户使用者可以通过利用银行或支付机构提供的银行卡信息验证接口，对用户进行实名认证。

进行实名认证时，需要验证姓名、身份证号、银行卡号、手机号；完成实名认证后，用户必须设置支付密码，后续自消费和提现时，就可以使用支付密码保证余额资金的安全。
用户更换余额账户提现银行卡时，必须对已绑定的银行卡进行进行校验，要求用户输入已绑定银行的完整账号和绑定手机号；同时新绑定的提现银行卡，也必须和账户已验证的身份信息一致。

以上措施，可有效防止用户个人信息泄漏造成的余额账户资金损失。

2. 风控模型

风控模型，是依赖可获取的交易信息和客户信息，抽象出的风险交易特征。可用于抽象分析风险交易特征的主要有三类：

交易信息：该笔交易自身的信息要素，例如交易类型、交易金额、交易时间、支付账号等信息；
客户信息：发起该笔交易的平台用户信息，包括用户使用的设备类型、设备编号、用户定位信息、用户手机号、手机号归属地等；
历史数据：用户在平台发生过历史交易，其历史交易的交易信息和用户信息。

通过对已发生的风险交易，分析上述信息即可抽象出风控模型，供风控模块识别风险交易。

3. 风控运营

对于风控模块识别出的风险交易，根据危害程度的等级不同，分为「事前拦截」和「事中审核」两种处理机制。

对于明确一定属于风险交易的交易请求，采用事前拦截的处理机制，支付核心收到后，由风控模块直接拒绝交易。
对于无法确认是否属于风险交易的，进入风控模块的待审核交易列表，由风控专员对可疑交易进行人工审核。审核后认为是风险交易的，则拒绝交易；审核后不属于风险交易的，由支付核心继续后续的交易处理。

五、内部控台

支付核心需要为内部的运营、财务、管理层，提供查看交易数据的可视化管理网站。

1. 交易操作

业务运营人员，需要对支付系统中已经发生的交易进行检索，确认某一具体交易的交易状态；
对于某一笔具体交易，进行退款操作；
内部控台要为业务运营人员提供交易操作入口。

2. 交易数据展示

管理层希望了解整个平台的业务运作情况，支付系统通过内部控台提供交易总额、订单转化率、支付渠道占比等可视化的数据图表，直观展示交易数据的变化情况。

3. 报表下载

将历史交易数据整理为交易报表，供相关人员以下载的方式直接获取。

4. 权限控制

支付系统的交易数据属于敏感信息。首先，内部控台要限制仅可以通过公司内网访问，并控制可以查看数据的人员数量，具有数据查看权限的人员，需要对数据安全和资金安全负责；其次，和用户有关的卡号、姓名等信息，要做脱敏显示，预防泄露用户信息。

六、报表

支付系统负责将交易数据，定期整理为报表，供有关人员下载使用。

1. 交易报表

按照固定的时间周期，将支付系统中已成功处理的交易流水，生成交易报表。交易报表展示的交易流水，需要按照交易系统支持的交易服务类型，分别生成交易报表。
支付交易、充值交易、出款交易，在交易数据信息上各不相同，需要分别出具独立的交易报表；一般按照日、周、月为时间维度，固定出具交易报表；交易报表中除了提供交易流水明细，还需要提供该时间周期内的汇总数据，方便使用者快速了解这个时间段内的交易情况。
交易报表的结构关系为：