STAR法则拆解“对账”案例分析

深圳产品图鉴 2024-10-01 11:33:34

本文将采用STAR 法则的视角，结构化拆解对账场景的案例分析，首先简要梳理下STAR 法则

Situation（情境）：描述事件发生的背景或情境。
Task（任务）：明确在该情境中需要完成的任务或面临的挑战。
Action（行动）：叙述为了完成任务或应对挑战所采取的具体行动。
Result（结果）：展示采取行动后得到的结果或学习到的经验。
Situation（情境）：

为出海商家提供支付服务解决方案，按照与商户约定的结算周期如T+15进行资金结算，其中必不可少的一个环节就是对账，对账是结算的基础，当前有些机构是先对账再结算，有些是对结分离。

一、对账情境

为了确保同一个事务的数据描述在不同场景，记录是否一致而进行的一致性比对。

举个例子：对于面馆老板，顾客吃了一碗面，点菜小票就是原始凭【证】，付了10元钱是【账】，老板电脑点菜记录小票10元是【账】，老板账户中余额增加10元是【实物】。

账实对账：是指我们记录的账与实物资产的实际数量进行对账。
账证对账：是指将自己的账本与记账凭证进行核对。一般记账凭证由与业务合作的第三方公司提供，在面馆的例子里，记账凭证由支付宝提供（交易记录）。
账账对账：是指在上下游相互关联的账本之间进行对账。在整个交易过程中，一般会涉及上下游多套账，上游比如外部采购、对外销售，下游比如快递发货账、第三方服务费等。这些账和总账之间有非常多的关联性，所以一般账账核对，通常用于确认及修正内部账之前的数据不一致。

1. Task（任务）

跨境支付机构在对账环节面临的挑战有几个：

其一：对账准确，能对不同上游银行的对账文件解析准确

其二：确保商户资金结算体验，如期结算给商户

其三：确保能对差错进行处理

其四：搭建商户获取对账单的系统或接口服务

2. Action（行动）

渠道数据处理：

主要负责渠道对账文件的下载，解析，以及数据落库。

目前市面上第三方支付渠道对账文件下载方式主要分为以下几类：

第三方渠道定时推送到 SFTP/FTP。这种模式比较简单，我们定时从 SFTP/FTP 取对账文件。
调用第三方渠道对账文件下载接口。这种模式需要对接渠道下载对账文件接口，定时调用下载。支付宝与微信为该模式。
手动在支付渠道网站下载对账文件。这种模式最不友好，需要我们花费人力下载文件。

除了下载方式，对账文件的格式也会存在一些区别。比如支付宝对账文件格式为 csv，而微信的对账文件格式为 txt，另外有些渠道为 xml,xls。

接下来，干货来了，从对账案例调研，对账核对模块，差错处理，系统优化模块进行深入剖析！

二、对账案例调研

案例一

叮咚支付向您提供两种对账形式，您可以根据需要自行获取对账文件。

通过商户站下载对账文件。
叮咚支付向您提供SFTP及其相关参数供以登录和下载。此选项需在叮咚支付开立SFTP账号，在您与叮咚支付的协议签署完成后，即可向工作人员申请开通您的商户号所属SFTP账户。

SFTP对账

SFTP对账是指您通过登录**向您提供的SFTP账户，获取对账文件的过程

获取到您的SFTP账户信息之后，您就可以通过访问SFTP的方式获取对账文件，下面我们以WINSCP作为示例，演示获取对账文件的过程。

打开WinSCP。

输入您的叮咚支付SFTP账户信息，连接SFTP。

在SFTP根目录下，打开以您的用户名命名的文件夹。

打开以您的商户号命名的文件夹，获取对账文件。

案例二

叮叮支付对账方式如下：

商户后台
API对接

接口请求参数：

接口响应参数：

商户站对账单时间周期：

商户站快捷查询日对账单，周对账单，月对账单，商户站自定义时间范围查询

日对账单，周对账单和月账单，不同范围的对账单下载模板是一致的

对账文件模板

通常可以在对账单上查看商户对应的交易记录信息，拒付，调单，伪冒，退款，费用项信息汇总以及每项明细

文件结构处理方式一：通常汇总对账单表在对账单表格文件的第一个sheet，各个分类的明细表放在第后面的sheet，优点是商户可以以先总后分的方式进行核对查验，先了解当前对账周期的各项总额，再查看各项明细记录

对账粒度

对账粒度分为两种，分别是总数对账和明细对账。

1）总数对账：选择一个维度，进行总数级别的对账。比如账期账单消费总数和账期资金记录总数对比，总数级别的对账好处是对账口径的设计比较简单，可以快速实现，不易出错。缺点就是无法定位问题数据，一旦对账发现问题。还需要进一步寻找问题数据。

2）明细对账：对双方的每条数据按照业务规则依次进行比对。它的优点是可以准确定位问题数据。缺点是对账口径的设计比较复杂，效率比较低。因为我们需要同时针对漏、重、错三种错误类别设计出较为全面的对账口径，同时还要考虑到业务的边缘场景。稍有不慎，就会影响对账的准确性。

因此，推荐的做法应该是以总数对账为主，首先确认是否存在问题。以明细对账为辅，对具体问题进行定位。

对账，我们一般称为勾兑，支付系统的对账，包含着两个层面：支付系统内部间的对账，支付系统一般是分布式的，整个支付系统被拆分成了多个子系统，如交易系统、账户系统、会计系统、账户系统，每个子系统在处理各自的业务，系统间的对账，就是以上系统的核对，用于修正内部系统的数据不一致。
支付系统与渠道的对账，这里的渠道泛指所有为支付系统提供代收付业务的渠道，如：第三方支付公司、银行、清算中心、网联、银联等。

对账单关键字段解读：

文件命名：商户对账单
通用文案：支付机构联系信息和品牌信息
商户号以及公司名称：支付机构商户唯一标识码
币种：通常每个记账币种一个账单分类，按不同的币种分为不同sheet进行汇总统计
账单周期：2024-07-01-2024-07-31

对账单分类汇总类目一：交易对账

按交易类型分为：成功交易，退款，拒付，调单，申诉成功等

费用对账：

以上分类项收入，支出，收入笔数，支出笔数，也有记录为借记，贷记，英文接口字段一般为Debit（通常为减号）和Credit（通常为记号）

其它调整：

案例三：支付宝商户对账方式

支付宝对账目前支付宝对外的常用对账方式也有两种：一种是通过在支付宝后台下载账单的方式来对账；一种是通过调用接口的方式来实现对账

方式一：

方式二：支付宝商家平台业务账单明细和业务汇总查询下载表

案例四：微信支付商户对账

SUCCESS账单字段：交易时间,公众账号ID,商户号,设备号,微信订单号,商户订单号,用户标识,交易类型,交易状态,付款银行,货币种类,应结订单金额,代金券金额,商品名称,商户数据包,手续费,费率,订单金额,费率备注

REFUND账单字段：交易时间,公众账号ID,商户号,设备号,微信订单号,商户订单号,用户标识,交易类型,交易状态,付款银行,货币种类,应结订单金额,代金券金额,退款申请时间,退款成功时间,微信退款单号,商户退款单号,退款金额,充值券退款金额,退款类型,退款状态,商品名称,商户数据包,手续费,费率,订单金额,申请退款金额,费率备注

注意：

符号：明细数据内容每个字段前会增加1个字符 ` 用于避免获取的内容被excel展示为科学计数法的格式、丢失数据细节
下载账单API为通用接口，交易/资金账单都可以通过该接口获取到对应的账单。
账单文件的下载地址的有效时间为30s。
强烈建议商户将实际账单文件的哈希值和之前从接口获取到的哈希值进行比对，以确认数据的完整性。

备注：哈希是一种将长数据映射为短数据的方法，哈希的有多种用途，包括数据完整性验证、密码存储、数据检索和加密安全

该接口响应的信息请求头中不包含微信接口响应的签名值，因此需要跳过验签的流程。
微信在次日9点启动生成前一天的对账单，建议商户10点后再获取。

三、对账核对模块

这一个模块我们使用上一模块提取出来的数据，核对订单号与金额是否完全一致。

这个过程可能产生三类差异数据。

第一种情况为本端数据存在，对端数据不存在，我们称为本端多账。

第二种情况为对端数据存在，本端数据不存在，我们称为对端多账。

第三种情况为金额不一致。

三者如图所示。

这里产生的差异数据存入一张差异表中，以便下个模块使用。

四、差异数据处理模块

这个模块主要用来处理上个模块产生的差异数据。

上面三类差异数据中，金额不一致相当少见，这种情况需要人工判断。

我们先讨论本端多账的情况。

本端多账是对账系统最常见的一种情况。这种情况可能由于交易的时候发生日切问题，导致双方记账日期不一致,从而发生不平账。

我们先解释日切的概念。

日切，通俗的来说就是更换系统记账的时间，系统从当前工作日切换到下一工作日。这个过程中，若我方的交易订单刚好发生在 T 日 23:59:59，那么我方的记账时间为 T 日。第三方渠道接收到订单的时间为 T+1 日 00:00:01，这样第三方渠道该笔的交易的对账日期为 T+1 日。

第三方渠道 T 日对账文件将缺少这笔，但是我方 T 日数据却存在这笔，这就导致了核对过程中产生一笔本端多账差异数据。

对于这类差异数据，我们可以选择将这笔数据挂账，等待 T+1 工作日对账。T+1 日对账的时候，对账单会相应多出数据，这样在核对过程就会产生对端多账的差异数据。

然后在 T+1 日差异处理模块将前几日差异数据都提取出来，逐笔核对本端多账数据与对端多账数据。若核对一致，将两笔差异状态都更新成处理完成。最后若无剩余差异数据，当天账单平账。

伪代码如下（引用）：

对端多账的产生情况可能可能有两种情况.

第一种情况测试环境与生产环境共用一份第三方渠道参数，这就导致测试环境交易订单也会出现在对账单中。若是这种情况，我们确认测试环境存在这批数据之后，我们忽略这批差异数据即可。

第二种情况，本端交易订单存在，但是状态不是成功状态。这种情况下，需要调用第三方渠道提供的查询接口，查询订单最终状态。若查询成功，更新订单状态，然后将差异数据状态更改为处理成功。

若第三方渠道无法查询到订单的状态。这种若与渠道确认订单最终支付成功，我们需要将支付订单改为支付成功，并修改差异账的状态。

最后我们再次重新对账，由于对端多账的数据会有对应的本端数据，将不会产生差异数据，这次对账完成且平账。

五、系统优化

目前系统的对账系统定时任务采用 Spring 定时功能。后期优化准备接入 elasticjob 这种分布式定时调度程序，可以做到快速修改定时任务的时间，而无需重启程序。以及可以快速触发定时任务。

1. 文件获取

银行，第三方支付，银联等，基本都会提供对账单下载的功能。不过也有少数工作做不到位或者太到位的银行，只提供账单查询后台，不提供对账单下载功能。对开发人员来说，这里有几个坑：对账单格式不一。文本，XML，csv的都有。为了后续能够统一处理，在账单下载完成后，需要进行标准化处理。
下载方式不一，HTTP，HTTPS，FTP的，都有。下载程序需要按照渠道的协议来处理。
下载时间不一，一般是凌晨1点后，到中午12才能用的也有。如果在预定的时间取不到数据，需要注意重试读取。
稳定性差。FTP服务器出问题那是常有的事。渠道侧解决方案往往就是重启。所以重试机制是必要的。

看一下第三方支付的对账单情况：

技术选型上，HTTP(S)用apache httpclient即可实现链接池和断点续传， FTP也可以使用Apache Commons Net API。但不管是哪一个，都需要设置重试次数和链接超时间。重试次数和间隔的设置需要小心，重试太频繁，容易把服务器打死.；时间间隔太大，又会阻塞后续处理步骤。5～10分钟是一个合适的重试间隔区间。链接超时指在服务器出现问题时，连接在指定时间内获取不到数据即自动断开。

这个很容易被忽略-渠道账单数据解析器设计。

即：我们拉了很多的不同渠道的账单，但是每个渠道的字段的命名不一样，那我们要把这些字段根据我们的理解映射到统一的字段当中，这样我们就可以无差别的处理不同的渠道了，但是这个就要具体情况去具体分析