支付系列：清结算系统

2018-04-08

1. 概要

关于清结算，需要考虑几个因素：

• 有什么用？业务上，清结算的价值，为哪个角色、提供哪些功能？
• 如何实现？主体流程、整体架构、关键细节
• 最终交付物？谁要使用清结算系统，最终的结果产出是什么？系统、页面？

围绕清结算系统，进行深入分析，具体涵盖：

• 业务目标：明确目标，系统的价值，为哪个角色、提供什么功能？
• 系统设计：
  • 功能设计
  • 主体流程
  • 逻辑架构
• 实践：清结算系统的实践

2. 业务目标

清结算系统：

• 背景：第三方支付平台，会在 T+1 进行清分、生成对账单，供外部下载，并将结算款项，付给电商平台的账户
• 目标：
  • 支持运营，进行高效的对账工作
  • 支持财务，进行高效结算工作
• 对象：财务、运营
  • 运营：跟进对账差异，并进行人工差错处理（每天、每周）
  • 财务：周期结算、入账（月、季度）
• 业务目标：
  • 电商平台：通过对账单，与自身的支付订单对比，确认是否存在异常订单
  • 电商平台：结算金额，依赖于对账结果
• 清结算分类：
  • 内外对账（渠道对账）：公司内部的支付订单、三方支付渠道的账单之间对账。
  • 内部对账（业务对账）：公司内部的支付订单、公司内部不同业务线的交易订单对账。

几个术语，进行统一：

• 三方账单：从第三方（银行、支付宝等）下载的「对账单」
• 支付订单：实际支付流水的订单
• 交易订单：业务方面，交易订单，订单金额可能包含满减、红包抵扣等

3. 系统设计

清结算系统，具体系统设计，涵盖下述几个方面：

1. 功能设计：从业务角度，需要支持哪些业务功能、逻辑功能
2. 主体流程：业务逻辑上，主体操作流程
3. 逻辑架构：逻辑模块

领域模型：

3.1. 功能设计

清结算系统，需要支持下述几个功能：

1. 两类对账：渠道对账、业务对账
   1. 支付渠道对账：
      1. 渠道：
         1. 国内：支付宝、微信、Ping++、ApplePay
         2. 海外：Stripe、Adyen、Juspay
      2. 类别：
         1. 收款
         2. 退款
      3. 特别说明：
         1. 每个渠道，都需要区分「渠道商户」，即，渠道侧分配的「商户」
   2. 业务对账：
      1. 类别：
         1. 收款
         2. 退款
      2. 两个订单：
         1. 支付订单
         2. 交易订单
      3. 特别说明：
         1. 不同业务，是否可以共用？还是每一个业务，一个系统？
2. 统计汇总：
   1. 渠道：三方支付渠道
      1. 渠道应收
      2. 渠道应退
      3. 手续费汇总
      4. 实际应结
   2. 商户号：商户清分
   3. 业务：分业务统计

清结算系统，需要考虑的一个关键模块：差错处理

• 差错分类：按照差错产生原因，进行分类，不同类别，可以采用统一的处理措施
• 差错处理：处理差错，达到两方一致，保证款项的精准

清结算系统中，对账的差错：

• 单边账：结算双方，一方的账目发生变化，另一方没有变化
• 长短款：
  • 长款：银行存的钱多了，自己有资金沉淀，上游给的款项，比我给下游的多（不考虑分润以及跳码的情况）
    • 支付：订单金额 < 银行对账文件金额
    • 支付：订单无 + 银行对账文件有
  • 短款：银行存的钱少了，自己有资金垫付，上游给的款项，比我给下游的少（不考虑分润以及跳码的情况）
    • 支付：订单金额 > 银行对账文件金额
    • 支付：订单有 + 银行对账文件无
• 对账的差错，分为 2 类：
  • 金额的长短款
  • 单边账的长短款

清结算系统中，对账的差错处理：

• 单边账，99.9% 都是长款，如果出现短款，就是灾难，建议彻查系统日志和上下游的对账单
• 长短款：
  • 分为 2 种情况：金额的长短款、单边账的长短款
  • 金额的长短款：一般情况下，支付联机时，「支付订单的金额」和「银行回显金额（回调）」不相等时，订单支付失败，不会进入「对账环节」；如果联机时两边金额是相等的，而在T+1对账时对出金额差异，这一般就是银行的问题了。线下找银行去。
  • 单边账的长短款：
    • 短款：解决办法「挂账」
      • T+1对账时，对出有「支付订单」+无「对账文件」，一般不会立即出短款，而是先标记为「存疑」，因为有的银行会在 T+2 时提供「对账文件」。
      • 待T+2的「对账文件」来了，再把之前「存疑」的订单拿来对。（日切的临界时间问题）
      • 万一到了设定了时间点，还是订单存疑的话，那么就要确认为短款了。
    • 长款：解决办法「补单」
      • T+1对账时，对出无「支付订单」+有「对账文件」，这会立即出长款。
      • 这时候要进行「补单」的操作，所谓补单即通过「支付流水」关联全局的订单：
      • 关联到了，将「订单」的支付状态改为「支付成功」，更新银行回调时间等等；
      • 如果没关联到，确实没有订单，那么要线下找银行去处理了；
    • 长款（重复支付）：解决办法「退款」
      • 还有一种情况，「同一支付订单」，重复支付，此时，要为用户发起退款，优先退后续支付的订单
    • 其他：解决办法「登账」
      • 支付系统做的再好，也会有少量款项对不上账，此时我们进行财务会计「登账」操作；
      • 比如如果银行结算的钱多了，我们把会计科目营业外收入加上对应的多的金额；
      • 如果银行结算钱少了，我们计入财务费用；
    • Note：补单过程，本质涉及「支付」和「交易」两个方面，在另外一个地方专门分析。
• 日切：临界时间
  • 「银行的日切时间」和「支付系统的日切时间」，不一定匹配
  • 所以，T + 1 清算款中，一笔扎差过来时，通常会出现「单边账-短款」情况
  • 一般做法：标记出来短款「挂账」，等待 T+2 再次对账，或者跟银行确认

补充，几个常见术语：

• 清分：指清算的准备阶段，将当日全网的交易数据，按各成员行之间，本代他、他代本、贷记、借记、笔数、金额、轧差净额等，进行分类、整理、汇总
• 结算：指把某一时期内，「所有收支」情况进行总结、核算
• 扎差：zha cha，汉语中，可以等同，差额计算、对冲、净提。
• 日切：日期切换
  • 「银行的日切时间」和「支付系统的日切时间」，不一定匹配
  • 银行的日切时间，本质就是银行停业结账的时间
• 补单：通过「人工干预」方式，将原有业务进行下去，如通过接口人工干预订单状态
• 挂账：对于不平账单，先「挂起」，等查明后再进行相应处理
• 登账：会计记账，伴随虚拟资金从一个账户向另一个账户转移的过程（原始凭证）

3.2. 主体流程

清结算系统，分为下述几个主要流程：

• 下载账单
• 账单转换
• 启动对账
• 标记差错
• 差错处理
• 结果汇总

3.2.1. 下载账单

下载对账单：

• 一般 T+1 可以下载
• 常见方式：接口、邮件、FTP

3.2.2. 账单转换

数据规范时，下载不同渠道的对账单，建议设置为统一的命名规范，然后进行存储。

• 文件命名
• 文件存储
• 信息入库

3.2.2.1. 文件命名

上传对账单文件命名规则为：

业务类型_资金渠道_清算日期_序列号 . 文件格式（I_WEIXIN10401_20160415_02.CSV ）

具体含义：

• 业务类型：常见业务类型有入款I、出款O、退款R（撤销、退货）
• 资金渠道：同一合作方有多种产品 or 多个商户号，需区别
• 清算日期：YYYYMMDD
• 序列号：同一业务类型同一资金渠道可能有多份对账单
• 文件格式：优选CSV格式

3.2.2.2. 文件解析

对账单，文件解析：

• 每个渠道，对应一个解析规则
• 抽取：订单号、交易本金等信息

3.2.2.3. 信息入库

原始账单文件，归一化之后，抽取结构化信息，导入数据库中，便于后续的对账。

3.2.3. 启动对账

对账单数据整理规范后，进行对账时，需将对账单中订单、金额与电商平台系统订单、金额进行比对。

1. 获取支付订单：根据渠道、日期、状态，获取支付订单
2. 支付订单与对账单匹配
   1. 按照系统订单中顺序一条条与对账单记录进行匹配
   2. 匹配时先按照订单号进行匹配，再对金额进行比对
   3. 系统订单匹配完成以后，检查对账单是否存在剩余记录

3.2.4. 标记差错

对账结果：

• 已对账：对于订单号、金额一致的，记为已对账
• 金额不一致：对于订单号匹配，但金额不匹配的，记为金额不一致
• 短款：对于订单号无法匹配的，记为短款
• 长款：对于对账单中剩余记录，全部记为长款

结果输出：

• 汇总：对账无差异的，显示「对账成功」，可进行汇总确认。
• 差错处理：对账存在差异，进行展示筛选，并提供「差错处理」方式。

对账结果的差错标记：

3.2.5. 差错处理

主要是针对：「单边账-长短款」的处理，以及「金额不一致」

清结算系统中，对账的差错处理：

• 单边账，99.9% 都是长款，如果出现短款，就是灾难，建议彻查系统日志和上下游的对账单
• 长短款：
  • 分为 2 种情况：金额的长短款、单边账的长短款
  • 金额的长短款：一般情况下，支付联机时，「支付订单的金额」和「银行回显金额（回调）」不相等时，订单支付失败，不会进入「对账环节」；如果联机时两边金额是相等的，而在T+1对账时对出金额差异，这一般就是银行的问题了。线下找银行去。
  • 单边账的长短款：
    • 短款：解决办法「挂账」
      • T+1对账时，对出有「支付订单」+无「对账文件」，一般不会立即出短款，而是先标记为「存疑」，因为有的银行会在 T+2 时提供「对账文件」。
      • 待T+2的「对账文件」来了，再把之前「存疑」的订单拿来对。（日切的临界时间问题）
      • 万一到了设定了时间点，还是订单存疑的话，那么就要确认为短款了。
    • 长款：解决办法「补单」
      • T+1对账时，对出无「支付订单」+有「对账文件」，这会立即出长款。
      • 这时候要进行「补单」的操作，所谓补单即通过「支付流水」关联全局的订单：
      • 关联到了，将「订单」的支付状态改为「支付成功」，更新银行回调时间等等；
      • 如果没关联到，确实没有订单，那么要线下找银行去处理了；
    • 长款（重复支付）：解决办法「退款」
      • 还有一种情况，「同一支付订单」，重复支付，此时，要为用户发起退款，优先退后续支付的订单
    • 其他：解决办法「登账」
      • 支付系统做的再好，也会有少量款项对不上账，此时我们进行财务会计「登账」操作；
      • 比如如果银行结算的钱多了，我们把会计科目营业外收入加上对应的多的金额；
      • 如果银行结算钱少了，我们计入财务费用；
    • Note：补单过程，本质涉及「支付」和「交易」两个方面，在另外一个地方专门分析。
• 日切：临界时间
  • 「银行的日切时间」和「支付系统的日切时间」，不一定匹配
  • 所以，T + 1 清算款中，一笔扎差过来时，通常会出现「单边账-短款」情况
  • 一般做法：标记出来短款「挂账」，等待 T+2 再次对账，或者跟银行确认

3.2.6. 结果汇总

结果输出：

• 汇总：对账无差异的，显示「对账成功」，可进行汇总确认。
• 差错处理：对账存在差异，进行展示筛选，并提供「差错处理」方式。

TODO：

• 需要重点考虑一下「最终交付物」，此次加深需求的理解。

3.3. 逻辑架构

清结算系统，逻辑架构，整体分为：

1. 接口层：对外提供服务
2. 服务层：核心的对账处理流程
3. 网关层：对外下载对账单、查询单个账单的详情

对应的「技术架构」：逻辑架构

对应的「技术架构」：技术栈架构

4. 附录

4.1. 附录 A：POSP 系统

POSProxy，POS 前置系统，用于管理：

• TODO

4.2. 附录 B：POS 机

几个常见问题：

• POS 机的一清机 & 二清机

疑问：

• POS 机，直接通过 wifi or 4G 信号，连接到支付公司？还是需要商户在「本地电脑上」也安装请求转发的软件？

4.2.1. POS 机的一清机 & 二清机

一清机：

• 有支付牌照的公司（银行、银联、支付公司等），直接对接商户的机器；
• 资金清算途径：消费刷卡（款额）– 人行清算中心（清算分配）– 收款账户（到账）
• 典型特点：
  • 到账时间：中国银联标准到账模式，T+1，次日到账，周末、假日，会顺延

二清机：

• 拥有 POS 机的商户，申请多份机器，再卖给「其他商户」，一清商户作为中转，再进行一次清算；
• 资金清算途径：消费刷卡（款额）– 人行清算中心（清算分配） – 第三方账户 – 收款账户（到账）
• 典型特点：
  • 到账时间：T+0，当日到账，一般是第三方公司垫资。

疑问：

• 多次清算，有什么影响吗？费用
• 为什么有人做二清机？

5. 参考资料

• https://credit.u51.com/post/179474.html POS 机的一清机和二清机
• https://blog.csdn.net/qq827245563/article/details/78479361 银行卡收单__对账_长短款差错处理
• https://www.zhihu.com/question/20702621

原文地址：https://ningg.top/fin-tech-01-clearing-and-settlement-sys/