背景

随着互联网这阵风的刮起，金融跟着火了一把。大概在13年左右，互联网金融也成为大家耳熟能详的一个名词。
在互金行业和支付行业，有过经历的同事都知道一个词：资损。顾名思义，就是资金损失。

资损产生原因

系统层面：

• 支付重复发生。
• 返回码映射错误。
• 处理中交易处理不当。
• 账务或者交易处理异常。

人为原因：
你可能想多了，我不想写。哈哈。

资损发生的场景

一般在出金的情况下，才会有资损的发生。即公司层面的资损。而对于入金的情况，一般会对用户产生重复扣款，导致用户投诉，影响客户体验。当然，也有一种场景，就是未扣成功，当作成功处理，也会产生资损。

所以，我们在日常处理资金的时候，尤其要注意。对于出金，如果处理不好，那么极有可能造成公司的难以估量的损失。

当然，也不是要大家忽略入金的处理。入金处理不当，造成大量的客户投诉，也会降低公司客户的粘度，从而降低用户的活跃度，使用户流失。当然，入金在我上面提到的场景中，也会造成公司资损。

特殊的场景是，用户扣款失败，但是当作成功处理。给用户电子账户加钱，然后用户进行提现。那么，资损立刻发生。

原因分析和应对方案

• 出金的场景：提现，自动赎回，人工赎回，转账等支付或者代发操作。
• 入金的场景：充值，购买等代扣行为。

1、支付重复发生：

对于互金行业的同胞来说，重复支付这种操作一点不陌生。

由于系统业务逻辑没有控制好，导致重复支付。如没有对返回码做正确的处理，那么上游业务系统认为是失败的，就会重复发送支付请求。造成资金损失。

由于通讯组件没有用好，导致支付重复的请求。这里很常见的的情况如下：我们在往银行后者第三方发送请求的时候，通常会用apache的httpclient或者netflix的feign组件。但是他们在通讯层面都是有重试策略的。对于readtimeout或者connectiontimeout，都会进行一定规则的重试。所以我们在用这些组件的时候，一定要了解他们的特性，推荐做法是将重试策略关闭。用掉单查询来进行支付请求结果的补偿。掉单机制后面会提及。

那么，如何来避免支付的重复发生呢？

不同的场景采用不同的策略。这里稍微提及下。因为场景复杂，可能时间有限，不便于过多的码文字。

行业内通俗的做法是下游系统对上游系统做幂等的控制。举个例子，第三方金融机构如果调用支付宝的接口，你会发现，支付宝的开放平台，要求你先获取一个支付单号。这个单号是唯一的。然后跳转到自己的平台，进行支付信息的填写。后续做的所有的支付操作，你都需要带着这个id。支付宝之所以这么做，其中一个用途，就是用这个来做幂等和掉单查询的机制。

2、返回码映射错误：

这个对于没有类似经验的人来说，打击是毁灭性的。因为根本没有这个概念。
我曾经看到团队的一个小伙伴，对于处理中的交易，直接当失败来处理，但是我惊呆了。

ok，言归正传，返回码，是下游对上游调用的一个响应。

如果上游将下游的返回失败的返回码，解析处理成成功，或者相反，解析成处理失败。那么可想而知，结果。。。。。

当然，返回码一般会有两种。如果接过银行渠道的同学，应该有印象：一种是通讯返回码；另一种是交易或者支付的返回码。

我们需要对这两种返回码做处理。分两层来判断。

如果通讯失败，那么交易失败。
如果通讯成功，交易成功，那么成功。
如果通讯成功，交易失败，那么失败。
其他情况，都是处理中。

以上是通用做法，公式套用即可。

当然，返回码需要分层来映射。对于底层来说，可能偏系统层面。对于上游或者业务系统来说，偏业务层面，需要转换成用户看得懂的描述。

比如，我们前段时间，业务和技术在纠结的“撤标中”和“已取消”。其实业务的角度，是希望用户能明白，明确目前操作的状况。而技术的角度，可能会站在系统层面看问题。

3、处理中交易处理不当
对于处理中的交易，我们通俗的做法是，记录成处理中。然后通过查询来查回最终交易的状态。而不是单纯的当作失败或者成功来处理。

当然，这里还有另外一种思路。供大家参考。
在业务紧急的情况下，有些交易是可以通过立即失败或者成功来处理的。当然，需要区分入金和出金。

对于出金，如果业务要求，那么可以在适当的掉单查询后，做成功处理。

对于入金，如果业务要求，那么也可以在适当的掉单查询后，做失败处理。

以上两种方案，在一定程度上保证来公司的资金安全。

。。。。。。电脑没电了。。。明天继续。