服務端如何防止重復支付

1、五年工作經驗總結 16 條的代碼規(guī)范
2、突發(fā)！Apache Log4j2 報核彈級漏洞
3、都在建議你不要直接使用 @Async 注解，為什么？
4、面試官：拋開Spring來說，如何自己實現(xiàn)Spring AOP?
5、藍綠發(fā)布、滾動發(fā)布、灰度發(fā)布，有什么區(qū)別？這下明白了

概述

如圖是一個簡化的下單流程，首先是提交訂單，然后是支付。支付的話，一般是走支付網(wǎng)關（支付中心），然后支付中心與第三方支付渠道（微信、支付寶、銀聯(lián)）交互，支付成功以后，異步通知支付中心，支付中心更新自身支付訂單狀態(tài)，再通知業(yè)務應用，各業(yè)務再更新各自訂單狀態(tài)。

這個過程中經常可能遇到的問題是掉單，無論是超時未收到回調通知也好，還是程序自身報錯也好，總之由于各種各樣的原因，沒有如期收到通知并正確的處理后續(xù)邏輯等等，都會造成用戶支付成功了，但是服務端這邊訂單狀態(tài)沒更新，這個時候有可能產生投訴，或者用戶重復支付。

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

為了防止掉單，這里可以這樣處理：

1、支付訂單增加一個中間狀態(tài)“支付中”，當同一個訂單去支付的時候，先檢查有沒有狀態(tài)為“支付中”的支付流水，當然支付（prepay）的時候要加個鎖。支付完成以后更新支付流水狀態(tài)的時候再講其改成“支付成功”狀態(tài)。

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

3、支付中心收到支付結果以后，將結果同步給業(yè)務系統(tǒng)，可以發(fā)MQ，也可以直接調用，直接調用的話要加重試（比如：SpringBoot Retry）

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

5、業(yè)務應用也應做超時主動查詢支付結果

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

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

1、創(chuàng)建訂單的時候，用訂單信息計算一個哈希值，判斷redis中是否有key，有則不允許重復提交，沒有則生成一個新key，放到redis中設置個過期時間，然后創(chuàng)建訂單。其實就是在一段時間內不可重復相同的操作

附上微信支付最佳實踐：

文章來源：https://cnblogs.com/cjsblog/p/14516909.html

最近熱文閱讀：
1、五年工作經驗總結 16 條的代碼規(guī)范
2、為什么我勸你放棄了Restful API？
3、Java8 Stream：2萬字20個實例，玩轉集合的篩選、歸約、分組、聚合
4、公司規(guī)定所有接口都用 POST請求，這是為什么？
5、為什么阿里強制 boolean 類型變量不能使用 is 開頭？
6、面試官：InnoDB中一棵B+樹可以存放多少行數(shù)據(jù)？
7、MyBatis批量插入幾千條數(shù)據(jù)，請慎用foreach
8、有了 for (;;) ，為什么還需要while (true) ？到底哪個更快？
9、名企公開掛“加班真好”標語，員工稱一年被免費“白嫖”600多小時！網(wǎng)友看不下去了，稽查部門展開調查...
10、面試官：為什么 Java 不把基本類型放在堆中？我竟然答不上來。。
關注公眾號，你想要的Java都在這里