封面送給我狗哥~
Hello，大家好，我是樓下小黑哥~
今天的文章我們接著上次的話題，繼續聊聊支付系統異常解決辦法。
在上篇文章中「支付掉單異常解決方案」，我們主要提到的是支付過程中掉單的場景，使用者明明付款成功，銀行卡都扣款了，但是訂單卻還顯示待付款。
而在今天的文章中，我們將聊到重複付款的異常，即同一筆訂單，扣了使用者兩筆錢。
另外我們還將會提到另外一種異常，使用者扣款成功，但是訂單卻支付失敗的場景。
以上兩種異常對於被扣款的使用者來講，使用體驗極差，自己多付了錢，訂單卻還不成功。所以如果不及時處理這兩類異常，那就真的等著被投訴吧。
歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn
重複付款異常
異常場景
重複付款異常一般常見於網銀支付，微信支付，支付寶等這類需要跳轉到一個支付閘道器頁（網銀支付），或者跳轉到錢包 APP(支付寶、微信)，從而非同步完成扣款的支付場景。
這種支付場景下，只能通過接受非同步通知才能知道支付結果，我們一般將其稱為非同步支付。
PS：有了非同步支付，那麼同步支付是什麼？
其實同步支付指的就是呼叫支付介面之後，就可以立刻返回支付結果的，比如銀行卡類快捷/代扣等支付就是同步支付。
當然也有一些奇葩的銀行卡支付渠道，同步支付結果為受理成功，只能接受非同步通知或者查詢返回支付結果。
由於銀行卡支付需要返回明確支付結果，對於這類渠道只能內部設計將非同步轉為同步,感興趣可以看下之前歷史文章：
後臺支付流程如下：
圖片來自之前的文章:銀行卡支付原理
為什麼會發生重複付款？
主要原因其實跟上次內部掉單異常一樣，跟業務表設計有關。
上次我們提到，支付系統主要表結構如下：
在這個表結構下，只要支付訂單未成功，商戶就可以重複使用其內部同一訂單號呼叫支付介面。
假設這樣一個場景，使用者在收銀臺支付時選擇招行進行網銀支付，當他點選支付之後，商戶系統將會呼叫支付公司的網銀介面。
這時支付系統內部將會建立一筆支付單以及關聯的渠道訂單，並且呼叫招行系統的介面。
然後使用者的瀏覽器頁面將會開啟一個新頁面，然後跳轉到招行網站。
這時如果此時使用者再次在收銀臺點選支付，將會再次呼叫支付系統介面。這時候由於支付單已存在，所以僅僅會再建立一條渠道訂單記錄，並且呼叫招行系統的介面。這時使用者的瀏覽器將會再次開啟一個招行的網站。
如果使用者在兩個招行網銀頁都完成支付，這時就發生了重複付款。
上面這種場景看起來有點傻,但是真實使用者操作真的會發生。除了這種，部落格園上的小夥伴還提到這麼下面這種情況：
解決辦法
重複付款異常的主要的解決辦法有兩種，分為事前與事後。
事前主要的目是儘可能防止使用者重複付款，主要解決辦法為優化付款頁面，儘可能做好提示。
第一種優化方式，付款頁面直接跳轉到第三方/銀行的網銀頁面，不要開啟新的頁面去跳轉。
這種方式可以防止使用者誤開啟兩個網銀付款的頁面，從而導致重複付款。
但是這裡會有一個問題，銀行網銀頁面付款成功之後，使用者如何知道其在商戶側訂單狀態也成功了？
其實很簡單，現在網銀支付介面，一般都會有一個引數 return_url:同步跳轉地址 。
只要在介面傳入這個地址，當支付成功之後，頁面最終就會跳轉到這個傳入的地址，商戶側就可以在地址顯示訂單是否支付成功。
上面我們提到，使用者有可能會使用瀏覽器回退功能，跳轉到支付頁，從而導致重複付款。
對於這種情況，我們可以在其回退支付頁時，首先向後臺查詢這筆訂單支付結果，如果已支付成功，那就直接顯示成功頁面。
第二種優化，對於這種重新開啟一個頁面跳轉到銀行網站，我們可以在頁面加入彈窗提示，詢問使用者是否已支付完成。
比如上面這種處理方式，當使用者點選確認完成充值，可以馬上向後臺發起查詢訂單狀態。
下面來聊聊事後的解決辦法，其實解決辦法很簡單，發起內部退款，將多餘支付的一筆反向退款回去。
支付系統內部可以有個定時任務，定時掃描支付單下有多條成功渠道訂單的記錄，然後選擇將重複支付渠道訂單發起退款。
這種方式是支付公司系統內部的操作，不需要商戶側發起指令。
訂單失效異常
異常場景
這種場景一般常見於電商購物，秒殺等購物場景。當使用者下單之後，頁面將會開始倒數計時，使用者需要在有效期內支付成功。
假設使用者點選跳轉到支付寶，但是其沒有立刻支付，而是停留了很久，在訂單最後一秒時間內完成了支付，但是這個時候訂單早已因為時間到期而被自動取消。
這樣就發生使用者扣款已經成功，但是訂單卻是失敗或關閉的場景的。
另外還有一種情況，使用者在有效期內支付成功，但是因為網路、內部應用等問題，支付結果的非同步通知過了很久才收到，這時內部訂單的早因為時間到期而被取消。
解決辦法
第一種解決辦法，上送有效期給支付渠道。
一般支付介面都會有一個支付有效期的欄位，表明這筆支付最晚可以支付的時間。如果超時未支付，這筆支付將會被關閉。
當然一般情況下，如果未上送，這個欄位內部一般會有個預設的有效期，比如 3 天，這個時間就比較長了。
所以當呼叫支付介面時，可以將訂單剩餘有效期傳入支付介面。這樣使用者如果在超時時間內未完成支付，支付將會失敗。
第二種解決辦法，內部發起退款。
這個解決辦法依然事後託底的解決辦法，對於支付訂單已關閉，但是支付卻成功的情況，發起內部退款，將錢退給使用者。
內部可以有個定時任務，定時掃描支付訂單已關閉但是支付卻成功的情況，然後發起退款指令。
最後
最後用思維導圖方式幫大家總結一下支付系統可能會碰到的異常。
歷史支付系統相關文章
歡迎關注我的公眾號：程式通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的部落格：studyidea.cn