Keywords: reconciliation, billing, reconciliation, transaction record, refund record
Reconciliation is the biggest headache for payment systems. For each transaction, the records of each participant must be consistent with no deviation. The job of the reconciliation system is to find discrepancies in the records, that is, accounting; and then resolve these discrepancies manually or automatically, that is, reconciling; for the e-commerce system, each transaction is on the side of all relevant entities. Must be able to match:
- The transaction subject, if the originator is an individual, must be able to locate the transaction from the individual transaction history. However, most people do not keep electronic records, so they generally provide downloadable bills or transaction records for users to check by themselves.
- The counterparty is usually a merchant. The reconciliation processing on the merchant side is the same as that on the user side, and only reconciliation is provided.
- On the transaction channel side, this is the focus of reconciliation. One is to verify the transaction flow, and the other is to verify the transaction commission. After all, the settlement is done by renting a channel.
What records need to be reconciled? At present, there are mainly two: one is the transaction record; the other is the refund record.
Reconciliation process
Generally speaking, the reconciliation process involves the following steps: channel statement download, local transaction record preparation, account reconciliation, and account reconciliation.
Channel Statement Download
Banks, third-party payment, UnionPay, etc., will basically provide the function of downloading statements. However, there are also a small number of banks that do not do enough work or do it too well, only provide the bill query background, and do not provide the function of downloading the statement. For developers, there are several pitfalls:
Statement formats vary. Text, XML, csv are available. For subsequent unified processing, standardization processing is required after the bill is downloaded.
There are different download methods, including HTTP, HTTPS, and FTP. Downloaders need to be handled in accordance with the channel's protocol.
The download time varies, generally after 1:00 in the morning, and some can only be used until 12 noon. If the data cannot be obtained at the predetermined time, you need to pay attention to retry the read.
Poor stability. Problems with FTP servers are common. The channel-side solution is often a reboot. So a retry mechanism is necessary.
Take a look at the statement of the third-party payment:
| channel | reconciliation cycle | Billing method | bill file format |
|---|---|---|---|
| Alipay | 2:10 every day | HTTPS | XML |
| Alipay refund | 3:10 every day | HTTPS | XML |
| Baifubao | 7:00 every day | FTP | TXT |
| Paypal refund | 7:00 every day | FTP | TXT |
| WeChat Pay | 10:30 every day | HTTPS | TXT |
| WeChat refund | 10:30 every day | HTTPS | TXT |
技术选型上，HTTP(S)用apache httpclient即可实现链接池和断点续传， FTP也可以使用Apache Commons Net API。 但不管是哪一个，都需要设置重试次数和链接超时间。重试次数和间隔的设置需要小心，重试太频繁，容易把服务器打死.；时间间隔太大，又会阻塞后续处理步骤。5～10分钟是一个合适的重试间隔区间。
链接超时指在服务器出现问题时，连接在指定时间内获取不到数据即自动断开。这个很容易被忽略。我们有一次系统出问题，是渠道侧的FTP假死后重启，导致我们的客户端挂住，一直在等待重新链接。
渠道对账单标准化
找个例子大家看看， 比如微信的对账单，他是csv格式的，包括如下信息：
交易时间：这是在微信侧的支付完成的时间。 这个时间会成为一个陷阱。
公众账号ID，商户号,子商户号,设备号： 这些信息需要做验证，确保是自己的单子，不要让微信把老王家的单子也给发过来了；
微信订单号,商户订单号： 这两个是对单的核心。前者是微信侧产生的订单号，在微信支付接口返回值中有。但是万一收不到这个返回值，那在本地记录中可能就空了。 后者是我们发送给微信的订单号，一般用这个来做对单依据。两边的数据中都会有这个值。
用户标识,交易类型,交易状态,付款银行,货币种类,总金额,企业红包金额： 这几个就是对单的核心字段，必须确保双方是一致的。
商品名称,商户数据包,手续费,费率：这些是可选验证。
而某宝的对账单，是文本格式的，用空格隔开。他们家的就简单很多，只有商户订单号，交易流水号，交易时间，支付时间，付款方，交易金额，交易类型，交易状态这些字段。 
由于每个渠道的账单格式都不尽相同， 在得到账单后，下一步是对账单做标准化处理，这样轧帐以及后续工作就可以统一处理了。 标准化后的账单数据可以放在文件系统或者数据库中。这取决于交易数据量。每天百万以上的量，还是使用文件系统，比较合适。数据库操作相对比较慢，也浪费资源。 基于文件系统的标准化涉及如下内容:
文件格式标准化统一使用csv或者json或者xml格式。如果是使用hadoop或者spark来对账，使用csv是个不错的选择。
文件存储统一化文件目录，文件名都需要遵循统一命名规范。
为了加快处理速度，我们使用hdfs作为文件系统，有利于后续的对账的处理。
本地交易记录准备
本地交易记录的准备，总的来说有如下方法: - 啥都不做，直接用原始数据。鉴于大部分系统使用的是mysql，这也意味着在MySQL上做对账。对账时需要大量的数据查找工作，必然会影响线上业务。在数据规模较大，比如超过100万时，就不太合适了。
当然，还有一个选择是使用备库来执行对账，这样既简单，也不影响线上业务。这是典型的空间换时间的做法。
如果业务大到需要分表分库才能处理，那对账数据准备也不一样。使用分库也不现实，因为分库一般是按照主体id，而不是渠道id，来分库，这样对账就需要在多个库上进行，效率反而降低了。而对分表分库建立从库也非常耗费资源。这种情况下，需要同步一份数据到(hdfs)文件系统中，或者NOSQL数据库上。
由于交易记录是支付系统核心数据，有大量的应用，如信用、风控等，都需要交易记录数据。这些应用对交易记录的需求还不完全一致，为了提升性能， 交易记录会使用异步的方式来将数据投递给使用方。 交易记录在入库时，投递消息到消息系统中。使用方监听这个消息，一旦收到新消息，则从交易记录库中查询数据，获取数据并更新到库中。关于此类数据同步的文章不少，这里就不详细介绍。
轧帐
轧帐是按照客户订单号来比较本地交易记录和渠道交易记录是否一致。从算法角度，是计算两个数组的差异。在单机运行时，可以采用的算法不少，这里不详细介绍。 我们推荐采用mapreduce来轧帐，这有个优势，可以按照订单号将渠道提供的记录和本地记录shuffle到同一个reduce处理上，这样就可以很容易进行数据比对。 轧帐中最大的坑，莫过于切分点的问题。比如以整0点为切分点，那存在一个问题，本地23:59发起的交易，到了渠道侧，可能会在00:01处理，这一笔交易变成第二天的帐了。实际处理中，一笔交易在渠道侧处理，花上几分钟都有可能。 对于切分点附近无法确认的帐，做一个时间窗，在时间窗内的数据，留待第二天对账时继续处理。
平帐
发现两边不一致的数据，那应该如何处理？数据量不大时，记录起来，人工甄别就行。但如果数据量很大，每天上千条，人工处理就成本太高了。这个没有统一的处理方法，需要根据有问题的数据，做个分析，然后做自动处理。 针对交易记录的对账的处理，主要有如下情况：
本地未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致。 一般处理是将本地状态修改为已支付，并做响应的后续处理，比如通知业务方等。
本地已支付，支付渠道已支付，但是金额不同，这个需要人工核查。
本地已支付，但是支付渠道中无记录；或者本地无记录，支付渠道有记录。在排除跨日因素外，这种情况非常少见，需要了解具体原因后做处理。
针对退款的对账处理，主要有如下情况：
本地未退款，支付渠道已退款，则以支付渠道为准，修改本地为已退款状态，并出发后续处理。
本地已退款、支付渠道已退款，但是金额不同，需要人工核查；
本地已退款，但是支付渠道无记录；或者支付渠道有记录，但是本地没有。 在排除跨日因素外， 这种情况非常少见，需要了解具体原因后做处理。
总之，对账工作，即复杂也不复杂。需要细心，对业务要有深入的了解，并选择合适的架构。