聚合支付系統設計（三）

退款網關與退款狀態查詢設計

背景

退款業務，相對於支付業務，部分需求方（包括產品、市場的同事）認為退款業務不是那麼緊急或重要。從業務角度分析，沒有支付業務，用戶無法支付或支付優惠活動無法開展，但沒有退款功能，則不影響用戶下單支付和開展優惠活動。用戶申請退款，財務可登錄第三方支付平台提供的商戶管理系統進行人工退款操作。因此，目前應該還有許多電商平台的退款業務都是財務人工操作的，當公司訂單到了一定規模，人工退款操作則是不可行的。這時候，則需要一一對接退款業務。

從系統安全形度分析，退款業務的重要性甚至比支付業務更要高，因為退款業務可以理解為是商戶自己向用戶付錢，如果多付，所造成的公司財務損失，幾乎不可能追回。常見的風險有：訂單申請了部分退款，由於各種原因造成多退的情況；系統退款由於操作人疏忽或其他原因造成不該退款的訂單退款給用戶的情況。以上兩種情況，我身邊確實有這樣的案例，最大的一次損失，是一個下午，給公司造成了80多萬的損失。鑒於此，在設計退款模塊的童鞋，邏輯一定要縝密，不要有疏忽、漏洞等隱患。

退款網關

對用戶主動取消的已付款訂單、或者因為庫存不足、無法配送等各種原因需要撤銷訂單的，都需要給用戶進行退款操作，退款形式有原路退款、銀行轉賬、退餘額等，目前主流的都是進行原路退款。退款網關不能有用戶直接訪問，訂單要有退款申請與審批流程，一般是在訂單管理系統控制，有訂單管理系統調用退款網關，發起退款請求，聚合支付系統要對退款網關做好身份驗證及安全防範。

聚合支付平台退款部分，也需要非同步通知處理隊列，消費隊列接受來自第三方非同步通知、crontab主動查詢或人工查詢到已退款成功的訂單退款數據，將其統一處理，更新退款單狀態、通知訂單系統等操作。

退款交易流水表，主要欄位展示

注意點

• 不管來自哪裡的退款申請，都要先查詢訂單支付狀態，直接調用第三方支付的查單介面去查最新的訂單狀態、可退金額等信息，並以此為準；
• 退款金額校驗，如果是全額退款，則只需驗證退款金額等於支付金額，方可調用退款介面進行退款；如果是部分退款，則要計算已經成功退款的金額總額，以及已經退款申請成功，但還沒收到第三方的退款成功通知這部分的金額總額，訂單支付金額減掉這兩部分的總金額之後的金額是可退金額；
• 對於部分退款申請處理，如本次已經申請成功了，還在處理中的退款，不要重複申請退款；

退款非同步通知

同支付非同步通知一樣，退款非同步通知也建議使用隊列進行解耦，收到第三方的退款通知，只需要驗簽和金額校驗後，則將報文數據push到退款通知隊列中，有後端消費進程去更新退款單的退款狀態、通知訂單系統的退款狀態等後續處理流程。

支付/退款狀態查詢

針對上一章節所遇到的問題，雖然主動對賬可以處理掉絕大部分已支付訂單被掛起的問題，但難免有漏網之魚，沒有被及時處理的訂單，用戶肯定不幹，要投訴平台。鑒於此，我們開發人員需要給客服或者財務同事提供一個後台查詢系統，用於處理客訴中這類問題的訂單。該模塊需要支持兩點：

• 所有第三方支付平台的查詢介面返回報文格式數據都不一樣，我們需要將其組織成統一的格式返回給前端，前端再展示給客服能看得懂的信息數據；
• 如果查詢訂單支付成功，需要將其訂單支付數據自動push到異常訂單處理隊列中，及時更新訂單支付狀態；

推薦閱讀：