大廠是如何防止訂單重複支付的？三分鐘徹底搞懂！

如圖是一個簡化的下單流程，首先是提交訂單，然後是支付。

支付的話，一般是走支付網關（支付中心），然後支付中心與第三方支付渠道（微信、支付寶、銀聯）交互。

支付成功以後，異步通知支付中心，支付中心更新自身支付訂單狀態，再通知業務應用，各業務再更新各自訂單狀態。

這個過程中經常可能遇到的問題是掉單，無論是超時未收到回調通知也好，還是程序自身報錯也好。

總之由於各種各樣的原因，沒有如期收到通知並正確的處理後續邏輯等等，都會造成用戶支付成功了，但是服務端這邊訂單狀態沒更新。

這個時候有可能產生投訴，或者用戶重複支付。

由於③⑤造成的掉單稱之爲外部掉單，由④⑥造成的掉單我們稱之爲內部掉單

爲了防止掉單，這裏可以這樣處理：

  1. 支付訂單增加一箇中間狀態 “支付中”，當同一個訂單去支付的時候，先檢查有沒有狀態爲“支付中” 的支付流水，當然支付（prepay）的時候要加個鎖。支付完成以後更新支付流水狀態的時候再講其改成 “支付成功” 狀態。

  2. 支付中心這邊要自己定義一個超時時間（比如：30 秒），在此時間範圍內如果沒有收到支付成功回調，則應調用接口主動查詢支付結果，比如 10s、20s、30s 查一次，如果在最大查詢次數內沒有查到結果，應做異常處理

  3. 支付中心收到支付結果以後，將結果同步給業務系統，可以發 MQ，也可以直接調用，直接調用的話要加重試（比如：SpringBoot Retry）

  4. 無論是支付中心，還是業務應用，在接收支付結果通知時都要考慮接口冪等性，消息只處理一次，其餘的忽略

  5. 業務應用也應做超時主動查詢支付結果

對於上面說的超時主動查詢可以在發起支付的時候將這些支付訂單放到一張表中，用定時任務去掃

爲了防止訂單重複提交，可以這樣處理：

創建訂單的時候，用訂單信息計算一個哈希值，判斷 redis 中是否有 key，有則不允許重複提交，沒有則生成一個新 key，放到 redis 中設置個過期時間，然後創建訂單。

其實就是在一段時間內不可重複相同的操作

附上微信支付最佳實踐：

來源｜cnblogs.com/cjsblog/p/14516909.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7on6kUlNihvWgz6f0psxuw

猜你喜歡