背景退款業務，相對於支付業務，部分需求方（包括產品、市場的同事）認為退款業務不是那麼緊急或重要。從業務角度分析，沒有支付業務，使用者無法支付或支付優惠活動無法開展，但沒有退款功能，則不影響使用者下單支付和開展優惠活動。使用者申請退款，財務可登入第三方支付平台提供的商戶管理系統進行人工退款操作。因此，目前應該還有許多電商平台的退款業務都是財務人工操作的，當公司訂單到了一定規模，人工退款操作則是不可行的。這時候，則需要一一對接退款業務。
從系統安全角度分析，退款業務的重要性甚至比支付業務更要高，因為退款業務可以理解為是商戶自己向使用者付錢，如果多付，所造成的公司財務損失，幾乎不可能追回。常見的風險有：訂單申請了部分退款，由於各種原因造成多退的情況；系統退款由於操作人疏忽或其他原因造成不該退款的訂單退款給使用者的情況。以上兩種情況，我身邊確實有這樣的案例，最大的一次損失，是乙個下午，給公司造成了80多萬的損失。鑑於此，在設計退款模組的童鞋，邏輯一定要縝密，不要有疏忽、漏洞等隱患。
退款閘道器
對使用者主動取消的已付款訂單、或者因為庫存不足、無法配送等各種原因需要撤銷訂單的，都需要給使用者進行退款操作，退款形式有原路退款、銀行轉賬、退餘額等，目前主流的都是進行原路退款。退款閘道器不能有使用者直接訪問，訂單要有退款申請與審批流程，一般是在訂單管理系統控制，有訂單管理系統呼叫退款閘道器，發起退款請求，聚合支付系統要對退款閘道器做好身份驗證及安全防範。
聚合支付平台退款部分，也需要非同步通知處理佇列，消費佇列接受來自第三方非同步通知、crontab主動查詢或人工查詢到已退款成功的訂單退款資料，將其統一處理，更新退款單狀態、通知訂單系統等操作。
退款交易流水表，主要字段展示
name
field
remark
系統訂單號
order_id
商戶訂單系統的真實訂單號
退款單號
refund_id
傳給第三方平台的退款訂單號
外部系統的退款單號
out_refund_id
一般指訂單系統傳來的退款單號
退款流水號
refund_no
第三方支付平台的退款流水號
支付方式id
payment_id
退款發起平台
platform
訂單支付金額
total_fee
退款金額
refund_fee
退款型別
refund_type
全額、部分
退款狀態
refund_status
enum(wait、success、failed)
同步狀態
sync_status
enum(wait、success、failed)
退款申請時間
create_time
非同步通知時間
notify_time
同步訂單系統時間
sync_time
注意點退款非同步通知
同支付非同步通知一樣，退款非同步通知也建議使用佇列進行解耦，收到第三方的退款通知，只需要驗籤和金額校驗後，則將報文資料push到退款通知佇列中，有後端消費程序去更新退款單的退款狀態、通知訂單系統的退款狀態等後續處理流程。
支付/退款狀態查詢
針對上一章節所遇到的問題，雖然主動對賬可以處理掉絕大部分已支付訂單被掛起的問題，但難免有漏網之魚，沒有被及時處理的訂單，使用者肯定不幹，要投訴平台。鑑於此，我們開發人員需要給客服或者財務同事提供乙個後台查詢系統，用於處理客訴中這類問題的訂單。該模組需要支援兩點：
支付系統對賬設計
對賬系統作為支付系統中的基石系統,處於整個支付環節中的最後一層，主要用來保證我方支付資料與第三方支付渠道或銀行的資料一致性。在沒有對賬系統之前，財務在第二日手工核對前一日的應收與實收。倘若不一致，這就需要一一核對資料，找出不一致的資料。對賬系統出現之後，就可減少以這種繁瑣手工操作，財務只需要每天關注...
簡單介紹四方聚合支付系統
移動支付的迅速崛起，給我們的生活帶來很大的便利，一台手機走天下已經成為了現實，現在市場上除了有第三方支付外，還有第四方支付，現在我們就來簡單介紹一下。四方支付是相對第三方而言的，作為對第三方支付平台服務的拓展。第三方支付介於銀行和商戶之間，而第四方支付是介於第三方支付和商戶之間，沒有支付許可牌照的限...
支付系統設計 支付系統的賬戶模型（一）
賬戶體系是支付系統的基礎，它的設計直接影響整個系統的特性。這裡 如何針對電子商務系統的支付賬戶體系設計。我們從一些基本概念開始入手，了解怎麼建模。賬戶體系設計首先要區分兩個概念，支付賬戶和登入賬號。這是兩個不同業務領域的概念 支付賬戶指使用者在支付系統中用於交易的資金所有者權益的憑證 登入賬號指使用...