Payment system owned loss analysis

1. Capital loss

Financial losses, a number of users deduction shall result in financial losses of users, but also how the gold or recharge lead to loss of funds to pay the company .

2. Capital loss analysis

   1. To keep up with the interactive system downstream

2.1.1 Repeat Request or repeated request

System interaction occurs at the junction, the callee repeated orders initiated with a business, or with an order to initiate calls to other systems more than two requests, if the interaction of the two sides , " the same order " understanding is not uniform, not associated with the system of " with an order " precautions against heavy process, will lead to a repeat or duplicate gold deposit.

2.1.2 return the result of the interaction code

Others need to explicitly call system return code meaning distinction represents the communication results or results of operations, usually return code mapping to the case failed because the majority is not a real business failure, there is no overtime, it also returns results by failure deal with the case, it can also cause loss of capital. For when someone calls our system, we try to return as little as possible, try to clear the return code, the other party if handled properly, then there will be capital loss.

2.1.3 Concurrent

Only in the code re-sentence order is not enough, if not well controlled, concurrent, when an order arrives the same time, the program determines that no single history are the next step in the business process, capital loss will occur.

2. Internal logic error

2.2.1 business logic processing procedure

Business processes follow the normal business process, if the process is not strictly fit the program criteria, such as the first and then deducted the amount of gold out of the process without first deducting the amount of gold went to make a business, and then, or during such an important amount of data processing, payee information has been changed capital loss will occur.

2.2.2 Fee

Because of better scene fee is deducted with the main business carried out separately, the fee is not deducted, multi-clasp buckle are less easy to find, so here are also at risk of capital loss.

2.2.3 Conversion Amount

In some relatively high precision scene, some database support is not enough, we need to turn into a decimal integer to store and read at this time if not handled properly, will result in capital losses.

2.2.4 state control

状态在订单的流转处理中扮演着非常重要的角色，每种状态的变化是有顺序的，每个状态下能做的业务处理也是有限制的，如果在某个状态下做了不该做的事情，或者状态转换时跳过了设定的状态，就有可能会发生资损。

3. 安全漏洞

2.3.1 伪造请求数据

报文被别有用心的人截取后，伪造请求报文发起出金请求，一旦安全机制薄弱的话会造成资损

2.3.2 内部人员调用系统

内部人员根据系统漏洞，模拟异步通知结果混淆当前系统，将本不该处理的订单处理状态，引发后续一系列操作，可能会造成资损。

2.3.3 人为修改数据库

如果数据库人为修改出金金额或者状态等关键信息，如果不能识别的话会造成资损

4. 人工处理

人工处理异常订单时往往跟系统自动处理的逻辑不一致，导致有可能会重复处理业务，或者在人工处理时与系统自动处理并发导致资损。

3. 解决方法

   1. 唯一商户订单号

防重表或数据库对商户号+商户订单号做唯一索引约束，控制请求的是否重发

2. 解决并发问题

基于redis分布式锁

基于数据库排他锁

增加审核机制，人工排除并发，然后再进行后续处理

3. 白名单

系统白名单，重点系统交互比如在异步通知回调接口要识别回调报文的来源，对指定的Ip断才认为是合法的。

业务白名单，重点业务对重要标识比如交易双方、业务主体等做的白名单，控制业务的影响范围。

4. 风控黑名单或商户授权联动控制

通过风控系统或者商户控制中心对发现的可疑商户及时制止交易，联动业务系统，达到防止资金损失的效果。

5. 订单、流水和状态

业务逻辑处理中为减少失误，需要依赖两个点，一个是订单、流水，另一个是状态。订单记录了一笔业务的详细信息，状态是订单状态，描述的是业务处理过程中的某个点，流水是资金变化的依据。处理过程中做能做哪些事情由当前和相邻状态决定，资金操作以之前的资金流水为依据判断是否可以执行。

6. 防篡改

接口请求需登录，请求报文加时间戳和签名。

数据库对重要记录加签存储，做业务前判断。

结合白名单，拒绝接受不明请求。

4. 预防和监控

   1. 事前

事前监控主要是功能在上生产环境前的一系列测试，包括开发人员自测测试人员测试和生产模拟环境测试，任何改动都不能不经测试直接放生产环境。

开发完成后要对做单元测试和接口测试。单元测试可以保证重点逻辑各个分支处理的准确性，接口测试可以保证整个业务大体的贯通。

测试人员结合用例进行充分的功能测试和集成测试。

生产模拟环境测试要测试通过。

2. 事中

出金前检查资金链路，一旦有问题，立即熔断，标识异常，拒绝出金，后续由人工介入处理。

数据库日志监控，根据数据库日志，检测到人为变更时，做关联的检查，资金链路有问题时会触发报警提示。

3. 事后

系统上下游之间的对账。正常情况下交互的系统间调用是一一对应的，对于发生异常或是由于通讯等原因双方有未完成状态的需要进行系统对账。

资金流和信息流关于出入金汇总对账。这种对账可以从宏观上把控资金往来的准确性，能够发现多入金或者多出金的情况。