可以说,对账是支付系统最头疼的事情。每一笔交易,都要做到冤有头债有主


对电商系统来说,每一笔交易,在所有相关主体侧都要能对得上

  • 交易主体侧,如果发起人是个人,必须能够从个人交易历史记录中找到这笔交易。但一般来说,个人不会保留电子记录,所以一般是提供可以下载的账单或交易记录,让用户自己对去
  • 交易对手侧,一般是商户。商户侧对账处理同用户侧,一般也仅提供对账单
  • 交易渠道侧,这是对账的重点,一是核实交易流水,二是几圈交易佣金,毕竟是租用人家通道做结算的

对账处理流程

一般来说,对账流程涉及到如下步骤:渠道对账单下载、本地交易记录准备、轧账、平账

渠道对账单下载

银行,第三方支付,银联等,一般都会提供对账单下载的功能。不过也有少数工作做不到位或者太到位的银行,只提供账单查询后台,不提供对账单下载功能。对开发人员来说,这里有几个坑:

  • 对账单格式不一。文本,XMLcvs的都有。为了后续能够统一处理,在账单下载完成后,需要进行标准化处理
  • 下载方式不一,HTTPHTTPSFTP的,都有。下载程序需要按照渠道的协议来处理
  • 下载时间不一,一般是凌晨1点后,到中午12才能用的也有。如果在预定的时间取不到数据,需要注意重试读取
  • 稳定性差。FTP服务器出问题那是常有的事。渠道侧解决方案往往就是重启。所以重试机制是必要的

支付系统的对账设计-烽言

渠道对账单标准化

由于每个渠道的账单格式都不尽相同,在得到账单后,下一步是对账单做标准化处理,这样轧帐以及后续工作就可以统一处理了。标准化后的账单数据可以放在文件系统或者数据库中。这取决于交易数据量。每天百万以上的量,还是使用文件系统,比较合适。数据库操作相对比较慢,也浪费资源。基于文件系统的标准化涉及如下内容:

  • 文件格式标准化统一使用cvs或者json或者xml格式。如果是使用hadoop或者spark来对账,使用cvs是个不错的选择
  • 文件存储统一化文件目录,文件名都需要遵循统一命名规范

当然,为了加快处理速度,使用hdfs作为文件系统,有利于后续的对账

本地交易记录准备

本地交易记录的准备,总的来说有如下方法:

  • 啥都不做,直接用原始数据。鉴于大部分系统使用的是mysql,这也意味着在MySQL上做对账。对账时需要大量的数据查找工作,必然会影响线上业务。在数据规模较大,比如超过100万时,就不太合适了
  • 当然,还有一个选择是使用备库来执行对账,这样既简单,也不影响线上业务。这是典型的空间换时间的做法
  • 如果业务大到需要分表分库才能处理,那对账数据准备也不一样。使用分库也不现实,因为分库一般是按照主体id,而不是渠道id,来分库,这样对账就需要在多个库上进行,效率反而降低了。而对分表分库建立从库也非常耗费资源。这种情况下,需要同步一份数据到(hdfs)文件系统中,或者NOSQL数据库上

轧帐

我们推荐采用mapreduce来轧帐,这有个优势,可以按照订单号将渠道提供的记录和本地记录shuffle到同一个reduce处理上,这样就可以很容易进行数据比对。轧帐中最大的坑,莫过于切分点的问题。比如以整0点为切分点,那存在一个问题,本地23:59发起的交易,到了渠道侧,可能会在00:01处理,这一笔交易变成第二天的帐了。实际处理中,一笔交易在渠道侧处理,花上几分钟都有可能。对于切分点附近无法确认的帐,做一个时间窗,在时间窗内的数据,留待第二天对账时继续处理。

平帐

发现两边不一致的数据,那应该如何处理?数据量不大时,记录起来,人工甄别就行。但如果数据量很大,每天上千条,人工处理就成本太高了。但这个没有统一的处理方法,需要根据有问题的数据,做个分析,然后做自动处理。

总之,对账工作,即复杂也不复杂。需要细心,对业务要有深入的了解,并选择合适的架构。


​​​​