可以说，对账是支付系统最头疼的事情。每一笔交易，都要做到各参与者的记录能够吻合，没有偏差。对账系统的工作，是发现有差异的记录，即轧帐；然后通过人工或者自动的方式，解决这些差异，即平帐。
对账介绍
看这篇文章的相信大家对支付都有了解，对于对账来说应该不陌生，肯定也明白对账的目的。简单例子，就是你和另外一个人做生意，约定的结款是月结，他每天都从你这里进货，你会记账说我应该收多少钱，他也会记账说他应该付多少钱；在月底结款的时候，他会说我应该结1w给你；然后给你一个进货的明细单子，你拿着这个单子和你自己的单子对比看是否正确，这就是对账。只是支付系统的对账涉及到其他账务处理事情相对感觉会比较复杂而已。
对账，我们一般称为勾兑，支付系统的对账，包含着两个层面：
- 支付系统内部间的对账，支付系统一般是分布式的，整个支付系统被拆分成了多个子系统，如交易系统、账户系统、会计系统、账户系统，每个子系统在处理各自的业务，系统间的对账，就是以上系统的核对，用于修正内部系统的数据不一致。
- 支付系统与渠道的对账，这里的渠道泛指所有为支付系统提供代收付业务的渠道，如：第三方支付公司、银行、清算中心、网联、银联等。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
为什么需要对账？
正常支付的情况下，两边（我们/第三方支付渠道）都会产生交易数据，那支付对账过程，两边数据一致，大家各自安好，不用处理什么。
但是有些异常情况下，可能由于网络问题，导致两边数据存在不一致的情况，支付对账就可以主动发现这些交易。
对账可以说支付系统最后一道安全防线，通过对账我们可及时的对之前支付进行纠错，避免订单差错越积越多，最后财务盘点变成一笔糊涂账
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
支付对账系统
开篇先来一张图，先来看下整体对账系统架构图：
整个对账系统分为两个模块：
- 对账模块
- 差错模块
对账模块，主要负责对账文件拉取，数据解析，数据核对，数据汇总等任务。差错模块是对账模块后置任务，对账模块核对过程产生无法核对成功的数据，这类数据件将会推送给差错系统。差错系统将会根据规则生成差错订单，运营人员可以在后台处理这列数据。
对账系统设计
对账系统如果从流程上来讲，其实非常简单
根据上面的流程，我们可以分为以下几个步骤
- 平台的数据获取
- 渠道文件获取
- 渠道账单数据解析器设计
- 对账数据的存储
- 交易对账项目的设计
- 交易对账结果管理
- 交易对账差错处理
平台的数据获取
这个其实很简单了，因为数据是从自己公司的平台上获取，你想怎么获取都行啦，反正是一个公司的，搞不好还是一个团队的呢，比如数据库，接口 或者是MQ都可以的拉，看你自己喜欢咯
渠道文件获取
银行，第三方支付，银联等，基本都会提供对账单下载的功能。不过也有少数工作做不到位或者太到位的银行，只提供账单查询后台，不提供对账单下载功能。
对开发人员来说，这里有几个坑：
- 对账单格式不一。文本，XML，csv的都有。为了后续能够统一处理，在账单下载完成后，需要进行标准化处理。
- 下载方式不一，HTTP，HTTPS，FTP的，都有。下载程序需要按照渠道的协议来处理。
- 下载时间不一，一般是凌晨1点后，到中午12才能用的也有。如果在预定的时间取不到数据，需要注意重试读取。
- 稳定性差。FTP服务器出问题那是常有的事。渠道侧解决方案往往就是重启。所以重试机制是必要的。
看一下第三方支付的对账单情况：
技术选型上，HTTP(S)用apache httpclient即可实现链接池和断点续传， FTP也可以使用Apache Commons Net API。但不管是哪一个，都需要设置重试次数和链接超时间。重试次数和间隔的设置需要小心，重试太频繁，容易把服务器打死.；时间间隔太大，又会阻塞后续处理步骤。5～10分钟是一个合适的重试间隔区间。
链接超时指在服务器出现问题时，连接在指定时间内获取不到数据即自动断开。这个很容易被忽略。
渠道账单数据解析器设计
这个设计是什么意思呢？就是说，可能我们拉了很多的不同渠道的账单，但是每个渠道的字段的命名不一样，那我们要把这些字段根据我们的理解映射到统一的字段当中，这样我们就可以无差别的处理不同的渠道了，但是这个就要具体情况去具体分析了
对账数据的存储
对账的时候肯定要考虑数据的存储，这块我觉得可以借助大数据平台去处理了
交易对账项目的设计
交易对账差错处理
发现两边不一致的数据，那应该如何处理？数据量不大时，记录起来，人工甄别就行。但如果数据量很大，每天上千条，人工处理就成本太高了。这个没有统一的处理方法，需要根据有问题的数据，做个分析，然后做自动处理。针对交易记录的对账的处理，主要有如下情况：
- 本地未支付，支付渠道已支付。这主要是本地未正确接收到渠道下发的异步通知导致。一般处理是将本地状态修改为已支付，并做响应的后续处理，比如通知业务方等。
- 本地已支付，支付渠道已支付，但是金额不同，这个需要人工核查。
- 本地已支付，但是支付渠道中无记录；或者本地无记录，支付渠道有记录。在排除跨日因素外，这种情况非常少见，需要了解具体原因后做处理。
针对退款的对账处理，主要有如下情况：
- 本地未退款，支付渠道已退款，则以支付渠道为准，修改本地为已退款状态，并触发后续处理。
- 本地已退款、支付渠道已退款，但是金额不同，需要人工核查；
- 本地已退款，但是支付渠道无记录；或者支付渠道有记录，但是本地没有。在排除跨日因素外， 这种情况非常少见，需要了解具体原因后做处理。
商户清结算
商户清结算是第三方支付系统核心的业务体系，商户清结算业务流程有可划分为支付流程、对账流程和结算流程三个小的业务体系，涉及商户、支付平台和银行（上游通道）三个部分。
商户清结算根据结算周期大致可分为D+0和T+1两种结算周期，当然在此基础上，可划分为D+0、D+1、D+2、T+1、T+2等等；D代表的是自然日，T代表着工作日；T+1属于正规结算流程，先对账后结算，不需要第三方支付系统垫资，第三方支付系统风险较小，商户支付手续费较低。
为了满足商户需求，第三方支付系统一般支持D+0结算方式，又称为实时到账，先结算后对账，需要第三方支付系统垫资，第三方支付系统风险较大，商户支付手续费较高。
商户T+1结算
商户D+0结算（实时结算）
结束
好了，今天的分享就到这里了，感谢大家阅读。
