谈谈对账

哥之前有一篇还算比较火的文章，简单给大家介绍了支付系统对账的大致逻辑，但由于这个是简易版本的，所以未很精细地描述实际业务细节。

这一年来，我一直想重构那个答案，但是一直没动力去做，今天借着专栏，先给大家把对账这个事情给拆开好好讲讲。

先谈谈对账本身，如果做到很精细化管理，支付公司的对账通常分为三类：业务对账，资金对账，账单对账。

先说业务对账。

业务对账文件，通常是银行的业务系统（通常是收单）出具，在业务系统日切结束后用以日终同步交易状态的文件。

值得注意的是，不是所有银行的交易都有业务对账文件，通常收单交易业务对账文件会普遍一些。

这个文件内通常包含以下核心内容，以网银为例：

支付公司流水号，银行流水号，金额，状态标识（成功，失败）

前两个用来定位交易，而状态标识用于同步交易单据状态——通常情况下，业务对账就是用来恢复掉单数据的。

对于原交易单据未明确状态的掉单交易，业务对账可以帮助我们更快地明确单据状态。从这个角度来看，业务对账文件是联机交易回执单据的补充，业务对账的明细与交易发生时的银行回执是等价的，目的都是为了明确交易状态以及因此产生的债权债务关系。

对业务来说：业务对账文件=掉单查询回执=联机交易回执

所谓掉单，就是指支付单据处理过程中，由于网络通信异常，服务器并发过多，程序错误等问题导致的报文信息未达的情况。

通俗点说，一笔快捷支付请求，从支付宝发往银行，银行处理，再到银行回执支付宝这个过程，任何一个环节出现了问题，都会导致最后支付宝无法得知最后的支付处理结果。所以极端情况就是银行处理并扣了用户银行卡余额，但是没通知到支付宝，支付宝这边不能给用户处理成功，正好碰上掉单查询接口出点幺蛾子，那这个用户就要急死了。

so，业务对账，对支付公司来说，最重要的价值是用户体验。

tips：由于双方系统间交互都有一堆机制保障各自报文不可篡改不可抵赖，所以日间银行告诉你成功，日终告诉你失败这种情况理论上是不可能发生的。即便真的出了这个问题，你也可以拿着原报文去找他投诉：喂！要不要这样坑爹，这是你的借条。

今天先这样。