支付业务与技术架构学习总结（6）——对账系统的设计

Dear 丶 2021-11-10 07:54 397阅读 0赞

# 背景 #

目前app线上涉及若干和支付有关的业务，并且存在如下情况：  
1、一个业务支持多种支付方式  
2、一种支付方式同一个商户号，�支撑多个业务  
3、一种支付方式存在多个商户号，不同的业务有些使用不同的商户号，有些业务使用同一个商户号。  
4、在某些业务中支持退款，且未设置退款时限。  
5、某些业务的数据是分散存储的，如某系统仅含支付信息，某系统仅含产品销售信息。  
因此，对账工作显得格外复杂，为了理清思路，解决对账这个问题，写下本文。

# 对账涉及的一些概念 #

1、支付渠道：目前分为支付宝、微信、招行一网通支付等。  
2、业务订单：app线上涉及支付的业务，在数据库中的交易记录，记录一般含商家单号、支付单号、金额、支付时间等。  
3、商品订单： 某些业务的商品为其他服务提供，app在支付成功之后将去其他系统创建订单。  
4、不平账：分为短账、长账、错账  
短账：实际入账比应入账少  
长账：实际入账比引入账多  
错账：数据错误，如金额不一致，其他数据不一致等。

# 订单支付流程 #

这里需要按照业务场景划分类型，不同的类型有不同的流程，按照app目前线上的业务情况，有如下几种类型：

## 1、单系统 ##

订单支付成功之后，将本系统中的订单状态改成已经支付，并进行其他业务逻辑，对账工作中涉及的数据，在本系统可以直接取到。

## 2、多系统 ##

订单支付成功之后，将本系统中的订单数据提交到其他系统中创建商品，并将本系统中的订单状态改成已经支付。对账将在系统间进行，各个系统层层对账。

# 对账总体思路 #

从短账、长账、错账的角度出发，对账本质上为两个集合之间的比较。集合中的元素为两个系统记录都存在的具有一一对应关系的值。在支付系统中为商户给的订单号，一般为本地订单的订单号。如存在多个系统，对账需要对多个系统的数据两两比较。  
集合之间的运算方式分成三种：1、交集（ ∩） 2、差集 （- ） 3、并集（∪）

>     以下所述的集合均为一天内的数据集合。

设

支付系统的订单集合为P  
本地业务订单的集合为L

则

短账=L - P 记为LP  
长账=P - L 记为PL  
错账=error( L ∩ P ) 记为L\_ERROR  
平账=(L ∩ P)-error( L ∩ P ) ，记为L\_SUCCESS  
error为搜索 集合内数据错误的函数。

如果存在n个其他系统需要两两对账  
则系统间的短长账和平账也可以用上述方法解决。

设：

系统1的订单集合为S1  
短账=S1 - L\_SUCCESS 记为LS1  
长账=L\_SUCCESS-S1 记为S1L  
错账=error( L\_SUCCESS ∩ S1 ) 记为LS1\_ERROR  
平账=(L\_SUCCESS ∩ S1)-error( L\_SUCCESS ∩ S1 ) ，记为LS1\_SUCCESS

系统2等依次类推

### 问题 ###

Q: 一个支付渠道支撑多个业务，如何用上述方法解决？  
A：

设

支付系统的订单集合为P  
本地业务订单的集合有：L0、 L1、 L2...LN

则

短账0=L0 - P  
短账1=L1 - P  
短账2=L2 - P  
...  
短账n=LN - P  
长账= P - L0 - L1 - L2 ... - LN  
对账集合： (L0 ∩ P) ∪ ( L1 ∩ P ) ∪ (L2 ∩ P) ...∪ ( LN ∩ P ) 记为T  
错账=error( T )  
平账=T-error( T )

Q: 若短账或长账是由时间差引起的呢，如本地订单为23：59：59秒创建，而支付系统中的时间为0:00:00之后的？  
A：这里视业务流程定，可以做手工不平账处理，也可以在第二个对账日继续对这些长账和短账进行处理。需要并入第二个对账日的对账集合中。一般可以设置一个时间段，如规定0点前后半小时内的长短账，在第二个对账日继续处理。

Q: 退款怎么对账  
A：与上述方法类似，只是时间范围不同，若退款未设置时限，则比较的对象为 支付系统对账单上的某一天的退款集合与订单系统的总退款集合

## 对账流程 ##

1、下载各个渠道的明细对账单，可以通过支付系统提供的接口下载，也可以人工下载各个支付系统的对账单，如支付宝和微信的都为cvs格式的文件。  
2、准备各个业务的对账数据  
3、进行集合计算获得不平账  
4、进行不平账处理