如果你是一位支付产研工作者,那肯定了解过支付对账的设计。我个人把支付对账分为四个部分:渠道对账、商户对账、内部对账、差错处理;
- 渠道对账:平台与渠道方的对账文件进行对账,有可以分为交易对账和资金对账两个部分。但一般的平台只做交易对账,资金对账则会根据交易对账和差错处理的结果来 判断
平台应收账户
=已对账交易记录交易总额
-手续费
=实际渠道结算金额
,这样会更高效的处理资金流转;至于平台的内部的账户系统是否有漏记、错计,是可以通过内部机制来控制的,比如:总账核对、总分核对、内部系统准实时对账等; - 商户对账:简单理解就是,自己平台对完账后,提供给商户的标准对账文件;
- 内部对账:系统与系统直接的日终核对、账户系统的总账加工、总账核对、总分核对等;
- 差错处理:很多朋友和我在沟通对账后的差错处理的时候,总是不明白差错处理的定位;他们会狭隘的认为差错处理是对账模块的,不应该反向去处理更上次的交易订单、业务定的一些状态和错误的订单信息。我告诉他们:渠道对账是一个平台性的标准功能,是不需要人参与运营的,是自动化的,它属于基础,底层。但差错处理却不同,它是一个资金运营的过程,是一个对自身系统整体纠错的过程。而且要随着交易系统、核心系统的逻辑变化而不断调整的,所以,它是一个更上层的资金运营平台;
本章只交流渠道对账的对账模型,因为对账模型是一个普适性的标准产品;而差错处理需要根据自身业务特点和原来其他模块的产品逻辑做特殊处理,具有个性化,不做总结,有问题可以私聊我;商户对账,就非常简单了,不做说明了;
我个人经历够两个对账模型:传统滚动对账模型 和 新型滚动对账模型;
这两个都是有滚动对账,那什么叫过滚动,是什么东西在滚呢?这里其实就是未对账数据+存疑数据在滚动。
那存疑数据主要的原因是什么造成的呢?主要是时差数据。
时差数据的来源
- 日切:通俗的来说就是更换系统会计记账的时间;系统从当前工作日切换到下一工作日,日切过程中交易可以照常提交并正确处理返回。
日切影响:如果是T1结算的代收通道,T日交易因为日切原因,订单完成时间落在了T1,则T2才能结算; - 时差:因为日切导致订单不能包含在T日交易对账单中的订单,称为时差订单,需T2重新对账。
日切偏移.
支付渠道的日切从理论上讲有两个可能:向前偏移(提前一点点时间切换会计日期)、向后偏移
-
支付渠道侧日切向后偏移
总结:如果想后偏移,
支付渠道侧
T日交易成功数据有可能对应业务方对账平台
的T日、T+1日未对账数据;
- 支付渠道侧日切向前偏移
总结:支付渠道侧
T日交易成功数据有可能对应业务方对账平台
的T-1日的对账存疑订单数据、T日未对账订单数据;
支付渠道侧日切偏移方向未知
在支付渠道侧日切偏移不知道是向前偏移,还是向后偏移。或者说,大部分支付公司都定好了自己的系统是朝着一个方向偏移,但不排除特定情况下需要向相反的方向偏移。
那我们设计的支付模块的对账能力,应该具备支付渠道侧多种形式的日切偏移。并尽早的把已结算给我们的资金完成对账,便于对完账后的资金流动性管理;这就设计到我们后面要讲的两种对账模型的区别了,也主要是优化了这个特性;
传统滚动对账模型
注意:这里业务方的数据只取了T日数据,没有取T+1的部分数据。当渠道日切向后偏移的时候,是不能及时完成对账处理的;
优化后的新型滚动对账模型
注意:这里业务方的数据只取了T日数据和T+1的部分数据(可以这是截止凌晨2点)当渠道日切向后偏移的时候,能及时完成对账处理的;
代收流水比对举例
代收流水比对结果汇总
对账术语收集中
长款 Cash shortage
短款 Cash overage
时差 time difference
对账成功 succeeded
未对账 Outstanding reconciliation
对账不一致 inconsistent
对账 Reconciliation
差错 Mistake