深度解析：什么是清算核心？

系统业务流程分析

系统架构和领域模型

逻辑视图

部署视图

这里的 Mix 系统职责是两块，一块是作为复杂支付渠道的业务产品，包括网点支付、代金卡、COD、MotoPay；一块是划入支付层职责的转帐账分润业务。之所以要提出这个系统，是因为这些复杂支付渠道的业务逻辑被分散在多个系统中（支付系统，开发平台，银行网关），而这些在系统中的定位是通信前置，不应该包含这些逻辑。所以统一迁到 Mix 系统中。

模型总览

清算实体通用模型

渠道类型

支付机构内部渠道划分为以下几类：

银行卡类型：

清算类型：

清算指令的状态：

清算指令的通信状态（文件类状态）：

指令类状态

批量的指令有两种发送的实现模式：

• 落地为文件供结算人工下载，人工发送提交。

• 直接通过和银行交互的接口批量或者单笔发送出去

核心的业务逻辑

1. 充值文件内清算指令总笔数 = 充值清算文件处理结果总笔数

2. 充值文件内每笔清算指令金额和状态 = 充值清算文件处理结果内每笔清算指令金额和状态

3. 充退文件内清算指令总笔数 = 充退清算文件处理结果的总笔数

4. 充退文件内每笔清算指令金额和状态 = 充退清算文件处理结果内每笔清算指令金额和状态

业务边界分析

清算文件处理

• 充值回导文件获取

• 充值回导文件有两种获取方式：一种是人工去银行网银系统去下载，并保存到本地硬盘，然后通过工作平台提供的上传功能进行上传。第二种是人工或系统触发（系统自动触发会是固定时间点，或者有规律的时间段）并由系统通信前置与银行服务器进行交互拿到回导文件。

我们这里主要指的是第二种。

清算文件处理

充值回导文件解析

• 见上图，我们要把解析脚本内容保存到数据库，直接读取数据库中的内容，这样方便管理和更新。

• 每一个文件解析脚本和文件模板都需要仔细开发。

充值回导文件导入

• 文件解析完成后，需要把数据对象存储到数据库中，对于充值来说业务关键字段和提现一样：充值订单号和充值金额。

充值回导文件对账

• 对账需要在导入后进行触发，可以是人工触发，也可以是系统自动触发，也可以在导入后立即系统自动触发对账。系统将提供接口供工作平台调用或者系统自己调用。

• 系统触发可以配置成一个定时执行任务，这样可以把实时要做的事情变成异步确保会做的事情，将使用到定时预约的系统功能，在定时查询中有讲这个工具。通用的对账流程如下图

银行通信前置

• 主要涉及到的工作是网银对指令的签名、校验签名以及报文服务费与清算核心的对接，还有获取对账文件的对接

清算指令处理

指令的清算结果状态：

清算指令的通信状态（文件类状态）

指令类状态

批量的指令有两种发送的实现模式：

• 落地为文件供结算人工下载，人工发送提交。

• 直接通过和银行交互的接口批量或者单笔发送出去

内部服务管理

指令处理时序图

系统边界分析

经过前期对业务上的一些认识，目前产品可以分为三大类：直连模式、网银异步模式、其它个性化模式。

直连模式

网银异步模式

转载于:https://blog.51cto.com/13835746/2154011