退款處理流程圖範本
退款處理流程圖，涵蓋資格、金額審批、冪等提交、逾時狀態查詢、防止重複、受控重試、結算及對帳。
甚麼是退款處理流程
退款流程要把面向客戶的決定，連到其後發生的付款事件。本範本由客戶申請退款或商戶主動發起開始，先記錄原因、申請金額及交易參考，再嘗試配對原有交易。找到交易後，商戶支援會覆核其狀態及現行退款政策。圖中把政策資格、例外覆核及金額計算列為不同步驟，讓團隊可解釋退款為何繼續或停止，以及金額是整筆交易還是只有合資格項目與調整。
審批只在符合條件時需要，並非每宗退款的通用要求。日常金額可直接進入有紀錄的決定；需要另一位覆核人的金額或例外，則進入退款審批人泳道。提交時使用穩定退款參考，並把結果分成獲接受、明確失敗，以及逾時或未知三種。未知結果絕不能當作失敗。營運人員會以原有退款及交易參考查詢狀態，判斷退款屬待處理、已完成、不存在、已失敗，還是仍未能確定。
明確失敗或經確認不存在的退款可以修正，但重新提交前，必須先證明沒有退款存在，並確認防重檢查通過及受控重試安全。獲接受及待處理退款會進入通知與結算追蹤；延誤結果返回狀態查詢，不會返回提交。已完成退款要與結算及帳簿對帳；狀態仍無法確定則暫停並交專責覆核，不可再次重試。服務商狀態、冪等行為及時間各異，實際證據與管控應由已設定的API合約及事故操作手冊訂明。
本流程圖涵蓋的內容
本範本包含
- 客戶申請或商戶發起、記錄交易參考、查找原有交易，以及修正未能配對的資料
- 覆核政策資格、處理例外，並為仍未解決個案保留明確路徑
- 計算全額或部分退款、按條件審批，並持久記錄決定依據
- 獲接受、明確失敗及逾時或未知的提交狀態，再以原有參考查詢狀態
- 受控重試前先防止重複，其後追蹤結算、完成對帳或覆核未解狀態
何時使用本範本
- 客戶支援、付款及財務對退款何時才算完成各有不同定義
- 團隊需要分清政策批准、提交成功及最終結算三個不同狀態
- 部分退款或例外的計算方式不一致，或沒有足夠背景便送到審批人
- 失敗、延誤或未知退款，在解決原有狀態及重複風險前已被重試
- 商戶在付款客戶實施或API整合期間，需要界定退款責任
運作方式
以你哋的規則取代政策關卡
界定業務中影響資格的交易狀態、產品、期限及證據。把例外與日常資格分開，指明誰可覆核，亦不要把某服務商的規則說成適用於所有付款途徑。
界定全額及部分退款計算
記錄哪些項目及調整可以退款，以及過往貸記或退款如何影響剩餘金額。支援、審批及財務應共用同一份計算紀錄，避免每次交接都重新解讀金額。
設定有條件的審批責任
寫明哪些金額或例外類型需要額外審批，以及哪個角色有權批准。若日常退款毋須審批，便保留直接分支並記錄政策依據，不要為每宗個案增加形式化覆核。
繪出提交狀態處理
對應獲接受、明確失敗、已完成、待處理及未知的服務商狀態。界定營運如何以原有退款及交易參考查詢狀態，絕不能把逾時翻譯成提交失敗或新要求。
保障每次重試
重新提交前，必須有證據顯示原有退款不存在或明確失敗，完成防重檢查，並確認重試具冪等性且受控。測試獲接受、已完成、待處理及仍屬未知的結果，直至對帳或專責覆核。
常見問題
退款處理有哪些主要步驟？
記錄及配對原有交易、覆核資格、計算金額、取得所需審批，並指定穩定退款參考。只提交一次，再分清獲接受、明確失敗及逾時或未知狀態。以原有退款及交易參考查詢未知或延誤結果；只有確認不存在、防止重複及證明受控重試安全後才可再試。獲接受的退款要追蹤至結算並完成對帳。
退款獲接受是否等於已結算？
未必。獲接受通常表示提交要求通過下一個系統或服務商關卡；結算或完成則其後由適用付款及財務紀錄確認。確實狀態及時間視乎所用途徑。把兩點分開，可避免面向客戶的確認被誤當成財務已核對結果的證明。
退款何時需要審批？
應採用商戶適用的權限模式及政策。某些金額、例外或風險情況可能需要審批，但不應說成通用付款規則，所以圖中同時保留直接及審批路徑。請在付款客戶實施或程序設計時，界定門檻、審批人、所需證據及替任負責人。
退款提交逾時後應怎樣處理？
把退款視為未知，保留原有退款及交易參考，並在任何重試前使用受支援的狀態查詢。若服務商確認已接受或完成，便繼續追蹤或對帳；若確認失敗或不存在，先修正要求，再完成防重及冪等管控才受控重試。狀態仍未知時要暫停重新提交並交專責調查。
此流程所處的位置
在大多數機構中，此流程會交接給付款對帳流程圖（由紀錄到結算）。
後續流程
- 付款對帳流程圖（由紀錄到結算） — 付款對帳流程範本，涵蓋完整來源擷取、交易與結算配對、差異分類、受控修正、重新配對及審計證據。