在交易支付的流程中，总会出现一些损耗，这种资损的处理比较麻烦。这篇文章，作者总结了其中的经验，希望可以帮到大家。

一、资损定义和分类

1. 定义

资损指的是在业务活动过程中，由于业务规则与实际资金流动存在不一致的情况，致使业务参与方中的一方乃至多方承受了资金损失。

2. 资损分类

站在平台/公司的角度，资损分长款资损和短款资损。

长款资损，多收了用户的钱，如重复代扣，重复支付，或算多了扣款金额。虽然不直接亏钱，也可以给用户退钱，但是也浪费用户时间、客服资源，而且可能存在互联网舆论问题。

短款资损，少收用户钱，或者多给用户钱/货/权益。占用公司客服，催收资源，而且追不回来直接亏钱。

二、通道接入时防资损

1. 状态码问题

错把判断接口操作成功的字段，当作定义支付业务是否成功的字段。

务必要跟通道方穷尽明确，哪些状态码是成功、哪些是失败，其余应该归为中间状态，包括空值等异常。

2. 支付结果查询问题

错把查询操作失败当作交易失败

切记发起交易结果查询接口失败，不等于交易失败，不能漏判断这个点。

查询速度过快

交易刚完成就反查交易状态，查询接口返回“无此订单/订单不存在”，可能是银行交易链路长，查询请求先到。若据此将交易视为失败处理，会引发上游系统重试，导致重复支付。

建议对接时咨询接口提供方查询频率，了解多久后能查询；或定义查询策略，报错后 N 时间再查一次，若一直报错，N 时长后置为失败。

3. 通知问题

通道方通知的结果不一致

如通道方出现多次通知结果前后不一致，则建议以第一遍的通知为准，后续通知不更新状态，且告警出来人工干涉。

同步结果覆盖异步通知结果

接口发起支付的时候没得到终态，而异步通知来得快，把订单改了终态。此时发起支付后的程序又把订单改成中间态，并触发后续的业务。

这个时候有人可能会说，等待下一次中间态查询的补偿任务即可，但是如果下游业务没做好幂等，就G了。

因此建议，支付状态不能从终态更新成处理中状态，不能从一个终态更新成另外一个终态，如把成功改为失败，或者失败改为成功。

4. 单位问题

明确通道方金额的分元单位、货币单位等，若内外部系统单位不一致，及时进行单位转换。同时关注金额精度问题。

三、扣款/支付时防资损

1. 支付中问题

业务一定要考虑、设计支付中状态。

2. 防重复扣款

系统代扣

后端按支付订单号幂等，支付中/支付成功状态下不允许发起新支付。

主动支付

前端防抖。

前端支付中状态付款按钮置灰禁用。

后端按支付订单号幂等，支付中/支付成功状态下不允许发起新支付。

3. 单位

前后端分元单位、货币显示要显示一致。

四、出金业务防资损

1. 防重复出金

根据业务单号防重

限制同一笔业务订单，只能同时存在在途或者成功1条出金记录。

根据业务特征防重

短时内同对象（卡号、身份证号、信用代码，对象编码等）。

短时内同金额。

2. 防大额出错

根据不同的业务特征制定出金限额

如单笔出金限额、平台单位时间之内（日、月、年）汇总出金限额、单对象单位时间之内出金限额

五、账户/钱包业务防资损

1. 涉及资金流的账户入账程序

加钱入账

如充值，一定是先用户支付成功（通道响应支付成功），再操作给用户账户加钱。

减钱入账

如提现、充值退款，一定是先操作用户账户减钱，再给用户原路退款/打款。

减钱时务必判断余额够不够。

如是充值退款，如充值的时候收了手续费，需明确退款是否退手续费，如手续费也退，判断余额够不够时，需要剔除手续费。

2. 操作账户的顺序

先插入流水，再操作余额加减，且务必上事务。

3. 入账防重

根据业务单号+流水类型/账户类型幂等。且需要将业务单号存进流水。

4. 提现失败后账户蓝字冲账

如业务涉及提现失败做冲账动作，需要注意以下点。

防重复给账户加钱

除了提现订单号判断防重外，带上原提现流水号做判断，如该提现流水号已存在冲账流水，则拒绝。

防算错金额

冲账要取当下最新的余额进行叠加，不能取原提现前余额。

如有提现手续费，需把提现手续费也退回，切记不要算错。