先分開業務決定與付款動作
部分退款先是業務決定：退回訂單哪一部分、原因是甚麼、由誰核准金額；不應由操作員直接在支付平台輸入一個數字開始。訂單可能包含多件貨品、運費、折扣，或狀態有異的退貨。客服要向顧客解釋，財務要追查原交易及退回款項，付款操作員則需要已核定的數額。三者是同一個個案的不同視角，卻不是同一份記錄。保留原訂單，後來才有辦法交代計算。
在按下退款之前，先建立簡短個案記錄：訂單編號、原付款參考、涉及貨品或服務、顧客要求、已審閱資料、核准退款金額及貨幣、決策負責人。如果店舖提供換貨、購物額或維修，也應按實際政策記錄顧客接受哪種安排。支付平台技術上可退款，不代表每宗退貨均有同樣權利，也不證明政策符合法律。商業決定取決於交易條款及適用義務；支付系統只負責執行已核准的金額。
選擇退款而非取消之前，要先確認付款狀態。Stripe 文件把尚未完成付款的取消，與成功付款後的全額或部分退款分開；未請款交易亦有不同處理方式。本文以 Stripe 展示具體流程，並不假設所有香港商戶都使用它。如果你的支付服務或付款方式有不同狀態，應先建立對照。顧客截圖或系統顯示「待處理」本身，不足以證明應執行哪個付款動作。
連同舊退款核算金額
假設顧客一張訂單購買兩件貨，付款港幣 800 元；店舖同意就其中一件退回港幣 300 元，另一件及運費仍須支付。這些只是示例數字，不是實際店舖成效或法律權利。個案應保存計算方法及政策依據。訂單仍顯示原付款 800 元，另有一筆 300 元退款記錄；若直接把原訂單改成 500 元，原來收取的金額便被掩蓋，難以核對支付紀錄。向顧客展示時，可清楚列出原付款、核准退款及保留金額。
核准新退款前，要先查閱該筆付款已有的所有退款。Stripe 說明同一筆收款可分多次退款，但總額不能超過原收款。平台上限只是最後防線，不能取代業務控制。第一筆退款仍在處理時，另一名員工可能就同一問題再次提出要求；另一件貨品也可能已經部分退款。個案畫面應列出舊退款編號、金額、原因及狀態，讓核准人看到尚可處理的餘額。
退款授權界線應配合店舖實際風險及人手。例如客服提出補救方案，經理核准政策例外，付款操作員執行已批個案。小團隊可以由同一人兼任，但記錄仍應區分建議、核准與執行。不要把隨意編造的金額門檻說成法規。任何門檻都應根據實際交易風險、爭議情況及內部權限決定，並寫入程序，讓員工一致執行。
執行並追蹤真實退款
按 Stripe 的 Dashboard 指引，操作員先找到原付款，選擇退款；部分退款需輸入另一金額、選擇原因，再完成操作。Stripe 的批量 Dashboard 功能處理全額退款，部分退款須逐筆執行。若使用 API，金額以交易貨幣的最小單位傳送；不同貨幣的最小單位可能有別。系統不應從畫面格式化的金額字串推算 API 數值，而應一起保存貨幣、已核准的最小單位金額、付款參考及取得的退款編號。
已提交退款，不等於顧客已在戶口看到款項。Stripe 說明，部分卡交易在可用結餘不足時會待處理；退款也可能失敗，某些付款方式更要顧客補充資料。部分較早發起的卡退款可能以撤銷原交易呈現，而非另一筆入帳。因此個案要有完整狀態：已申請、已提交、待處理或待顧客行動、成功、失敗或取消，並記下平台參考及最後核查時間。通知顧客時須反映當前狀態，不應一提交便保證已到帳。
Stripe 指退款一般只能回到原付款方式，不能任意轉往新卡或銀行帳戶。當有人要求客服把退款轉至另一戶口，這是重要界線。原付款方式已關閉時，後續安排由支付服務及發卡機構處理，退款也可能失敗。不要在原交易中臨時改填另一目的地。失敗個案應按已記錄的替代付款程序升級，透過適當渠道核實顧客，並保留與原退款嘗試的連結，以免重複付款。
核對訂單、平台及顧客通知
每日結算時，逐宗比較三項事實：訂單原付款與核准調整、支付平台退款編號及狀態，以及實際發給顧客的訊息。待處理退款應列入例外清單，不可當作已完成支出。失敗退款須指定負責人及下一步。撤銷原交易未必在顧客帳戶顯示另一筆入帳，客服應按平台所示解釋，而不要聲稱能看到顧客銀行戶口。財務核對要使用支付服務的結餘和報表紀錄；單靠訂單畫面不能證明結算。
在示例中，商業上應看到原付款 800 元、已核准退款 300 元，餘下 500 元對應顧客保留的貨品及同意支付的費用。這只是訂單層面的算式。銀行實際收款可因處理費、結算時間及其他交易而不同。Stripe 文件指出，原交易處理費不會因退款退回，可用結餘也會影響退款。應先按交易及退款參考逐筆核對，再比較匯總入帳，不要硬把銀行一筆撥款等同某張訂單的淨額。
有用的結案規則是：操作員按下按鈕，不代表個案已解決。須確認平台最終狀態、更新訂單調整、如實向顧客說明，並完成倉庫驗貨等相關工作。待處理、失敗、有爭議或金額不符個案應進入同一例外清單。若顧客稱未收到款項，可提供平台已有的退款參考和狀態；Stripe 提醒參考編號並非每宗都有，撤銷原交易亦可能沒有 ARN。正式採用流程前，可用一宗已匿名化真實個案及一宗失敗情況作演練。
讓交接可以追查
實用的個案時間線應保留每個獨立動作，不要只覆寫一格「退款狀態」。可依次記錄顧客要求、收到的證據、金額計算、核准、向平台提交、平台回覆、後續狀態變化及顧客通知。原訂單和付款參考只需連結一次，每筆部分退款則分別附上編號。同一訂單的不同貨品在不同日子退回時，這尤其重要；覆核人可辨認第二筆退款是另一個已批補救，還是重複操作。個案內容仍應按員工職責限制存取；可追查不代表所有員工都要看到全部付款及個人資料。
應預先指定非正常完成退款的負責人。待處理申請可能要檢查結餘或向平台查詢；待顧客行動個案需要聯絡顧客；失敗個案則可能需要新的已授權補救。相關工作未完成前，個案不應關閉。第一筆退款較慢時，切勿立即再付一次；先確認平台最新狀態，以及原款項是否仍可能完成。最後結案時，記下顧客得到的實際結果及支持該結果的資金流。客服才有如實答覆，財務亦有交易脈絡，而不會把按下 Dashboard 按鈕誤作已結算證據。
每日結算未能解決的個案，可在每周例外覆核中跟進。清單包括仍待處理、等候顧客補充資料、退款失敗，以及已批調整與支付平台紀錄不符的訂單。每宗指定負責人及下次核查日期，並記下給顧客的答覆。這是營運紀律，不代表所有支付服務都有相同報表或處理時間；如平台狀態不同，仍應核對訂單決定、平台結果及顧客溝通三方面。
推出前檢查
- 金額是否已核准並連回原訂單？
- 是否已查閱舊退款及原付款狀態？
- 結案是否根據平台最終狀態及顧客通知？
