业务背景：

对账模块是支付系统的核心能力之一，是信息流与资金流关联的重要基础。 如果平台仅使用渠道的单方票据或平台跑单，则渠道出现错误或恶意扣款的风险极高。

为了提高资金核算的准确性，保护平台的利益，需要将平台系统的对账能力与上游渠道报表一一进行核对确认。 如有分歧，可及时解决或备案。

用户画像：

1）清算结算专员：负责发起清算的运营商首先要保证信息流平衡，然后确认应收资金流金额与信息流平衡账户一致。 我们希望能够及时发现并解决长短支付问题，保证对商户（可以在平台收款的用户）资金结算的及时性。

2）对账异常订单处理专员：负责计算异常订单的原因，并在平台上进行操作，纠正和平衡异常订单。

一、必须了解的业务知识点 1、对账

会计中的概念：指对相关账目进行核实，以保证账簿记录的准确性； 确保会计凭证一致、账目一致、会计事实一致。

体现在支付系统上：

1）核对：核对会计记录和会计凭证。 这里的记账凭证是指第三方上游提供的渠道报表。 第三方渠道实际上会根据报表金额进行资金结算，也就是常说的信息流对账。 （部分支付公司或银行允许业务即使资金未实际到账，只要收到对账单并结算即可启动清算，以提高清算的及时性）

2）对账：对相互关联的多个账簿记录进行对账。 相互关联的账簿记录包括总账簿之间的对账、明细账簿之间的对账等。整个支付系统可以拆分为多个子系统，如交易系统、账户系统、会计系统、账务系统等。 每个子系统处理并记录自己的业务，实际上相当于会计理论中的账簿。 系统间的对账主要用于纠正内部系统中数据不一致的情况。

3）账务核对：核对各项资产、材料的记录价值与实际金额之间的核对。 确认第三方汇入银行账户的资金结算金额与结算金额是否相符，这就是常说的资金流向对账。

2、结算

对账系统主要进行信息流的对账。 如果对账中发现有差异的订单分类并记录在对账异常订单表中，则可以称为对账。

3. 账户余额

当异常订单的对账进入错误流程时，可以根据预先设计的规则手动或自动处理这些异常错误，这可以称为对账。

4. 渠道声明

上游渠道将根据平台申请的渠道账户维度推送报表。 通道账户通常也称为支付通道。

如果是第三方支付公司或银行，上游渠道为微信、支付宝、银联二维码（云闪付）等。例如支付平台应用有微信2渠道和微信6渠道，则2个对账单文件会在微信端生成。

每份对账单将包含成功的付款订单和成功的退款订单。 第三方将使用对账单中的结算金额（付款订单金额-付款订单手续费）-（退款订单金额-退款订单手续费）进行结算并将款项汇至平台资金账户。

5.银联二维码（难点）

银联二维码是银联平台自主推出的支付产品。 C端支付采用云闪付和各类手机银行APP。 订单底层走的是银联二维码通道。

为什么需要高亮银联二维码？

由于与微信、支付宝渠道统一费率原则不同，银联会根据C端用户支付时使用的银行卡性质以及交易金额是否大于1000元来制定费率规则，同时也会收取额外的品牌服务费。 详情见下图。

因此，在设计银联二维码渠道对账时，还需要考虑多种费率和品牌服务费的场景。

2. 对账流程 1. 业务流程

对账业务可分为五个业务环节。 本文主要阐述各环节的能力与职责、常见问题及一般解决方案。 具体的产品方案还需要结合阅读器平台本身的业务特点和系统架构设计。

3. 对账任务

对账是一项日常操作。 正常情况下，上行通道会以D+1为周期生成通道语句。

系统默认每天生成定时对账任务。 每个上行通道的生成时间不同。 这可以提前与上游确认，并根据平台对账的处理时效性和商户到账要求来设计合理的执行时间。

在设计对账任务之前，需要确认通道语句推送方式、解析方式、匹配字段，提前做好联调适配工作； 例如，频道可能需要申请白名单权限或提供SFTP地址信息，所以上线后要小心。 这时我才发现系统无法正常获取报表。

1.创建任务批次

一方面创建批次是为了防止重复对账，另一方面在对账完成时需要将对账结果信息存储在批次中。

2.记录任务信息

对账任务信息，如：渠道名称、渠道编号、渠道商户编号、对账任务批次、对账任务状态、交易时间、任务创建时间、下载开始时间、下载结束时间、下载状态、对账开始时间、对账结束时间、调节结果、调节方法；

对账方式是对账处理时的对账规则，根据业务实际情况可分为：无需对账、基于渠道、基于平台。

根据渠道，如果对账订单平台的交易状态为支付中或支付失败，但渠道为支付成功，则平台状态将更改为支付成功。

视平台情况，若出现上述情况，对账订单将被记录为异常订单。

3.重置任务机制

考虑到对账过程中可能出现的上游渠道问题或者平台系统本身的问题，需要设计重置机制。

上游通道语句错误，需要推送两次或者多次，需要重新下载通道语句或者重新上传通道语句； 可能是平台自身数据错误导致大量订单不符，修复后需要重新对账。

4. 对账任务详情示例

对账信息：记录对账任务的基本情况；

对账结果信息：显示关键对账字段值；

核销账户信息：显示是否有核销账户订单及金额；

对账异常信息：显示是否有对账异常订单及其金额；

注：记录系统自动处理的过程，也可以手动修改。

四、报表下载 1. 获取文件

获取通道语句的方法一般会提前写成任务规则。

大多数银行要求接入方提供ftp服务，银行定期将报表推送到接入方提供的ftp服务器上；

也有一些银行提供对账单下载服务，都是通过ftp/http方式，其中ftp是最常见的方式；

另外，网上银行的报表也比较特殊。 一般情况下，您需要登录网银后台管理系统进行结算并手动下载。 结算下载对账单后，导入对账系统。

2.判断文件是否存在

当任务自动获取文件时，需要判断该任务是否存在：

自动获取通道语句：无需设置轮询并重新获取每个间隔。 设置重试次数和间隔时需要小心。 如果重试太频繁，很容易杀死服务器。 如果时间间隔太大，就会阻塞后续的处理步骤。 5 到 10 分钟是合适的重试间隔。

手动导入通道语句：需要设计导入入口，导入成功后任务状态也要相应改变。

3.下载文件

技术实现可以做成工厂模式。 不同的支付渠道有不同的下载类别。 如果是http接口，则将语句写入文件中。 如果是ftp服务器，则将服务器中的语句下载到本地目录进行解析。 。 代码主要涉及ftp工具类、http(s)工具类以及相关IO读写。

4.确定来源渠道

获取上游语句文件后，很可能多个通道的语句都在同一个SFTP地址。 根据文件名匹配对应的对账任务。 文件名通常包含计费时间和渠道商户号，然后执行下一步。

5. 文件解析 1. 解析文件

解析文件主要是将下载的对账文件解析成我们可以对账的数据类型并存储到数据库中。

不同的通道有不同类型的解析文件，因此也可以设计成不同的解析模板，并使用工厂模式将不同格式的文件解析为可以协调的统一数据类型。

解析的文件类型一般包括：json、text、cvs等。另外，有些银行会对账单进行加密或者提供zip打包格式。 这里需要开发额外的zip工具类和加解密工具类来处理。

对账文件包含的主要信息包括：商户订单号、交易序列号、交易时间、支付时间、付款人、交易金额、交易类型、交易状态等字段。

2. 转换为数据库

每个渠道的话单格式不同。 拿到账单后，下一步就是规范账单，以便结算和后续工作能够统一处理。

标准化的计费数据可以放置在文件系统或数据库中，具体取决于交易数据量； 如果每天的量超过百万，那么使用文件系统比较合适。 数据库操作速度比较慢，而且浪费资源。

基于文件系统的标准化涉及以下内容：

文件格式标准化，统一使用csv或json或xml格式。 如果您使用 或 进行调节，也可以使用 csv。

文件存储在统一的文件目录中，文件名需要遵循统一的命名规则。

六、声明处理 1、获取对方声明

将事先准备好的上游语句标准文件放入缓冲协调池中。

2. 获取我们的声明

本地交易记录的准备一般涉及以下方法：

什么都不做，只需使用订单表中的原始数据：鉴于大多数系统都使用它，这也意味着对其进行调节。 对账需要大量的数据查找工作，这势必影响线上业务。 当数据规模很大，比如超过100万条时，就不适合了。

使用备库进行对账：简单，不影响线上业务。 这是典型的以空间换时间的做法。

采用分表分库进行对账：如果业务规模很大，需要分表分库来处理，那么对账数据的准备就会有所不同。

3、一一匹配

前面提到了对账方式有无对账、基于渠道、基于平台三种。 大多数情况下，对账方法是基于渠道的。 信息流向和支付成功结果由上游决定。 如果渠道通知平台，平台可能会因为网络或系统问题而收不到通知。

一般情况下，交易金额、交易状态、手续费金额都是一一匹配的。 协调方法基于基于通道的处理逻辑。 例如：

1) 交易金额不符：将记录异常订单。

2）交易状态不符：若上游支付成功而我方未支付或失败，则以上游为准。

如果我们的订单支付成功，上游只会推送支付成功的订单作为报表。 如果上游语句不存在，我们的订单会被记录为挂单；

如果语句存在但我们这边不存在，则会记录异常订单。

3) 手续费金额不符：将记录异常订单。

4、核销账款的处理

经常会出现由于每日截止时间点不一致或网络延迟等原因导致我们平台下单时间与上游渠道时间不一致的情况。 同一个订单在渠道上的交易时间是1月1日，但在平台上是1月2日。

当账户处于挂单状态时，如果对账时上游没有我方的订单，订单就会被放入挂单中。

注销账户时，若挂单账户订单匹配，则记录为当日平台账单，挂单账户状态变更为已注销。

7. 错误处理

关于出错流程，各个系统的业务特点、运营团队流程、公司财务管理方法等都不同，不能生搬硬套，但原理是一样的。 所有异常订单的报销账目必须有据可查，并经过多重审核。

1、异常原因

（1）如果订单金额不一致，通常是平台调用上游交易接口时双方字段定义不匹配造成的。

（2）如果出现手续费金额不一致的情况，一般是平台手续费计算规则与上游不匹配造成的。 差别不会太大。 可以设计一个阈值，在可以接受的范围内就不算异常。

（3）如果上游语句存在，但平台订单不存在，通常是因为第三方绕过平台系统，与上游系统进行支付或退款交易。 需要及时检查交易密钥是否泄露或绕过商户在上游系统平台进行操作。

2. 修正

选择跟随平台或上游修改订单金额、订单状态、手续费金额。 此时写下更正原因很重要，方便后期业务跟踪和考虑。

3. 余额账户

将平台异常订单状态更改为已结算账户，并以账户结算时的时间作为计费时间，并入平台账单中。 平台将根据平台账单计算渠道利润分成金额和商户结算金额。

8、业务规则系统化

最后，每个平台的产品细节都会有自己特定的业务规则。 平台页面和平台操作功能我就不详细解释了。 我不会给出详细的解释。 将以上业务规则系统化，系统流程图如下。 读者可以根据自己平台业务情况进行提炼和提炼。