如何設計避免訂單出現重復支付的邏輯
1，問：假設有這麽一種情況：
訂單已下單成功並且正處於支付頁面，用戶調起支付網關進行支付。支付成功了一次，但是由於某種情況導致未接收到銀行返回的【支付成功】等信號，系統此時還是認為未支付成功。用戶此時又支付了一次並且成功了。
問題：
如果用戶出現了2次支付並且都成功了，後臺邏輯退款這一塊如何設計？
是否可以避免這種情況的發生？如果可以怎麽去避免呢。
2，以下由網友回答，僅作參考：
參考1）
A.後臺設計邏輯：
1.參與的主體：
電商系統
網銀或者第三方支付平臺
電商用的結算平臺(例如商戶支付寶，商戶翼支付等)
2.設計的主要流程：
電商系統調起網關支付，訂單跳轉到網銀或者第三方支付平臺中進行實際支付，這時訂單中包含的信息是由電商用的結算平臺先生成的一個支付訂單信息(這個支付信息包含與電商系統與網銀或者第三方支付平臺的關聯)；用戶在網銀或者第三方支付平臺中進行實際支付(這個支付交互是網銀或者第三方支付平臺與結算平臺的交互)，成功之後才是結算平臺反饋支付信息給電商系統。
下列圖中
是用戶調起網關支付，訂單跳轉到網銀或者第三方支付平臺中進行實際支付。
是用戶支付成功後，訂單反饋至電商系統。
現在出現重復付款的問題就是出現在中的網銀或者第三方支付平臺到電商用的結算平臺出現了延遲的情況，導致在電商系統中的訂單一直處於未付款狀態，部分用戶以為未支付就最終產生了重復付款。
B.如何避免
針對這個問題，思考了各種場景以及情況，這種模式是無法避免重復付款的（必須得看結算平臺的處理效率-一般情況下還是比較好的，還是少有延遲的情況）。只能後臺檢測重復付款的訂單，異常走退款流程。
除非系統本身具有支付平臺的功能。
C.延伸問題，如何處理因為支付成功後因延遲回調而訂單被取消
這個問題的出現背景也是因為第三方結算平臺延遲反饋而造成用戶錯以為沒有支付而取消訂單或者是系統到時時自動取消訂單
解決辦法：
建立異常處理機制，機制如下：
結算平臺延遲返回成功的支付信息給電商系統時，如果判斷出此訂單已經取消。則進入異常處理機制，更改訂單為已收款狀態，並再次扣減訂單中庫存以及各種優惠（例如：價保，返利，促銷費，優惠等等）的回退。當然再此扣減的時候需要先判斷相關產品的庫存以及用戶的各種優惠是否滿足訂單的扣減，不滿足則不允許轉化。
這裏是應該先判斷再次扣減的庫存以及各種優惠，再修改訂單狀態，步驟以及相關的支付信息為成功。
參考2）
第三方返回的狀態實際是3種，返回成功，返回失敗和無返回。當無返回時，如果處理成返回失敗，就會讓用戶支付兩筆，這本身是一種最糟糕的選擇。沿著這個最糟糕的選擇去做退款邏輯，是錯上加錯。
我們應該引入一個單獨的支付層，它可以做兩個事情：1.delay第2次支付請求 2.通過另一組接口查詢第1次支付狀態。 在最無能為力的情況下，提示用戶異常並在24小時內對賬後處理解決。當然用戶如果確實急的不行，另下一單即可。
說回真實情況，支付寶等第三方成熟的支付平臺，自然會根據重復的購物訂單號來做好預防
參考3）
問題：
如果用戶出現了2次支付並且都成功了，後臺邏輯退款這一塊如何設計？
這塊其實要通過賬務的對賬長款能區分出來，理論上來講第二天支付通道返回的交易流水文件每一筆跟你的訂單交易記錄是一一對應的。一旦有一筆訂單支付N次的話，則可能出現一個現象就是支付通道返回的交易流水會多出（N-1）筆，那這些就是長款，財務確認無誤後可以手動發起退款。
是否可以避免這種情況的發生？如果可以怎麽去避免呢。
理論上每一筆訂單發起支付的時候都會有統一下單的過程，會把訂單單號作為外部交易流水號加上其他信息打包去支付方生成支付訂單，如果一筆訂單在支付方已經支付的話，用戶再次打開這個頁面應該是會被提示訂單已支付。除非每次點擊“支付”生成的支付通道流水號都不是唯一，則可能出現。
同時，建議你在後端做一些未支付訂單主動查詢的動作，例如：最近15分鐘生成的未支付訂單後端主動查詢一下支付狀態”等等，可以優化這塊的困擾。
參考4）
1、如果用戶出現了兩次支付並且都成功了......
看你站在誰的角度去解決問題了，一般後臺都是有應付、實付、立減、優惠等字段的。1）等著用戶來找你（不找你的你幫公司賺了），2）財務對賬發現問題，3）你主動為用戶解決。至於回答中還有什麽根據流水來的，首先請求流水是控制不了得；返回成功流水，那可能是你們業務暫時不涉及到組合支付，分次支付...
2、怎麽解決？
前端：1）交互方式改變，有的是新開頁面，例如PC，如果同時開了兩個第三方頁面，那只能讓其繼續支付了（在沒收到消息前調起SDK也是一樣無法避免），有的是原頁面跳轉，這種也一定程度上避免了用戶打開很多頁面自己搞亂掉了再去發起支付。2）在選擇支付渠道，發生【去支付】動作時也可以做一個接口判斷，有沒全部付完款？在這之前還有訂單及業務資源等一系列判斷，與此題無關。
系統：支付頁設置定時器，維金系統中查詢功能也蠻好的，支付請求開始後，半小時之內去跟蹤狀態，查詢頻率由高到低。有開始你就要去考慮終止，涉及到資源問題要依據自己公司的情況，想法跟落地從來都是矛盾的。
最後，第三方信息返回延遲，失敗率都沒有想象中的那麽不友好。場景上，例如移動端支付寶微信會有個支付後的等待動作，不會立馬再讓你去發起【去支付】。我的經歷一般重復支付這樣的問題都是內部支付系統跟訂單系統太不穩定導致的...
參考5）
接口支持冪等性的話，同一條流水只會執行一次，就算無返回，再次發起時會直接返回結果，不會執行的。
---------------------
作者：未名who
來源：CSDN
原文：https://blog.csdn.net/qq_2300688967/article/details/79319656
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
如何設計避免訂單出現重復支付的邏輯