Apple 可以撤回一筆已經核准的退款，而你的伺服器忽略的已撤回退款，會把付了錢的客戶鎖在門外

退款不一定是最後定論。在客戶提出爭議之後，App Store 可以撤回一筆已經核准的退款，而當這筆已撤回的退款送到你的伺服器時，它帶著一個指示：把存取權還回去。大多數團隊只接上一般的 REFUND 通知、切斷客戶，然後就到此為止。他們從不建立另一半。所以當撤回到來時，什麼都不會執行，而一位正在再次付款的客戶，卻被鎖在自己所購買的東西之外。以下說明整組退款通知在 App Store 與 Google Play 上如何運作，以及當你忽略每一種時各會付出什麼代價。

App Store 送出三種退款通知，不是一種

大多數退款處理是為單一事件而建：錢退回去了，切斷客戶。App Store Server Notifications V2 的資料流其實帶著三種各自獨立的退款結果，而它們各自要求不同的事。其中兩種會改變客戶能存取什麼。另一種則撤銷第一種。以下是完整的一組，用 Apple 自己的話來說。

REFUND，每個團隊都會處理的那一種

當 App Store 處理一筆退款時，它會送出 REFUND 通知到你設定的 URL，而 Apple 的定義很直白：它「表示 App Store 已成功為一筆消耗型 In-App Purchase、非消耗型 In-App Purchase、自動續訂訂閱，或非續訂訂閱的交易完成退款。」你儲存這筆已退款的交易、收回它所購買的東西，而 Apple 要求你在 app 內用符合情境的訊息告訴客戶有什麼改變。這是大家最先接上的通知，也往往是唯一的一個。

REFUND_DECLINED，完全不需要你動手的那一種

REFUND_DECLINED 的意思正如字面：「App Store 拒絕了一筆退款請求。」客戶提出要求，Apple 說不，交易維持有效。客戶的存取權沒有任何改變，所以你的權益邏輯在這裡什麼都不做。這則通知的價值在於記帳。它為你可能以 CONSUMPTION_REQUEST 回應過的退款請求收尾，並確認客戶仍然擁有他所付費的東西。把它當成一筆記錄，而不是一個動作。

REFUND_REVERSED，讓團隊措手不及的那一種

這是大多數退款流程從不處理的通知。Apple 的定義毫不含糊：REFUND_REVERSED「表示 App Store 因為客戶提出的爭議，撤回了先前核准的退款。如果你的 app 因為相關退款而收回了內容或服務，就必須把它們恢復。」把這句讀兩遍。Apple 給了客戶退款，你收回存取權，接著 Apple 判定這筆退款不應成立並收回它。扣款再次生效。客戶付了錢，而如果你的伺服器只知道怎麼收回，他就依然被鎖在門外。已撤回的退款是唯一會把存取權加回去的退款事件，也是幾乎沒有人為它建立處理的那一個。

一筆已撤回的退款實際上讓你付出多少代價

漏掉一次撤回並不是四捨五入的誤差。把錢往兩個方向都走一遍，因為任一半做錯都有代價。

漏掉撤回，你就會讓一位付費客戶一直被鎖在門外。Apple 已經恢復了扣款，所以客戶再次破財，而你的 app 卻拒絕給他所購買的東西。眼前的代價是客服時間，以及一筆你現在可能得自己發出的善意退款，這一次沒有商店抽成退回來替你緩衝。較慢浮現的代價是評論與流失，而在 Google Play 上，同樣這種被鎖在門外的不滿，正是會演變成 chargeback 的東西。

漏掉原始退款，你就會繼續服務一位一毛錢都沒付的客戶。相對的錯誤是根本從不收回。一位已退款的客戶若仍在生成圖片、呼叫你的 API、佔用你的儲存空間，就會針對一筆已撤回的銷售累積真實成本。運算、第三方呼叫與儲存都是你已經花掉的錢，而它們沒有一樣會隨著退款回來。

• 客服成本：由真人回覆一張工單，處理的是你自己的程式碼移除、卻從未還原的存取權。
• 善意退款：把錢重新發給一位你錯誤鎖在門外的客戶，而這種手動舉動不會有商店抽成退回。
• 浪費的支出：由一個你從未切斷的已退款帳號所消耗的運算、API 呼叫與儲存。
• chargeback 風險：在 Google Play 上，一位覺得自己被重複收費的客戶可以提出爭議，而如今敗訴的爭議會落到你身上。

已撤回的退款與一般退款是同一條指向相反方向的 webhook 資料流。處理其中一種而略過另一種，你就會兩頭都付出代價。

Apple 為什麼撤回退款，以及如何解讀 revocationReason

撤回並非隨機。Apple 把它與「客戶提出的爭議」連在一起，也就是客戶事後對退款決定提出質疑。當退款最初被核准時，該筆交易帶有 revocationDate 與 revocationReason，而在下游任何東西據以行動之前，這個原因值得先讀一讀。

• revocationReason 1：App Store「因為你 app 內實際存在或被認為存在的問題」而退款。那是關於你產品的訊號，不只是關於這一位客戶。
• revocationReason 0：App Store「基於其他原因，例如誤購」而退款。沒有附帶任何關於 app 品質的訊號。

當那筆交易的 REFUND_REVERSED 到來時，撤銷正在被還原。你的恢復邏輯應該查出原始的 transaction id、確認你曾收回它，並把權益原原本本地放回去。

Google Play 不送出撤回，所以你改用對帳

Google Play 的模型不同，而如果你用一個 webhook 處理器同時跑兩家商店，這個差異就很重要。沒有與 REFUND_REVERSED 對應的 Google 版本。Google 的 Real-time developer notifications 把退款事件拆成兩則訊息，而撤回是靠對帳處理，不是靠推送。

作廢購買通知

當一筆 Google Play 購買被作廢時，你的伺服器會收到 VoidedPurchaseNotification。它會列出 purchaseToken 與 orderId、一個為 subscription 或 one-time 的 productType，以及一個為完全作廢、或針對多數量購買按數量計的部分退款的 refundType。Google 說這些資料足以找到正確的購買並調整權益。若需要更多，它會指引你使用 Voided Purchases API，這是一個拉取模型，會列出你所查詢的時間戳範圍內的已作廢訂單。

chargeback 審核，以及它的 24 小時時鐘

chargeback 透過另一則訊息傳來，也就是 PendingRefundReviewNotification。當客戶向銀行對一筆扣款提出爭議時，Google Play 會送出這則通知並啟動一個時鐘。你有 24 hours 可以呼叫 orders.reviewrefund，附上退款偏好與任何用量證據，好讓 Google 能代表你抗辯一筆不正當的 chargeback。Google 記錄你的第一次呼叫，忽略其餘的。這是 Google 這邊對應 Apple CONSUMPTION_REQUEST 的機制，是你在爭議中的一方唯一算數的那個窗口。

因為沒有撤回推送，一筆 Google 抗辯並勝訴的 chargeback，不會以一個乾淨俐落的恢復事件送達。你要拿它去和 Voided Purchases API 以及你自己的記錄對帳。教訓和 App Store 上一樣：一筆已作廢的訂單不一定是永久的，而你的權益狀態必須能夠往回移動，不能只會往前。

如何處理每一種退款通知，卻不把任何人鎖在門外

你不需要每家商店各一條獨立的流程。你需要一個處理器，它能把權益往兩個方向移動，並把每則訊息都當成可能重複的來對待。

• 建立恢復，而不只是收回。對於每一條在 REFUND 時移除存取權的路徑，都寫出在 REFUND_REVERSED 時把它還原的反向路徑，並以同一個 transaction id 為鍵。
• 讓它冪等。兩家商店都可能不只一次送達同一則通知，所以把每次收回與恢復都以 transaction 或 order id 為鍵，並讓重複成為 no-op。
• 動手之前先讀原因。用 revocationReason 分辨一筆 app 品質退款與一筆誤購退款，並把 app 品質那類轉給負責產品品質的人。
• 準時回應證據窗口。在 CONSUMPTION_REQUEST 之後 12 hours 內送出 Apple 的用量資料，並在 PendingRefundReviewNotification 之後 24 hours 內呼叫 orders.reviewrefund。
• 儲存每一個事件。保留 REFUND_DECLINED 與原始通知，好讓稍後到來的撤回能夠對應到它所撤銷的那筆退款。

這一切都不會改變退款是否發生。它改變的是，站在一筆已撤回退款另一端的客戶，會不會察覺到你的伺服器搞錯了。