支付通道系统功能

支付前置

着业务定制化对交易支付需求复杂度的增加, 交易系统保证系统稳定的同时, 亦需灵活性, 灵活意味着可配置化. 支付前置负责解决支持业务变化的扩展性, 将交易通过支付前置的配置转化为后端支付系统能统一处理的模式, 方便后端多样化的记账需求.

功能定义

支付前置包装后端支付核心系统的接口, 包装后对外提供的服务包括余额, 现金, 网银, 快捷支付, 出款及相关订单的退款和控制接口; 另提供后台系统调用的服务包括确定性入款, 登账, 冻结解冻, 退票等. 所有的支付行为都会以业务支付订单的形式落地.

用户在前端发起一次支付行为后, 交易系统基于原始的交易订单, 对应生成一条付款订单, 通过这笔付款订单和支付核心进行交互。

业务产品码

交易系统各类交易接口包装成业务产品(提现, 充值等)后, 将对应的支付请求发送到支付前置系统, 前置系统根据业务产品编码和本身的支付业务配置关系, 生成对应的业务支付订单并处理后续流程.

支付产品码

由于即时到账, 担保交易在业务规则上不同, 但支付渠道侧判断均为支付, 因此支付产品码相同但业务产品码不同. 这里的支付产品编码配置来自于支付协议的配置, 一个支付产品编码代表着一个支付协议.

支付协议

支付协议即对支付模式, 支付服务的封装.

以收单支付为例, 某个业务方在支付系统开设支付权限后, 可理解为与支付系统本身签署了收单支付协议, 即可通过交易系统对外输出担保交易产品和即时到账产品来使用收单支付的能力.

此时交易侧定义的两个业务产品码, 与支付侧的收单支付产品编码为多对一关系, 交易系统调用前置系统时, 根据交易产品代码和支付协议的配置, 对应生成一条收单支付的请求, 前置系统根据该请求转化为对应的付款订单(支付协议的明细项, 比如通过网银, 现金, 快捷等方式发起支付), 然后根据对应支付模式和业务支付类型生成业务支付订单, 且将业务支付订单转化为支付指令去执行下游系统的流程.

提现协议 以提现协议为例, 提现的明细项关联着业务方所传递的外部订单号, 代表着这次业务支付行为的原始订单请求, 对应着收付款人的信息.

调用支付服务层的时, 会有客户权限校验等判断, 通过的情况下此时去调用支付协议的配置信息落地一笔支付订单, 并基于该订单生成对应的一笔或者多笔支付指令, 接下来由指令去执行调用下游系统的具体方式, 若是调用清算通道则生成清算类的操作指令(调用通道, 调用时间, 通道需要的信息等), 可称为外部指令, 若是要操作账户金额则生成账务类的操作指令(具体账户, 金额, 借记还是贷记), 可称为内部指令.

支付引擎

支付引擎的类型

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

• 充值: 资金从外部资金源向内部资金源转移

• 提现: 资金从内部资金源向外部资金源转移

• 内转支付(转账): 资金在内部账户转移, 这里的定义和产品中定义的转账概念不同

• 退款: 充值的反向操作

指令

指令即支付核心的工单号, 前置的每笔支付订单对应着一笔甚至多笔指令. 指令里包含了这笔支付订单的

• 原子支付类型(充值, 提现, 转账, 退款), 指令一定是基于原子支付类型来生成的, 任何支付行为都能被原子类型所支持

• 对应着的业务请求类型

• 支付方式

• 支付产品编码

• 参与方信息(交易中收付款人的信息)

• 相关联的支付指令信息(退款时用于关联原支付指令)

• 支付服务流程等相关信息

由支付指令去调用支付服务流程时, 再根据流程编排环节去确定何时生成账务类操作指令和清算类操作指令.

举例 用户在电商网站购买一本书价格 100 元,

1. 通过支付宝付款, 交易类型为担保交易,

2. 在交易核心生成一笔担保支付的订单,

3. 调用支付核心系统时支付系统判断该业务调用方对应已经配置了「收单支付协议」, 且根据对应协议生成一笔业务类型为第三方支付的支付订单

4. 基于此订单生成了第一条充值的支付指令.

5. 该指令在根据支付类型去调用服务流程时，先通过流程编排生成清算指令并调用(这里值得注意的是, 先生成清算指令的原因在于需要先调用外部支付渠道, 把钱收进来)

6. 用户付款成功后再生成账务指令并调用账务核心, 执行内部账务入账

服务流程

定义支付指令的执行流程, 将支付拆分成原子支付类型, 并对支付类型的流程进行编排, 任何一个交易的请求, 都能由上述四种原子支付类型组合完成支付行为.

例如: 一笔担保收单的交易, 用户用支付宝等第三方支付完成了这笔交易, 并在 7 天后确认收货, 平台侧 7 天后根据用户的行为应该将该笔货款打给了商户. 这里我们将用户的行为分为支付和确认收货两个动作, 对应着在交易侧 = 两次请求 + 一次支付 + 一次结算:

• 在支付层对应收单支付协议

• 在前置系统被拆分成了两笔业务支付订单, 一笔是快捷支付, 业务类型自定义, 可以叫第三方支付; 一笔是余额转账, 将资金从担保账户结算到商家账户

• 分别生成两条支付指令, 充值和转账. 充值代表着用户的支付行为, 转账代表着用户的确认收货行为, 因为从但保护结算到商家账户, 可以定义为一笔账户之间的资金流转

风控

支付系统设计中, 提升自身的风控意识, 为交易增加风控模块, 可以有效减少风险交易造成的资金损失. 支付核心的风控模块, 一般位于交易处理的最前端, 每笔交易通过风控模块的检验后, 才允许支付核心进行后续的交易处理.

业务规则

为支付核心设计交易流程和业务规则时, 了解交易中可能发现的风险因素并注意异常环节, 是拦截风险交易的有效途径. 对于一些常见的支付产品, 已经形成了一些能够有效防范风险交易的通用业务规则.

举例: 个人余额账户的风控规则 用户使用余额账户进行首次充值时, 必须通过账户信息的实名认证. 由于银行会对持卡人的身份进行实名认证, 所以对平台可以通过银行或支付机构提供的银行卡信息验证接口对用户进行实名认证.

实名认证使用四要素, 需要验证姓名, 身份证号, 银行卡号, 手机号. 完成实名认证后, 用户必须设置支付密码, 后续自消费和提现时, 使用支付密码保证余额资金的安全.

用户更换余额账户提现银行卡时, 必须对已绑定的银行卡进行进行校验, 要求用户输入已绑定银行的完整账号和绑定手机号, 同时新绑定的提现银行卡, 也必须和账户已验证的身份信息一致.

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

风控模型

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

• 交易信息: 当前交易自身的信息要素, 例如交易类型, 交易金额, 交易时间, 支付账号等信息

• 客户信息: 发起该笔交易的平台用户信息, 包括用户使用的设备类型, 设备编号, 用户定位信息, 用户手机号, 手机号归属地等

• 历史数据: 用户在平台发生过历史交易, 其历史交易的交易信息和用户信息

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

风控运营

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

对于命中风险交易的交易请求, 采用事前拦截的处理机制, 由风控模块直接拒绝交易

对于疑似风险交易的, 进入风控模块的待审核交易列表, 由风控专员对可疑交易进行人工审核. 审核后认为是风险交易的, 则拒绝交易, 审核后不属于风险交易的则由支付核心继续后续的交易处理

内部控台

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

交易操作

• 业务运营人员, 需要对支付系统中已经发生的交易进行检索, 确认某一具体交易的交易状态

• 对于某一笔具体交易，进行退款操作

• 内部控台要为业务运营人员提供交易操作入口

交易数据展示

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

报表下载

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

权限控制

• 内部控台要限制仅可以通过公司内网访问, 并控制可以查看数据的人员数量

• 具有数据查看权限的人员, 需要对数据安全和资金安全负责

• 用户的卡号姓名等信息, 要做脱敏显示, 预防用户信息泄露

报表

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

交易报表

按照固定的时间周期, 将支付系统中已成功处理的交易流水生成交易报表. 交易报表展示的交易流水, 需要按照交易系统支持的交易服务类型分别生成.

支付交易, 充值交易, 出款交易在交易数据信息上各不相同, 需要分别出具独立的交易报表, 一般按照日周月为时间维度, 固定出具交易报表, 交易报表中除了提供交易流水明细, 还需要提供该时间周期内的汇总数据, 方便使用者快速了解这个时间段内的交易情况.

结算报表

支付系统的清算核心对账户中资金进行结算时生成结算报表, 供运营或财务进行付款前的确认或者作为付款凭证作为后续查账和审核的依据. 面向内部人员使用的结算报表可以根据本系统的业务需求增加其他信息字段, 以便于更好地了解结算交易信息.

财务报表

账务核心分账户来管理资金, 账户记录了所属会计科目和账务记录, 账务记录标明了账户的资金收支情况. 按照公司的财务报表编制期间需求, 对同一类会计科目的账户, 分别统计该报表编制期间内收入和支出金额, 生成财务报表.

交易监控

支付系统的稳定性十分重要, 一旦因技术故障出现交易中断, 会对整个平台的业务造成重大影响.

监控支付渠道的交易稳定性包括

• 监控支付系统对接的外部渠道的接口响应时间和成功交易占比这两个重要指标

• 监控支付核心处理交易的平均时间, 保证支付系统的稳定信息

交易监控中发现的异常告警以短信邮件等方式及时通知负责人员进行处理

名词

ABS 中央银行会计核算系统

ACS 中央银行会计核算数据集中系统

Payment 支付

Clearing 清分: 对支付指令进行计算归类和传递, 资金未转移

Settlement 结算: 根据清分结果进行账户间资金转移

SWIFT (Society for Worldwide Interbank Financial Telecommunication) 环球同业银行金融通信系统

 

 

 

 

参考资料

http://www.woshipm.com/it/1371591.html 对账中心功能, 清算对账业务流程