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

背景

目前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、进行不平账处理

展开阅读全文

没有更多推荐了,返回首页