在互金行業和支付行業，經歷過的同事都知道壹個詞:資金流失。顧名思義，就是資金流失。
系統級別:
人為原因:
妳可能想多了，我不想寫。哈哈。
壹般來說，只有付出了錢，才會發生資本損失。也就是公司層面的資本損失。在押金的情況下，會出現用戶重復扣費，導致用戶投訴，影響客戶體驗。當然也有成功不扣錢的場景，如果當作成功，也會造成資金損失。
所以要特別註意資金的日常處理。這筆錢如果處理不當，極有可能給公司造成不可估量的損失。
當然，我們並不是要求每個人都忽略押金的處理。押金處理不當會造成大量客戶投訴，也會降低企業客戶的粘度，從而降低用戶的活躍度，使其流失。當然，在我上面提到的場景中，投資也會造成公司的資金損失。
特殊場景是用戶扣費失敗，但被視為成功。給用戶的電子賬戶加錢，然後用戶提現。那麽，資本損失就會立即發生。
1.重復付款:
對於互金行業的同胞來說，這種重復支付的操作並不陌生。
那麽，如何避免重復支付呢？
不同的場景采用不同的策略。這裏稍微提壹下。因為場景復雜，時間可能有限，不方便碼字太多。
業內通行的做法是下遊系統控制上遊系統冪等。比如第三方金融機構調用支付寶的接口，妳會發現支付寶的開放平臺要求妳先獲取壹個支付單號。這個數字是唯壹的。然後跳轉到自己的平臺，填寫支付信息。您需要攜帶此id進行所有後續支付操作。支付寶這麽做的目的之壹，就是把它作為冪等和單滴查詢的機制。
2.映射返回代碼時出錯:
對於沒有類似經歷的人來說，打擊是毀滅性的。因為沒有這個概念。
有壹次看到團隊的壹個小夥伴直接把正在進行的交易當做失敗來處理，我驚呆了。
好了，言歸正傳，返回代碼，是下遊對上遊調用的響應。
如果上遊解析了下遊的失敗返回碼，則解析為成功，反之，則解析為失敗。結果可想而知。。。。。
當然，壹般有兩種返回碼。如果接手銀行渠道，應該會有壹個印象:壹個是通信返回碼；另壹種是交易或支付的返回碼。
我們需要處理這兩個返回代碼。分兩個層次來判斷。
以上是通用做法，公式可以套用。
當然，返回代碼需要分層映射。對於底層來說，可能偏於制度層面。對於上遊或業務系統，需要將業務層面轉化為用戶能夠理解的描述。
比如前段時間，我們的業務和技術糾結於“撤”和“撤”。其實從業務的角度來說，是希望用戶能夠了解和明確目前的運營情況。從技術角度來說，我們可能會從系統層面來看問題。
3.處理過程中交易處理不當
對於正在處理的事務，我們通常的做法是將其記錄為正在處理。然後通過查詢檢查最終交易的狀態。而不是簡單的把它當做失敗或者成功。
當然，這裏還有另壹種思路。供妳參考。
在業務緊急情況下，壹些交易可以通過立即失敗或成功來處理。當然，要區分存取款。
以上兩個方案在壹定程度上保證了來公司的資金安全。
。。。。。。電腦壞了。。。明天繼續。