"Continue to create, accelerate growth! This is the second day of my participation in the "Nuggets Daily New Plan · June Update Challenge", click to view the details of the event "
It can be said that reconciliation is the most troublesome thing in the payment system. For each transaction, the records of each participant must be consistent with no deviation. The job of the account reconciliation system is to find discrepancies in the records, that is, account balance; and then resolve these differences manually or automatically, that is, account balance.
Introduction to Account Reconciliation
I believe that everyone who reads this article has an understanding of payment. They should be familiar with reconciliation, and they must also understand the purpose of reconciliation. A simple example is that you do business with another person. The agreed settlement is monthly. He buys from you every day. You will keep a book and say how much I should charge, and he will also keep a book and say how much he should pay. ; When the payment is settled at the end of the month, he will say that I should pay you 1w; and then give you a detailed list of purchases, you can compare this list with your own list to see if it is correct, this is the reconciliation. It's just that the reconciliation of the payment system involves other accounting processing and it feels relatively complicated.
Reconciliation, we generally call it blending, the reconciliation of the payment system includes two levels:
- For reconciliation within the payment system, the payment system is generally distributed, and the entire payment system is divided into multiple subsystems, such as transaction system, account system, accounting system, and account system. Each subsystem handles its own business. The inter-system reconciliation is the reconciliation of the above systems, which is used to correct the data inconsistency of the internal system.
- Reconciliation between payment systems and channels. The channels here generally refer to all channels that provide collection and payment services for the payment system, such as: third-party payment companies, banks, clearing centers, Wanglian, UnionPay, etc.
Why do you need reconciliation?
In the case of normal payment, both parties (our/third-party payment channels) will generate transaction data. In the payment reconciliation process, the data on both sides are consistent, and everyone is safe and does not need to deal with it.
However, in some abnormal cases, there may be inconsistencies in the data on both sides due to network problems, and payment reconciliation can actively discover these transactions.
Account reconciliation can be said to be the last security line of defense in the payment system. Through account reconciliation, we can correct the previous payment in time to avoid the accumulation of order errors, and the final financial inventory becomes a confused account.
payment reconciliation system
Let’s start with a picture first, let’s take a look at the overall reconciliation system architecture diagram:
The entire reconciliation system is divided into two modules:
- Reconciliation module
- error module
对账模块，主要负责对账文件拉取，数据解析，数据核对，数据汇总等任务。 差错模块是对账模块后置任务，对账模块核对过程产生无法核对成功的数据，这类数据件将会推送给差错系统。 差错系统将会根据规则生成差错订单，运营人员可以在后台处理这列数据。
对账系统设计
对账系统如果从流程上来讲，其实非常简单
根据上面的流程，我们可以分为以下几个步骤
- 平台的数据获取
- 渠道文件获取
- 渠道账单数据解析器设计
- 对账数据的存储
- 交易对账项目的设计
- 交易对账结果管理
- 交易对账差错处理
平台的数据获取
这个其实很简单了，因为数据是从自己公司的平台上获取，你想怎么获取都行啦，反正是一个公司的，搞不好还是一个团队的呢，比如数据库，接口 或者是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属于正规结算流程，先对账后结算，不需要第三方支付系统垫资，第三方支付系统风险较小，商户支付手续费较低。
In order to meet the needs of merchants, the third-party payment system generally supports the D+0 settlement method, also known as real-time arrival, first settlement and then reconciliation, which requires a third-party payment system to advance funds, the third-party payment system is risky, and the merchant pays the handling fee higher.
Merchant T+1 settlement
Merchant D+0 settlement (real-time settlement)
Finish
Alright, that's all for today's sharing. Thank you for reading. I'm Xiao Liuliu.