如何设计一套支付系统—清算模块
清算对于商户来说是最刚性的需求，并对其容忍度最低，支付等待时间长和操作繁琐商户可能还能容忍。
但出现结算错误和长时间延迟清算，商户认为资金的安全性得不到保障，商户基本上在有其他选择的情况下会毫不犹豫的改换其他支付产品。
我们常说的清算其实是由清分和结算是2个环节组成的，类似于会记中的财务和出纳的关系，财务负责算清账款，出纳则负责转账。
清分是指清分模块按照业务规则计算各个账户的收支账目，最后生成有收支方和金额的清分记录；结算是指将清分记录以清分文件的形式或调用接口的形式推送到核心结算系统转账扣款。
清算模块可谓是支付系统中含金量最高的业务模块之一，要求既能支撑丰富的业务场景又要保障精准的清分算法，信息交互的监控粒度要求非常细致。
相比较交易订单的中转透传，清算的每一个金额数字和状态，都是真实的涉及到资金的划拨，所以状态监控和人工介入审核的环节必不可少。
清算从业人员需要一定的行业知识和专业储备，笔者总结了自身业务知识和项目经验，希望能帮助读者能有结构的快速入门。
本文会先从实际生活常见的场景举例，介绍信息流、资金流的流经的每一个环节，中国清算系统概况，从而充分理解清算业务的基本业务知识。
接着会以银行收单系统为例解构清分模块的几个核心业务能力如何实现，并抽象出行业内常用的基本设计理念。
对账清算不分家，业务上一定是对账平账了才会执行清分，对账模块的详细设计可以查看笔者上篇文章《如何设计一套支付系统—对账模块》，本文不做重点说明。
清结算专员：负责发起清分的操作者，首先确保信息流对平，然后确认资金流应收款和信息流平账账单金额一致。希望能及时发现长短款问题，并解决，保障资金清算给商户（平台可收款用户）的时效性。
一、一笔交易的生命线
消费者使用任意一种非现金支付渠道（微信、支付宝、刷卡）支付的商品货款，商户并非实时收到销售货款，而是按照一定的结算周期，由其使用的支付收单服务商清算给到商家，收单服务商可以是银行、银联、和第三方支付机构。
举个栗子：小明使用支付宝付款码（绑定建行卡）在沃尔玛购买了1000元钱的商品，沃尔玛的支付服务商是工行的收单通道，支付费率为0.6%。
1. 信息流
间联模式下：
- 商家收银系统客户端->商家收银系统服务端：生成商户订单号、金额、状态：未支付（业务场景复杂的商户系统还会区分业务订单号和支付订单号，本文仅说明支付订单号）；
- 商家收银系统服务端->工行收单服务端：支付路由找到工行收单通道，上送商户订单号、金额、状态：未支付；
- 工行收单服务端->银联间联服务端：支付路由找到银联支付宝通道，上送工行订单号、金额、状态：未支付；
- 银联间联服务端->支付宝服务端：支付路由找到间联支付宝通道，透传工行订单号、金额、状态：未支付；
- 支付宝服务端->银联快捷支付系统：支付路由找到银联快捷支付，上送支付宝订单号、金额、开卡行、银行卡号、状态：未支付；
- 银联快捷支付系统->建行发卡网关：支付路由找到建行发卡网关，上送银联代扣订单号、金额、开卡行、银行卡号、状态：未支付；
- 建行发卡网关：根据银行卡号、金额内部划账（此时只是发卡行内账簿记录不涉及资金结算），若银行卡余额大于等于则执行划账，状态：支付成功；若余额不足，则不执行划账；
- 建行发卡网关->银联快捷支付系统：以扣款成功为例，返回：建行代扣订单号、银联代扣订单号、金额、开卡行、银行卡号、状态：支付成功；
- 银联快捷支付系统->支付宝服务端：返回：银联代扣订单号、支付宝订单号、金额、开卡行、银行卡号、状态：支付成功；
- 支付宝服务端->银联间联服务端:支付宝订单号、工行订单号、金额、状态：支付成功（同步推送小明的支付宝APP）；
- 银联间联服务端->工行收单服务端：支付宝订单号、工行订单号、金额、状态：支付成功；
- 工行收单服务端->商家收银系统服务端：工行订单号、支付宝订单号、商家订单号、金额、状态：支付成功；
- 商家收银系统服务端->商家收银系统客户端：工行订单号、支付宝订单号、商家订单号、金额、状态：支付成功。
2. 资金流
间联模式下：
- 建行行内清算系统轧差：建行收到扣款通知时，小明的银行账户余额实时减少1000元。
- 银联跨行清算系统轧差：晚上12点日切，银联生成清分文件上送人行大小额系统：中行扣除其发卡所得资金（比如是千1）清算账户减少999元，支付宝清分账户增加1元，工行清算账户增加998元。
- 收单行行内清算系统轧差：次日10点，工行生成清分文件上送人行大小额系统，商户结算账户增加994元，商户所属展业渠道结算账户增加4元。
二、中国清算系统简述
中国国内基本上所有的跨行转账的最底层都是走的人行大小额系统，是国家级的核心系统，接入资质要求和安全性要求都比较高，一般只对银行和特许金融机构（例如：银联）开放。
银行的清算系统首先会按照本行卡、他行卡进行归类，本行卡转入本行行卡账户结算系统；他行卡则按照金额大小归类，大于5w的走人行大额支付系统，小于等于5w的走人行小额支付系统。
一般三方或四方能接触到的结算系统，是银联银行卡跨行支付系统，以银行卡卡组织的业务形式处理银行卡清算业务，本质上基于人行大小额系统的一层封装，其对外开放性更强，业务灵活性更高。
大额支付系统（HVPS）在国家法定工作日运行，系统运行时间是每日的8：30到17：00，主要用于处理单笔金额在5万元以上跨行普通汇兑或5万元以下的跨行紧急汇兑业务。
大额系统实行对支付指令逐笔发起、全额清算的方式，加快了大额资金汇划到账的速度及社会资金的周转。
小额支付系统（BEPS）：实行7×24小时不间断运行的模式，主要用于处理单笔5万元以下的普通贷记业务和定期扣划业务。
与大额支付系统相比，小额支付系统采取了批量发送业务、定时清算轧差的业务处理方式，故其资金划拨的实时性没有大额支付系统高。
三、案例：银行收单系统清算设计
1. 搭建资金账户体系
在开始梳理清算需求的时，一定是要明确资金流向，在满足业务需求的诉求上，首先要确保符合国家相关要求，其次要符合企业财务企划管理办法。一般常用的账户类型如下：
1）备付金账户
指接入通道时填写的结算账户，需独立申请报备。此账户的主要用途是，归集收单业务来款方资金。
上游微信、支付宝、银联，是相互独立的业务系统其来款时间、对账单推送时间均不相同，所以会再按类型区分微信、支付宝、银联备付金账户，这样专户专用便于直观的处理资金对账。
2）过渡户
指先汇集各个备付金账户的来还款，再合并资金一笔结算给到商户和渠道的资金过渡账户。每天过渡户需清零，如果有清分失败的挂账，则需划拨至挂账户。
这样即便是系统上的清分指令重复调用出现bug，在业务上因余额不足的原因无法划款，从而规避大规模的资金损失。且根据账簿流水账户余额是否清零，也可快速精准定位到具体是哪一天系统出现问题。
3）挂账户
因结算卡错误和风控冻结原因出现的挂账资金统一归集到挂账户，每天需清分专员发起清分并回盘后，核查系统显示的清分失败金额和过渡户余额是否一致（结算退票会按照资金出款方向原路返回指过渡户）若一致发起挂账户清分，将过渡户清零。
4）商户银行账户
商户进件是填写的结算账户，除了一类卡、部分银行本行卡还支持二、三类卡。
5）外包渠道银行账户
外包渠道进件时填写的结算账户。区别于分行机构内部账户，生成清分文件时多和商户清分信息归档至一份清分文件中。
6）分行机构内部账户
分行渠道进件时填写的结算账户，属于银行内部科目管理账户，除账户编号外一般还需填写科目编号。部分银行使用接口内部划账；部分银行仅做账簿记录，实际填写账户时填写总行账户。
2. 划分清分类型
按照收款方向划分作为清分类型，可以归类为：过渡户清分、挂账户清分、商户清分 、渠道清分。
过渡户清分、挂账户清分账户一般固定不变，商户清分、渠道清分结算账户则在生成清分文件时根据业务规则关联添加。
3. 明确资金流向
假设：商户费率为6‰，外包渠道渠道费率4‰，分行机构渠道费率2‰，通道成本为2‰：
- 商户应收款=3000-3000*6‰=2982元
- 外包渠道应收款=3000*（6‰-4‰）=6元
- 分行机构渠道应收款=3000*（4‰-2‰）=6元
4. 处理挂账补清分
挂账：清分失败后资金会原路退还至过渡户；经由清分专员核查过渡户越和失败金额一致后，操作挂账户清分划款。
补清分：指错误信息修改后，再次发起清分。清分类型不做改变，清分状态由清分失败转化为清分中，出款账户改为挂账户，收款账户取商户当前最新结算信息。
5. 生成清分文件规则
- 获取对账结果数据对账任务执行完毕，拉取一份已对平的订单数据，生成一份原始清分数据；
- 生成商户清分记录逐笔订单匹配其所属商户的当前费率，并计算商户手续费=订单金额*商户费率；
- 生成渠道清分记录逐笔计算机构分润，以平台兜底为例，按照机构级别从下往上计算，渠道分润=订单金额*（商户费率-渠道费率）；
- 是否冻结判断是否有冻结订单，若有将冻结订单剔除。（冻结订单一般来自第三方风控或平台风控，商户资金存在违规风险或消费者争议）；
- 是否解冻判断是否有解冻订单，若有将解冻订单合入清分数据。（冻结订单一般来自第三方风控或平台风控，商户资金存在违规风险或消费者争议）；
- 是否分账判断商户是否需要分账，按照分账规则计算分账金额和分账商户信息；
- 生成清分明细添加结算信息，根据商户号信息，查找匹配的结算信息（卡号、姓名等），生成清分明细；
- 是否合并入账判断是否需要合并入驻，常用的有2种，一种为商户维度，根据商户号合并生成结算金额；另一种为连锁商户维度，将该连锁商户下所有门店合并生成结算金额；
- 生成清分文件。
清分文件是推送给银行清算核心或代付接口的数据（txt、csv、json格式都有），具体以合作平台要求为准。
6. 清分文件推送批次统计
生成清分文件后，点击清分推送清分文件给到对应的业务系统，需提前确认推送路径和文件格式。
不同的银行管理办法可能不同，有的会要求区分本行卡和他行卡生成2份清分文件。有的会区账户类型，若是行内内部账户划款走指定的接口划款，实时返回清分结果；若是外部账户则采用文件推送的方式，批量清分。
常用记录信息：交易时间、清分文件名称、清分批次号、总金额、总笔数、推送时间、批次号、推送批次状态。
7. 清分结果统计
每笔转款记录需逐笔记录清分明细，便于后续对账和处理补清分操作。
常用记录信息：交易时间、清分状态、清分类型、平台账号信息、出款账户信息、收款账户信息，金额，清分时间，流水号，失败原因。
8. 清分结果统计
差错处理，指的是处理那些还没有清分成功的清分记录，主旨在于使挂账户余额清零。差错处理可以分为两大类，一类是正常补清分，一类是异常情况。
正常补清分是指，回盘时结算系统明确指出哪一笔清分失败，用户按照正常流程修改后，重新补发清分即可。
另一类异常情况，又可以细分为2种场景，退票和线下手补：
- 退票是指回盘时结算系统并没有指出清分失败，但实际情况清分失败了，且资金已经退还至出款账户，需要根据退票原因修改后再次发起清分。出现这种情况多是因为行内核心结算系统返回的结果状态仅代表信息接收状态，不是实际结算状态，其还存在上级结算系统——例如人行大小额系统，所以他行卡退票最为多见。
- 线下手补是指因系统调整的时效性过长，业务上又急需结算给到商户，可以先线下通过手工转账的形式结算给商户，信息流状态稍晚一点同步。线下行为没有经过平台系统，需将清分失败转为清分成功，保证信息流和资金流的统一，避免重复清分。
9. 清算模块产品框架图
下图为清算模块的产品框架，基本上清算设计都是以此为出发点，大家可以作学习参考。
四、如何做好清算产品工作
首先当然是要了解业务：
- 钱是哪里来的？
- 什么时候分钱？
- 谁来操作分钱？
- 分钱的依据是什么？
- 出现长短款了，如何定位上下游哪个环节出了问题？问题由如何解决？
可以从资金流和信息流的流程图开始，一步步理清，资金流的账户设计多和公司务企划部门沟通明确账户设计的用途和处理规范，对业务背景深刻理解后会发现其实账户设计和表结构设计类似。
产研侧建议多用实际的业务金额举例，最好能直接拿着例子做测试用例那样详细，一则便于沟通，二则便于自身检测模型是否有遗漏。
本文作者 @Jamie Gao 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
