只要是涉及到支付的互联网行业，就不可避免地需要对账。几乎所有互联网公司的业务都或多或少涉及到支付。大一点的公司甚至标配了自己的第三方支付公司，所以对账是普遍的。对账系统是支付系统中最重要的部分，也是保障交易和资金安全的最后一道防线。在大多数互联网公司中，一般都有独立的对账系统进行处理，例如：电商平台、互联网金融、第三方支付公司等。对账是支付系统的一部分，所以在对账之前，我们先了解相关业务知识业务知识什么是对账？、核对账簿相关数据的工作。在银行或者第三方支付中，对账其实就是一定时期内交易双方相互确认的过程。一般是银行或第三方支付公司在次日整理出前一天的交易，生成对账单进行支付。平台商户下载结算应付给平台商户的账款。再往下一层，在互联网金融行业或者电商行业，对账其实就是在固定期限内与支付方（银行和二方支付）确认交易和资金的正确性，确保交易和双方资金一致无误。在广义对账中，理论上应该对所有跨应用程序的数据交互进行对账。因此，对账也可以分为信息流对账和资金流对账。信息流对账一般也用于自身内部系统的对账，比如支付系统的支付数据与业务系统的业务数据之间的对账，保证资金往来和业务往来的一致性。资金流向对账是支付系统与银行或第三方支付系统之间的资金交易对账。对账方式单向对账：一般使用第三方支付机构或银行流量与自己系统对账，防止漏单问题；双向对账：订单系统和财务系统等两个应用之间的流量双向校验，需要保证财务系??统有支付成功的记录，订单系统也有成功的记录；还要保证订单系统记录成功，财务系统也成功。我们一般使用双向对账进行对账。和解相关的问题。不同系统日常积分不一致：滚动对账错误处理：对账、补偿（退款）相关概念需要保证各参与方的记录能够一致无偏差。对账系统的工作是发现记录中的差异，即关闭账户；然后手动或自动解决这些差异，即平衡账户。长单和漏单在平台交易的基础上与银行对账，发现周期内的交易，平台有此单但第三方支付中无订单，成为平台的长期支付。平台支付时间长一般是因为用户跨天支付。例如，用户在23:58创建订单，并在次日凌晨00:03支付。在基于银行交易对账的情况下，如果银行有这样的订单，而平台没有这样的订单，则属于平台漏单。平台漏单很少见，一般直接转人工处理。账户系统在一般的支付系统中分为登录账户和支付账户。支付账户是指用户在支付系统中用于交易的资金的所有者权益凭证；登录账号是指用户登录系统的证书和个人信息。一个用户可以有多个登录账户，一个登录账户可以有多个支付账户，如零钱账户、储值卡账户等。一般来说，支付账户不会在多个登录之间共享。对账交易一般是参与交易的支付账户。交易和账户账户设置通常从交易开始。交易的实现必须有账户的支持，而账户是交易的基本构成要素。从支付系统的角度来看，交易涉及的资金流向是资金从一个账户流向另一个账户。发起交易的一方称为交易主体，可以是个人也可以是机构。清算与结算清算主要是指不同银行之间货币的收付。可视为发款行和收款行在结算前对付款指令的发送、接收、核对和确认。其结果是结算工具和支付信息的综合交换，并建立最终结算头寸。结算是指在清算过程中产生的待结算头寸，在发款行和收款行进行相应的账务处理，完成资金划转，并通知收款人和付款人的过程。目前大部分银行结算业务主要通过两类账户完成：一类是银行间开立的代理账户，一类是在央行、银联等独立金融机构或第三方支付机构开立的账户。清算：计算各方到期应付的时间和金额。结算：根据清算结果，在规定时间向各方进行实际资金划转操作。资金池用户的储备资金（如充值）统一存放在公司的银行账户中，公司可以随意处置这些资金，这就是资金池。与之对应的是第三方托管。用户的备付金存放在企业在第三方支付机构为用户开立的虚拟账户中，企业不能随意提取这些资金。互联网金融现在全面要求接入银行存管，即银行会为每个用户创建一个资金账户来保护用户的资金，互联网金融公司不能随意划转这些资金账户中的金额。对帐系统AccountReconciliationDesign在对帐系统的设计阶段，对帐系统分为四个模块，每个模块负责各自的功能。文件获取模块：下载或读取各渠道的对账文件文件分析模块：创建不同的分析模板，根据渠道和文件类型获取相应的分析模板进行分析对账处理模块：对账业务逻辑处理错误处理模块：处理错误池中的订单，一般设计一个定时任务，每天在固定时间点触发，定时驱动调度类调用四个模块处理对账。有些银行会主动推送对账单，然后通过http回调触发对账流程。对账算法流程：1.从上游渠道（银行、银联等金融机构）获取对账文件，程序逐行解析存储；程序逐行读取，与我们系统的交易记录（如果是会计系统，合理的方案应该在账户记录中）进行比较，找出不同的记录；3.将账户与我们系统的交易记录进行对比程序根据交易记录逐行读取，并与上游的对账文件进行对比，找出差异记录。二、缺陷：1、对账过程中查询相关数据。如果数据量巨大，对数据库的性能影响很大，对账逻辑的扩展极其麻烦；2、逐行比较算法效率低，但算法没有很好的优化空间。如果使用数据库INTERSECT和MINUS，数据库压力也大；3、在业务量很大的情况下（比如上游有几百个通道需要纠错，每个通道都有几十万条交易记录），对账服务器和数据库服务器的负载就比较高。即使采用读写分离，在对账的时候，读库的压力还是很大；4.导入批处理文件，逐行入库，效率比较低（每次都需要建立网络连接，关闭连接）。3、改进：1、对于网络传输，尽量使用批量操作，减少网络消耗和时间消耗；2、使用Redis等NOSQL数据库，减轻数据库服务器的压力。同时，也便于扩展。一台Redis服务器不够用，可以自定义添加服务器进行对账；3.利用Redisset集合的sdiff功能，利用Redissdiff算法的高性能，比较上游记录和我们记录的差异。对账流程1、下载对账单大多数银行要求接入方提供ftp服务，银行定期向接入方提供的ftp服务器推送对账单；部分银行也提供ftp/http的月结单下载服务，且大部分为ftp方式；另外，网银对账单比较特殊，一般需要结算登录网银后台管理系统，手动下载，结算下载后导入账户对账单系统。在技??术实现上，可以做成工厂模式。不同的支付渠道有不同的下载类型。如果是http接口，把文件写入语句。如果是ftp服务器，将服务器中的语句下载到本地目录并解析。.主要涉及代码ftp工具类，http(s)工具类，相关IO读写。在技??术选择上，HTTP(S)可以使用apachehttpclient实现连接池和断??点续传，FTP也可以使用ApacheCommonsNetAPI。但是无论是哪一种，都需要设置重试次数和链接超时时间。在设置重试次数和间隔时需要小心。如果重试太频繁，很容易把服务器挂掉。如果时间间隔过大，会阻塞后续的处理步骤。5到10分钟是合适的重试间隔。2.创建批次。一方面，创建批次是为了防止重复对帐。另一方面，在对账结束时，需要将对账结果信息分批存储。3、解析文件解析文件主要是将下载的对账文件解析成我们可以对账的数据类型存入数据库。不同渠道解析出来的文件类型不同，所以也可以设计不同的解析模板，利用工厂模式可以将不同格式的文件解析成统一的数据类型，可以调和。解析的文件类型一般包括：json、text、cvs、excle等。另外，部分银行会加密票据或提供zip打包格式。这里需要开发额外的压缩工具和加解密工具进行处理。对账文件包含的主要信息包括：商户订单号、交易流水号、交易时间、付款时间、付款人、交易金额、交易类型、交易状态等字段。4、对账处理对账处理也是对账的核心逻辑，分为以下几步实现：查询平台所有成功订单查询平台所有交易订单查询平台缓存池数据查询银行交易成功订单开始根据平台数据进行对账，平台长期支付记录在缓冲池中。对账以银行渠道的数据为准。对于订单的所有数据，找出订单号相同的订单，比较订单金额和手续费是否一致。如果一致，则跳过；若不一致，平台订单进入错误池；如果在银行订单中没有找到该笔交易，则订单进入缓冲池，记录平台长支付。同时统计相关对账金额和订单数量。基于银行订单的对账逻辑：基于银行交易数据，遍历所有平台交易（包括未成功的订单），找出订单号相同但支付状态不一致的订单，比对后将金额存入错误池。如果在平台的交易中没有找到该订单，则通过缓存池查找对应的平台订单，验证金额是否一致，不一致的进入错误池。如果在缓冲池中仍然没有找到对应的订单，则直接进入错误池，并在平台上记录丢失的订单。同时统计相关对账金额和订单数量。5.对账统计根据对账流程，统计相关信息包括：对账完成时间、对账是否成功、余额金额及订单数、错误金额及订单数、缓冲池金额及订单数量等6.错误处理一般系统中，错误处理有两种，一种是手动的，一种是自动的。主要有以下几种情况：本地没有支付，但是支付渠道支付了。这主要是本地没有正确接收到通道发送的异步通知导致的。一般处理是修改本地状态为已支付，并做响应的后续处理，比如通知业务方等，本地已经支付，支付通道已经支付，但是金额是不同的。这需要人工验证。本地已支付，但支付渠道无记录；或者本地没有记录，但是支付渠道有记录。除了排除跨日因素外，这种情况非常少见，需要了解具体原因后再处理。示例代码网上对账系统的开源代码不多，但有一个还不错：火龙果支付。火龙果支付有一个比较完整的对账流程。代码以微信和支付宝的对账语句为例，编写了对账流程。你可以参考一下。roncoo-pay【本文为专栏作者《纯洁的微笑》原创稿件，转载请微信联系作者♂获得授权】点此查看作者更多好文
