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

清算核心是什么？文章通过从系统业务流程、系统架构和领域模型、业务边界分析和系统边界分析四个方面来解析，一起来看看~

系统业务流程分析

• 第0步由产品层来实现各种接受提现请求的场景。
• 第1-1.2步骤归为支付层处理，支付层的核心是支付协议，前面讲支付核心时已经分析过，简单点说：一个支付协议可以=一个账务指令+一个清算指令。其中账务指令和清算指令，都是可以进行运行的最小单位。
• 第1-2.4步，本讲中称作清算平台，其中2.2和2.3承担的工作叫做通信前置，负责指令的发送，和接受指令的返回，在物理部署上他们将**是独立的通信前置机器。像使用文件这种人工提交的方式处理的指令2.2和2.3步骤则分别**被影射到文件生成器，和文件解析器上，也是清算系统和外部进行批量交互的核心组件。
• 第3步是清算层处理完毕后的收尾工作，让支付层知道最后的处理结果，对于先扣款的交易来说，这一步的影响仅仅在于两边记录的清算指令最终状态的一致性，对于以后可能出现的其他交易来说，这个状态可能**决定后续账务处理。

系统架构和领域模型

逻辑视图

部署视图

• 这里的mix系统职责是两块，一块是作为复杂支付渠道的业务产品，包括（网点支付、代金卡、COD、MotoPay），一块是划入支付层职责的转帐和分润业务。之所以要提出这个系统，是因为这些复杂支付渠道的业务逻辑被分散在多个系统中（支付系统、开发平台、银行网关），而这些在系统中的定位是通信前置，不应该包含这些逻辑。所以统一迁到mix系统中。
• Mix系统的使用者有外部前置系统和收银台，外部前置系统提出复杂支付渠道请求时，外部前置做了基本的接口校验之后，所有逻辑处理由mix来负责。收银台是支付渠道的发起者，如果发起复杂支付渠道请求，也先转给mix来处理。
• Mix系统作为复杂支付渠道的业务产品，但完成支付，最终还是调用支付核心来完成。与mix后端交互系统，目前只有支付核心。发起支付请求时，mix调用支付核心。支付核心支付完毕之后，业务分流给mix系统。
• 清算核心负责整体清算模型的运转，所有跟外部机构有清算需求的业务，都经过清算核心，包括前面提到的复杂支付渠道。
• 支付核心和清算之间的关系非常明确，支付核心调用清算核心进行清算请求，清算核心清算完毕之后，反馈给支付核心。
• 清算核心是负责整体清算模型，具体的清算指令发送，是由几个通信前置来完成的。

模型总览：

清算实体通用模型：

清算指令和清算文件是多对一的关系，核对并处理过的清算指令和清算文件处理结果是多对一的关系。以上都和清算通道接口是一对一的关系、即不论文件或者指令只有一个清算通道接口。

渠道类型：

渠道类型和其中一个维度通信类型是密切相关的。

渠道类型可以这样来划分：快捷、线下、信用卡、人工、银企互联、B2B、B2C、VISA，MIGS（国际支付）、COD、代金卡等

清算的各种模式也是和渠道类型分不开的，例如：渠道类型为快捷的，统统是使用的实时接口，银企互联则采用批量数据通过接口提交的模式，而线下类型则是批量数据生成文件来进行提交的。

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

银行卡类型：

清算类型：

清算指令的状态：

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

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

• 落地为文件供结算人工下载，人工发送提交。
• 直接通过和银行交互的接口批量或者单笔发送出去。

核心的业务逻辑

1. 充值文件内清算指令总笔数=充值清算文件处理结果总笔数；
2. 充值文件内每笔清算指令金额和状态=充值清算文件处理结果内每笔清算指令金额和状态；
3. 充退文件内清算指令总笔数=充退清算文件处理结果的总笔数；
4. 充退文件内每笔清算指令金额和状态=充退清算文件处理结果内每笔清算指令金额和状态。

业务边界分析

用例总图：

清算文件处理：

充值回导文件获取。

充值回导文件有两种获取方式：

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

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

• 如上图，我们将**通过标准接口和通信前置交互获取到文件，实际保存动作由通信前置完成，保存完成后将文件路径返回给清算文件处理模块。通信前置获取到文件后，要把纯文件信息保存到数据库中。
• 在文件被解析成功后将数据导入SETTLE_BANK_RETURN表，同时将文件摘要信息保存到SETTLE_BANK_RETURN_BATCH表。
• 通信前置需要一定的缓存功能，比如：一些银行多种业务一个文件返回的，那么通信前置需要能区分出来，不要去请求银行多次。

清算文件处理

充值回导文件解析：

• 见上图，我们要把解析脚本内容保存到数据库，直接读取数据库中的内容，这样方便管理和更新。
• 每一个文件解析脚本和文件模板都需要仔细开发。

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

充值回导文件对账：

• 对账需要在导入后进行触发，可以是人工触发，也可以是系统自动触发，也可以在导入后立即系统自动触发对账。系统将提供接口供工作平台调用或者系统自己调用。
• 系统触发可以配置成一个定时执行任务，这样可以把实时要做的事情变成异步确保**做的事情，将使用到定时预约的系统功能，在定时查询中有讲这个工具。

通用的对账流程如下图：

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

清算指令处理：

指令的清算结果状态：

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

指令类状态：批量的指令有两种发送的实现模式。

• 落地为文件供结算人工下载，人工发送提交。
• 直接通过和银行交互的接口批量或者单笔发送出去。

内部服务管理：

指令处理时序图：

系统边界分析

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

• 网银异步模式包含：B2B、B2C、VISA、MIGS这些有支付机构和银行页面展示的，银行端需要用户输入账号密码进行支付的业务。
• 直连模式包含：网汇E、快捷这些通过某种协议只需要在网站确认就可以进行支付的业务。
• 其它个性化模式包含：MOTO、线下网点金融机构、信用卡还款、COD货到付款、代金卡、电话支付这些属于清算但是模型很复杂的业务。

直连模式：

网银异步模式：

本文由 @支付学院 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

给作者打赏，鼓励TA抓紧创作！

**赏

6人打赏