深度解析:什么是清算核心?

15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

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

系统业务流程分析

  • 第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人打赏
评论
欢迎留言讨论~!
  1. 有质量的文章,继续赞赏。希望还能看到更多有干货成体系的文章

    回复
    1. ;-) 多谢支持

      回复