服務端如何防止重複支付

如圖是一個簡化的下單流程，首先是提交訂單，而後是支付。支付的話，通常是走支付網關（支付中心），而後支付中心與第三方支付渠道（微信、支付寶、銀聯）交互，支付成功之後，異步通知支付中心，支付中心更新自身支付訂單狀態，再通知業務應用，各業務再更新各自訂單狀態。

這個過程當中常常可能遇到的問題是掉單，不管是超時未收到回調通知也好，仍是程序自身報錯也好，總之因爲各類各樣的緣由，沒有如期收到通知並正確的處理後續邏輯等等，都會形成用戶支付成功了，可是服務端這邊訂單狀態沒更新，這個時候有可能產生投訴，或者用戶重複支付。

因爲③⑤形成的掉單稱之爲外部掉單，由④⑥形成的掉單咱們稱之爲內部掉單

爲了防止掉單，這裏能夠這樣處理：

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

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

三、支付中心收到支付結果之後，將結果同步給業務系統，能夠發MQ，也能夠直接調用，直接調用的話要加劇試（好比：SpringBoot Retry）

四、不管是支付中心，仍是業務應用，在接收支付結果通知時都要考慮接口冪等性，消息只處理一次，其他的忽略

五、業務應用也應作超時主動查詢支付結果

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

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

一、建立訂單的時候，用訂單信息計算一個哈希值，判斷redis中是否有key，有則不容許重複提交，沒有則生成一個新key，放到redis中設置個過時時間，而後建立訂單。其實就是在一段時間內不可重複相同的操做

附上微信支付最佳實踐：