系统业务流程分析
系统架构和领域模型
逻辑视图
部署视图
这里的 Mix 系统职责是两块，一块是作为复杂支付渠道的业务产品，包括网点支付、代金卡、COD、MotoPay；一块是划入支付层职责的转帐账分润业务。之所以要提出这个系统，是因为这些复杂支付渠道的业务逻辑被分散在多个系统中（支付系统，开发平台，银行网关），而这些在系统中的定位是通信前置，不应该包含这些逻辑。所以统一迁到 Mix 系统中。
模型总览
清算实体通用模型
渠道类型
支付机构内部渠道划分为以下几类：
银行卡类型：
清算类型：
清算指令的状态：
清算指令的通信状态（文件类状态）：
指令类状态
批量的指令有两种发送的实现模式：
- 落地为文件供结算人工下载，人工发送提交。
- 直接通过和银行交互的接口批量或者单笔发送出去
核心的业务逻辑
- 充值文件内清算指令总笔数 = 充值清算文件处理结果总笔数
- 充值文件内每笔清算指令金额和状态 = 充值清算文件处理结果内每笔清算指令金额和状态
- 充退文件内清算指令总笔数 = 充退清算文件处理结果的总笔数
- 充退文件内每笔清算指令金额和状态 = 充退清算文件处理结果内每笔清算指令金额和状态
业务边界分析
清算文件处理
- 充值回导文件获取
- 充值回导文件有两种获取方式：一种是人工去银行网银系统去下载，并保存到本地硬盘，然后通过工作平台提供的上传功能进行上传。第二种是人工或系统触发（系统自动触发会是固定时间点，或者有规律的时间段）并由系统通信前置与银行服务器进行交互拿到回导文件。
我们这里主要指的是第二种。
清算文件处理
充值回导文件解析
见上图，我们要把解析脚本内容保存到数据库，直接读取数据库中的内容，这样方便管理和更新。
每一个文件解析脚本和文件模板都需要仔细开发。
充值回导文件导入
文件解析完成后，需要把数据对象存储到数据库中，对于充值来说业务关键字段和提现一样：充值订单号和充值金额。
充值回导文件对账
对账需要在导入后进行触发，可以是人工触发，也可以是系统自动触发，也可以在导入后立即系统自动触发对账。系统将提供接口供工作平台调用或者系统自己调用。
系统触发可以配置成一个定时执行任务，这样可以把实时要做的事情变成异步确保会做的事情，将使用到定时预约的系统功能，在定时查询中有讲这个工具。通用的对账流程如下图
银行通信前置
主要涉及到的工作是网银对指令的签名、校验签名以及报文服务费与清算核心的对接，还有获取对账文件的对接。
清算指令处理
指令的清算结果状态：
清算指令的通信状态（文件类状态）
指令类状态
批量的指令有两种发送的实现模式：
- 落地为文件供结算人工下载，人工发送提交。
- 直接通过和银行交互的接口批量或者单笔发送出去
内部服务管理
指令处理时序图
系统边界分析
经过前期对业务上的一些认识，目前产品可以分为三大类：直连模式、网银异步模式、其它个性化模式。
直连模式
网银异步模式
想要学习清算核心的更多内容，请验证信息下载完整 PDF 课件