聊聊对帐系统的设计方案

前言

对帐系统做为支付系统中的基石系统,处于整个支付环节中的最后一层，主要用来保证我方支付数据与第三方支付渠道或银行的数据一致性。

在没有对帐系统以前，财务在第二日手工核对前一日的应收与实收。假若不一致，这就须要一一核对数据，找出不一致的数据。对帐系统出现以后，就可减小以这种繁琐手工操做，财务只须要天天关注系统的对帐记录，释放了生产力。

本文主要结合实际的项目经验，聊聊对帐系统的设计方案。

系统总体设计

对帐系统设计主要分为如下四个模块：

• 渠道数据处理模块
• 数据处理模块
• 核对模块
• 差别数据处理模块

模块调用顺序层次图以下。

下面先来介绍渠道数据处理模块。

渠道数据处理模块

这个模块主要负责渠道对帐文件的下载，解析，以及数据落库。

目前市面上第三方支付渠道对帐文件下载方式主要分为如下几类：

• 第三方渠道定时推送到 SFTP/FTP。这种模式比较简单，咱们定时从 SFTP/FTP 取对帐文件。
• 调用第三方渠道对帐文件下载接口。这种模式须要对接渠道下载对帐文件接口，定时调用下载。支付宝与微信为该模式。
• 手动在支付渠道网站下载对帐文件。这种模式最不友好，须要咱们花费人力下载文件。

除了下载方式，对帐文件的格式也会存在一些区别。好比支付宝对帐文件格式为 csv，而微信的对帐文件格式为 txt，另外有些渠道为 xml,xls。

第三方渠道对帐文件里面字段数量以及字段名称也存在不一样。

通常这一层每接入一个渠道须要专门根据这个渠道特性开发。这一层能够抽象化接口，对外暴露下载与解析接口。每次接入渠道，实现该接口相应方法便可。

这一层开发难度不大，只要根据对帐文件格式相应解析文件便可。通常须要提取对帐文件里面信息以下：

商户号
商户订单号
渠道流水号
交易日期
交易金额
手续费
退款原订单号
复制代码

下面说一下开发这一层须要注意的一些细节。

一、同一渠道若申请了多个商户号。这种状况下，每一个商户号若前一日都存在交易，第三方渠道会为每一个商户号都会产生一份对帐文件。因此这里系统设计时候须要考虑到多份对帐文件处理的状况。 二、对帐文件须要考虑重复下载的状况。通常状况下，渠道的对帐文件一旦生成，就不会改变。可是第三方渠道也可能发生异常，致使我方收到对帐文件数据不完整。这种状况下，须要有机制从新下载解析入库。 三、每一个第三方渠道下载文件时间都不同。

数据处理模块

讲完对帐文件处理模块，咱们来看数据处理模块。

这个模块主要用来提取我方前一日全部支付成功的流水数据以及上一模块入库的前一日对帐单的流水数据。为了减小数据库的压力，提取的数据只须要包括必要字段便可，无需将整行数据信息都提取出来。通常来讲只要须要提取交易时间，金额，交易订单号，渠道返回流水号。

这一层主要就是数据库的查询行为。最好使用备库进行数据查询。由于这里咱们须要提取前一日全量的支付成功的数据，数据量大的状况下，可能会拖慢主库，影响在线的支付交易。

核对模块

这一个模块咱们使用上一模块提取出来的数据，核对订单号与金额是否彻底一致。核对模块伪代码以下。

这个过程可能产生三类差别数据。

第一种状况为本端数据存在，对端数据不存在，咱们称为本端多帐。

第二种状况为对端数据存在，本端数据不存在，咱们称为对端多帐。

第三种状况为金额不一致。

三者如图所示。

这里产生的差别数据存入一张差别表中，以便下个模块使用。

差别数据处理模块

这个模块主要用来处理上个模块产生的差别数据。

上面三类差别数据中，金额不一致至关少见，这种状况须要人工判断。

咱们先讨论本端多帐的状况。

本端多帐是对帐系统最多见的一种状况。这种状况可能因为交易的时候发生日切问题，致使双方记帐日期不一致,从而发生不平帐。

咱们先解释日切的概念。

日切，通俗的来讲就是更换系统记帐的时间，系统从当前工做日切换到下一工做日。这个过程当中，若我方的交易订单恰好发生在 T 日 23:59:59，那么我方的记帐时间为 T 日。第三方渠道接收到订单的时间为 T+1 日 00:00:01，这样第三方渠道该笔的交易的对帐日期为 T+1 日。

第三方渠道 T 日对帐文件将缺乏这笔，可是我方 T 日数据却存在这笔，这就致使了核对过程当中产生一笔本端多帐差别数据。

对于这类差别数据，咱们能够选择将这笔数据挂帐，等待 T+1 工做日对帐。T+1 日对帐的时候，对帐单会相应多出数据，这样在核对过程就会产生对端多帐的差别数据。

而后在 T+1 日差别处理模块将前几日差别数据都提取出来，逐笔核对本端多帐数据与对端多帐数据。若核对一致，将两笔差别状态都更新成处理完成。最后若无剩余差别数据，当天帐单平帐。

伪代码以下：

对端多帐的产生状况可能可能有两种状况.

第一种状况测试环境与生产环境共用一份第三方渠道参数，这就致使测试环境交易订单也会出如今对帐单中。如果这种状况，咱们确认测试环境存在这批数据以后，咱们忽略这批差别数据便可。

第二种状况，本端交易订单存在，可是状态不是成功状态。这种状况下，须要调用第三方渠道提供的查询接口，查询订单最终状态。若查询成功，更新订单状态，而后将差别数据状态更改成处理成功。

若第三方渠道没法查询到订单的状态。这种若与渠道确认订单最终支付成功，咱们须要将支付订单改成支付成功，并修改差别帐的状态。

最后咱们再次从新对帐，因为对端多帐的数据会有对应的本端数据，将不会产生差别数据，此次对帐完成且平帐。

系统优化

目前系统的对帐系统定时任务采用 Spring 定时功能。后期优化准备接入 elasticjob 这种分布式定时调度程序，能够作到快速修改定时任务的时间，而无需重启程序。以及能够快速触发定时任务。

总之，对帐系统工做不难，就是细节比较繁琐，前期很难将全部细节都考虑彻底，这个过程须要咱们不断改进。

推荐阅读

支付对帐系统怎么设计？

我们聊聊对帐系统该如何设计

凤凰老熊-对帐处理

---

若是以为好的话，请帮做者点个赞呗~ 谢谢

喜欢本文的读者们，欢迎长按关注订阅号程序通事~让我与你分享程序那些事。