支付清算系统
清结算系统是支付系统的一个子系统，本文重点介绍清结算中的系统设计和与对账系统的关系。
清结算系统是第三方支付系统按照与商户的协议，将一个结算周期内的收付款项汇总轧差生成待结算金额，并将待结算金额结算给商户的一个功能模块，是支付系统的一个子系统。
第三方支付系统的清结算系统并不是与人行的支付清算体系处在同一层级的系统，简单来说，后者担任着完成银行与银行之间的资金清算，而前者仅仅服务于一个第三方支付系统，完成对第三方支付系统的商户的资金结算。
大家想必注意到了清算和结算用词的差异，清算是各清算中心的工作内容，包括清分和资金划拨两个步骤，清分用于登记流水和轧差汇总，资金划拨则是在各个银行之间进行资金调动，即该扣哪个银行多少资金就扣掉，该付给哪个银行多少资金就给它增加余额；结算是指银行按照结算周期对其直连商户的资金核算了结。
第三方支付系统的清结算系统，虽然包含清结算三个字，但“清”仅仅只是清分，没有清算中心那样进行资金划拨的权利，结算倒是名符其实的结算，与银行对其直连商户的结算概念等同。
清结算系统的实现
正如在《支付路由的管理与设计》一文中提到的，后台服务型系统的设计一般都逃不过三个范围：业务流程、管理页面、接口，支付路由如是，清结算系统也如是。
只不过，相较于支付路由（业务流程一般分布在来自管理页面的配置和接口的调用当中，不存在自动化的业务处理），清结算系统的业务流程存在自动化的业务处理逻辑，且清结算系统不一定能说是纯后台服务型系统，因为它需要提供给商户后台查看结算单信息以及进行对账单下载的能力（这两点一般只是查询下载功能，故下面的部分不会讲述商户后台的部分）。
1. 清结算的管理页面功能
清结算的管理页面主要包含商户结算信息的管理、清分明细管理和结算单管理三部分。
商户的结算信息是在商户入驻支付平台的时候通过协议合同确定的，协议中包含如下用于结算的关键信息：
结算周期：可以是D0，D1，也可以是T1，T2……Tn（D代表自然日，T代表工作日），D0一般是设置某些个时间段结算一次，比如可以设置0点到15点的交易在15点之后结算一次，15点到24点的交易在24点之后结算一次；
结算方式：分为结算到商户的银行账户，还是商户支付平台内的可用余额账户；
银行账户信息：包括银行账户名、联行行号、银行账号。
如上，商户结算信息管理功能中的结算信息基本上都是在商户入驻的时候登记进去的，但是要在这个功能里进行后期的维护，如更换结算周期，修改结算方式，更换银行账户信息，修改结算信息的有效性……
清分明细管理是对成功消费的订单生成的清分明细的管理，之所以称之为明细，是因为这条记录中会包含交易金额、商户手续费，甚至可能会有渠道成本、代理商分润金额等信息，清晰的表明了各部分金额的归属。
清分明细管理的数据来源于订单系统在一笔消费订单成功之后，对清结算接口的调用（当然其中也可能会要求退款也要产生清分明细，这个时候就要看退款是从哪个账户退，从可用余额账户退，可以考虑不登记，也可以登记但不计入结算，从待结算账户退，就要登记并参与结算）。
结算单管理即是对商户的结算管理，结算单是一种外在表现形式，其记录了商户一个结算周期内的所有清分记录的汇总轧差的结果。
结算单的生成是由系统依据商户的结算周期设置自动汇总清分记录而成。
2. 清结算的接口
清结算的接口是与其他系统交互的入口，一笔交易的最后一步，即是调用清结算接口登记一条清分记录，用于一个结算周期之后对商户进行结算。
清结算接口的设计一般要包含商户编号、交易金额、商户手续费、渠道成本等参数字段，如果要求代理商的分润信息添加进来，则也要增加相应的代理商户编号、代理商分润金额等参数（描述的参数基于这些费用成本数值都是在订单系统完成的计算，如果要求清结算系统内自行计算，则要上传相应的费率，或者在清结算系统调用费用中心获取相应的商户费率、代理商扣率等费率数据）。
注意：订单系统调用清结算系统登记清分记录，也可能会出现异常，导致清分记录没有登记成功，这个时候，要么在订单系统设置相应的机制保证一定要清结算系统登记成功方才停止请求，要么就要进行两个子系统的对账，对不上的记录要自动补登记，并且要在两个系统流水一致的情况下，才能进行结算操作。
3. 清结算的自动化业务流程
清结算的自动化业务流程分为三步：自动生成结算单、自动结算、自动生成对账单。
自动生成对账单，即是一开始讲到的，按照第三方支付系统按照与商户的协议，将一个结算周期内的收付款项汇总轧差生成待结算金额，形成一条结算单数据。
自动结算，即是按照设定的结算方式，在生成结算单之后，或者指定某个具体的时间点，自动将结算单中的金额结算给商户的银行账户或者支付平台账户，但是结算之前，需要进行记账操作，如下：
结算到银行账户：
借：应付账款-商户-待结算账户 XXX元
贷：银行存款 XXX元
结算到支付平台账户：
借：应付账款-商户-待结算账户 XXX元
贷：应付账款-商户-余额账户 XXX元
注意：
可以没有自动结算这个功能，由人工在管理页面操作结算；
结算到银行账户，也可以分成两步，先结算到支付平台账户，再自动帮助商户提现到银行账户，这个逻辑可以在代付渠道不能使用的情况下，将资金结算到商户的支付平台账户，对其可见，不过，是否要按照应急状况进行这种逻辑的设定要看业务方的考虑，如果机制完善，也可以不采用这种方式，毕竟对于资金问题，过于自动化可能并不让人放心。
自动生成对账单，即是在对商户结算之后，提供商户核对结算金额是否正确的依据，而对账单生成的依据则是清分明细。
生成对账单之后的一个问题就是怎么让商户获取到对账单，一般有如下几种方式：
在商户后台提供下载入口；
提供获取对账单的接口，由商户进行系统对接；
将对账单放到支付机构的FTP/SFTP上，允许商户访问获取；
将对账单推送到商户的FTP/SFTP上
……
方法多多，可以视具体需要确定提供哪些方式。
清结算系统完成对商户的结算之后，要将这个结算周期的清分记录生成一个对账文件（商户对账单），供商户对账使用。
可能有人认为提供商户对账单供商户对账应该放在对账系统，但由于商户对账单的生成要依据清分记录，所以商户对账单的生成是在清结算系统。
与对账系统的关联
清结算系统与对账系统产生关联，主要是考虑要不要在跟渠道对账结束之后，再将资金结算给商户的问题，涉及下面两种情形：
如果是先对账，再结算，则是以渠道的流水记录为准，核对了流水之后再进行结算；
如果是不管对账结果，直接结算，则是以支付系统的流水记录为准进行结算；
然而，渠道对账单里的流水可能只是用户充值到支付平台账户，并不需要结算给哪个商户，而结算给商户的资金也不一定是发生了银行卡支付，像余额支付（对于支付宝，还有花呗支付等）这种，支付记录不需要与渠道对账，但是也要结算给商户。
个人认为，没有必要增加业务耦合度，让清结算系统与对账系统纠缠不清，渠道不会少结算给支付机构，支付机构也不会少结算给商户，不需要为了一点特殊的差异，而复杂化业务流程，分别保证支付机构与渠道、商户与支付机构之间不存在对账差错即可。
题图来自Unsplash，基于CC0协议。
相关阅读
0×00 简述 沙盒(Sanbox) 是一种将未知、不可信的软件隔离执行的安全机制。恶意软件分析沙盒一般用来将不可信软件放在隔离环境
BF算法BF（Brute Force)算法也就是传说中的“笨办法”，是一个暴力/蛮力算法。设串S和P的长度分别为m,n，则它在最坏情况下的时间复杂度
前言： 在sql语句查询中，有时候，我们可以通过like模糊查询来判断是否存在某个数据，但是，当我们要确定某个字符串第一次出现的位置时，lik
定义和使用oncontextmenu 事件在元素中用户右击鼠标时触发并打开上下文菜单。注意：所有浏览器都支持 oncontextmenu 事件， contextm
文章目录概述建立连接下载上传错误机制代码实现实验环境实验过程延伸概述 TFTP，全称是 Trivial File Transfer Protocol（简单文件传