一筆訂單，可是誤付了兩筆錢！這種重複付款異常到底該如何解決？|原創

封面送給我狗哥~

Hello，你們好，我是樓下小黑哥~

今天的文章咱們接着上次的話題，繼續聊聊支付系統異常解決辦法。

在上篇文章中「支付掉單異常解決方案」，咱們主要提到的是支付過程當中掉單的場景，用戶明明付款成功，銀行卡都扣款了，可是訂單卻還顯示待付款。

而在今天的文章中，咱們將聊到重複付款的異常，即同一筆訂單，扣了用戶兩筆錢。

另外咱們還將會提到另一種異常，用戶扣款成功，可是訂單卻支付失敗的場景。

以上兩種異常對於被扣款的用戶來說，使用體驗極差，本身多付了錢，訂單卻還不成功。因此若是不及時處理這兩類異常，那就真的等着被投訴吧。

歡迎關注個人公衆號：程序通事，得到平常乾貨推送。若是您對個人專題內容感興趣，也能夠關注個人博客： studyidea.cn

重複付款異常

異常場景

重複付款異常通常常見於網銀支付，微信支付，支付寶等這類須要跳轉到一個支付網關頁（網銀支付），或者跳轉到錢包 APP(支付寶、微信)，從而異步完成扣款的支付場景。

這種支付場景下，只能經過接受異步通知才能知道支付結果，咱們通常將其稱爲異步支付。

PS：有了異步支付，那麼同步支付是什麼？

其實同步支付指的就是調用支付接口以後，就能夠馬上返回支付結果的，好比銀行卡類快捷/代扣等支付就是同步支付。

固然也有一些奇葩的銀行卡支付渠道，同步支付結果爲受理成功，只能接受異步通知或者查詢返回支付結果。

因爲銀行卡支付須要返回明確支付結果，對於這類渠道只能內部設計將異步轉爲同步,感興趣能夠看下以前歷史文章：

架構設計|異步請求如何同步處理？

後臺支付流程以下：

圖片來自以前的文章: 銀行卡支付原理

爲何會發生重複付款？

主要緣由其實跟上次內部掉單異常同樣，跟業務表設計有關。

上次咱們提到，支付系統主要表結構以下：

在這個表結構下，只要支付訂單未成功，商戶就能夠重複使用其內部同一訂單號調用支付接口。

假設這樣一個場景，用戶在收銀臺支付時選擇招行進行網銀支付，當他點擊支付以後，商戶系統將會調用支付公司的網銀接口。

這時支付系統內部將會建立一筆支付單以及關聯的渠道訂單，而且調用招行系統的接口。

而後用戶的瀏覽器頁面將會打開一個新頁面，而後跳轉到招行網站。

這時若是此時用戶再次在收銀臺點擊支付，將會再次調用支付系統接口。這時候因爲支付單已存在，因此僅僅會再建立一條渠道訂單記錄，而且調用招行系統的接口。這時用戶的瀏覽器將會再次打開一個招行的網站。

若是用戶在兩個招行網銀頁都完成支付，這時就發生了重複付款。

上面這種場景看起來有點傻,可是真實用戶操做真的會發生。除了這種，博客園上的小夥伴還提到這麼下面這種狀況：

解決辦法

重複付款異常的主要的解決辦法有兩種，分爲事前與過後。

事前主要的目是儘量防止用戶重複付款，主要解決辦法爲優化付款頁面，儘量作好提示。

第一種優化方式，付款頁面直接跳轉到第三方/銀行的網銀頁面，不要打開新的頁面去跳轉。

這種方式能夠防止用戶誤打開兩個網銀付款的頁面，從而致使重複付款。

可是這裏會有一個問題，銀行網銀頁面付款成功以後，用戶如何知道其在商戶側訂單狀態也成功了？

其實很簡單，如今網銀支付接口，通常都會有一個參數 return_url:同步跳轉地址 。

只要在接口傳入這個地址，當支付成功以後，頁面最終就會跳轉到這個傳入的地址，商戶側就能夠在地址顯示訂單是否支付成功。

上面咱們提到，用戶有可能會使用瀏覽器回退功能，跳轉到支付頁，從而致使重複付款。

對於這種狀況，咱們能夠在其回退支付頁時，首先向後臺查詢這筆訂單支付結果，若是已支付成功，那就直接顯示成功頁面。

第二種優化，對於這種從新打開一個頁面跳轉到銀行網站，咱們能夠在頁面加入彈窗提示，詢問用戶是否已支付完成。

好比上面這種處理方式，當用戶點擊確認完成充值，能夠立刻向後臺發起查詢訂單狀態。

下面來聊聊過後的解決辦法，其實解決辦法很簡單，發起內部退款，將多餘支付的一筆反向退款回去。

支付系統內部能夠有個定時任務，定時掃描支付單下有多條成功渠道訂單的記錄，而後選擇將重複支付渠道訂單發起退款。

這種方式是支付公司系統內部的操做，不須要商戶側發起指令。

訂單失效異常

異常場景

這種場景通常常見於電商購物，秒殺等購物場景。當用戶下單以後，頁面將會開始倒計時，用戶須要在有效期內支付成功。

假設用戶點擊跳轉到支付寶，可是其沒有馬上支付，而是停留了好久，在訂單最後一秒時間內完成了支付，可是這個時候訂單早已由於時間到期而被自動取消。

這樣就發生用戶扣款已經成功，可是訂單倒是失敗或關閉的場景的。

另外還有一種狀況，用戶在有效期內支付成功，可是由於網絡、內部應用等問題，支付結果的異步通知過了好久才收到，這時內部訂單的早由於時間到期而被取消。

解決辦法

第一種解決辦法，上送有效期給支付渠道。

通常支付接口都會有一個支付有效期的字段，代表這筆支付最晚能夠支付的時間。若是超時未支付，這筆支付將會被關閉。

固然通常狀況下，若是未上送，這個字段內部通常會有個默認的有效期，好比 3 天，這個時間就比較長了。

因此當調用支付接口時，能夠將訂單剩餘有效期傳入支付接口。這樣用戶若是在超時時間內未完成支付，支付將會失敗。

第二種解決辦法，內部發起退款。

這個解決辦法依然過後託底的解決辦法，對於支付訂單已關閉，可是支付卻成功的狀況，發起內部退款，將錢退給用戶。

內部能夠有個定時任務，定時掃描支付訂單已關閉可是支付卻成功的狀況，而後發起退款指令。

最後

最後用思惟導圖方式幫你們總結一下支付系統可能會碰到的異常。

歷史支付系統相關文章

1. 收款神器！解讀聚合收款碼背後的原理|原創
2. 手機沒網了，卻還能支付，這是什麼原理？|原創
3. 輕輕一掃，馬上扣款，付款碼背後的原理你不想知道嗎？|原創
4. 支付渠道路由系統進化史
5. 從零開始設計對帳系統