支付通道系统功能

支付前置

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

功能定义

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

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

业务产品码

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

支付产品码

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

支付协议

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

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

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

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

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

支付引擎

支付引擎的类型

定义支付的原子级支付形态, 全部的支付行为都是帐户资金的流转, 可梳理出如下几个支付类型

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

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

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

• 退款: 充值的反向操做

指令

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

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

• 对应着的业务请求类型

• 支付方式

• 支付产品编码

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

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

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

由支付指令去调用支付服务流程时, 再根据流程编排环节去肯定什么时候生成帐务类操做指令和清算类操做指令.

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

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

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

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

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

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

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

服务流程

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

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

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

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

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

风控

支付系统设计中, 提高自身的风控意识, 为交易增长风控模块, 能够有效减小风险交易形成的资金损失. 支付核心的风控模块, 通常位于交易处理的最前端, 每笔交易经过风控模块的检验后, 才容许支付核心进行后续的交易处理.

业务规则

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

举例: 我的余额帐户的风控规则 用户使用余额帐户进行首次充值时, 必须经过帐户信息的实名认证. 因为银行会对持卡人的身份进行实名认证, 因此对平台能够经过银行或支付机构提供的银行卡信息验证接口对用户进行实名认证.

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

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

经过以上措施可有效防止用户因我的信息泄漏形成的余额帐户资金损失.

风控模型

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

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

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

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

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

风控运营

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

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

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

内部控台

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

交易操做

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

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

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

交易数据展现

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

报表下载

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

权限控制

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

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

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

报表

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

交易报表

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

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

结算报表

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

财务报表

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

交易监控

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

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

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

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

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

 

参考资料

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