支付系統常見問題與解決方案
- 2020 年 3 月 7 日
- 筆記
概述
支付系統涉及到資金交易，對數據安全性和一致性有較高要求。
本文簡單介紹下幾個常見對問題，和一些思考。（作者也是剛剛學習，有理解不對的地方敬請斧正）
防抵賴
支付系統中有一些操作/介面是必須對調用方進行身份強校驗的。
- 支付結果回調
- 退款、撤銷訂單（訂單回滾）
支付結果回調不作校驗的話，如果回調是別人偽裝的，就可能導致商戶沒收到錢，卻通知他發貨給下單人。
訂單回滾操作不作校驗的話，可能導致錯誤地把商戶的錢退換給用戶。
以上兩種情況都會給商戶帶來損失。
支付回滾
防抵賴通常的措施，是通過密鑰對支付關鍵數據進行簽名，請求接收方校驗簽名。
對於支付系統而言，訂單回滾通常需要使用非對稱私鑰。即支付系統的使用方使用私鑰進行加密，然後支付系統通過公鑰匙解密。
能通過公有解密出來的資訊，就是來自對應私鑰的擁有者。從而做到防抵賴。
支付成功回調
支付成功回調相比支付回滾對支付系統對要求會低一些。（因為支付系統可以要求使用方收到回調後，需要進行訂單查詢確認，將一些責任轉移到應用/商戶）
不過整體上，尤其對於不是很強勢的小支付平台而言，非對稱加密是比較常用的方式。
重複支付問題
訂單發生重複支付，也回增加系統使用方對負擔。
重複支付問題有兩個解決思路，
-
- 在支付時，一旦支付人發起支付，在限定時間內其他人不得對同一個訂單發起支付，同時支付人必須儘快在限定時間內完成支付，否則支付票據失效，訂單解鎖。
-
- 確認無法杜絕重複支付時，可以做退款邏輯。（不過這塊要尤為謹慎）
數據一致性問題
數據一致性主要是要避免因為網路問題或者系統對一些其它故障，要能夠保證最終系統對整個鏈路中訂單對狀態是一致的。
- 數據回調丟失。（儘快回調通常回多次發起，但是還是有可能出現全部丟失的場景）
- 退款請求沒有應答。（系統下游收到退款請求，且執行了實際動作，但是應答丟失了）
在退款時，支付系統或應用，一旦想下游發起請求時，不過有沒有收到應答，訂單的狀態都必須更改為退款中。後續在通過應答，或者訂單的延時查詢將訂單的狀態修正為確定狀態（退款成功或失敗）。
