訂閱退款與一次性退款的運作方式不同，而你能有多少話語權由所在的商店決定

對訂閱退款和對單筆應用程式內購買退款，感覺像是按同一個按鈕。其實不是。一次性購買是你退還的一筆扣款。訂閱是帶有即時權益的循環扣款，因此訂閱退款必須回答兩個一次性退款從不會問的問題：目前週期你退還多少，以及訂閱是否繼續運行。App Store 和 Google Play 對這兩個問題給出的答案正好相反，而這種差異決定了你能掌控多少，以及有多少錢離開你的帳戶。

這是簡明的對照圖。在 App Store 上，Apple 擁有決定權，你事後才得知。在 Google Play 上，你掌握控制權，自己選擇全額還是按比例。本文會走一遍兩家商店、每家使用的確切欄位和通知、當訂閱已多次計費時你該處理哪一筆訂單，以及一旦把你已經花掉的運算算進去，訂閱退款實際會讓你付出什麼。

訂閱退款與一次性退款有何不同

兩家商店都把退款視為撤銷某一筆特定訂單。對於一次性購買，只有一筆訂單，因此沒什麼可選。訂閱是一串訂單，每個計費週期一筆，並附帶一項處於啟用或未啟用狀態的權益。正是這種結構，讓訂閱退款帶有一次性退款所沒有的選擇。

被撤銷的單位是一個計費週期

當你為訂閱退款時，你並不是在退還一輩子的付款。你處理的是這串訂單中的一筆，通常是最近的一筆，也就是單個計費週期。全額退款退還整個週期。按比例退款只退還客戶尚未使用的那部分週期。無論哪種，你撤銷的銷售都是一個週期的價格，而不是客戶在應用程式上的全部歷史。

誰來決定才是真正的區別

更鮮明的分野在於權限。在 App Store 上，是否發生訂閱退款完全由 Apple 決定，你頂多提供一些背景資訊。在 Google Play 上，由你決定，API 嚴格照你說的執行。對客戶來說結果一樣，但開發者所處的位置完全不同，這也改變了你要為處理各自情況而建構的東西。

App Store 如何處理訂閱退款

在 Apple 這邊，你是個拿著小麥克風的旁觀者。客戶與 Apple 溝通，Apple 做出裁定，你的伺服器讀取結果。

客戶向 Apple 申請，由 Apple 裁定

App Store 客戶在 reportaproblem.apple.com 申請訂閱退款，而不是找你。Apple 依據自己的訊號審核請求並決定。你不核准它，也沒有哪個 Apple 主控台按鈕能讓你像在 Google Play 那樣發放訂閱退款。Apple 自購買起最多有 90 days 的時間來受理審核請求，而一旦它做出裁定，決定權就在 Apple。

退款到達時你的伺服器會看到什麼

你透過 App Store Server Notifications V2 得知結果。已核准的退款會以 REFUND 通知到達，該交易現在帶有一個標記存取權應何時結束的 revocationDate。訂閱的 autoRenewStatus 被設為 false，因此它停止續訂，客戶失去權益。如果 Apple 拒絕了請求，你會收到 REFUND_DECLINED；如果 Apple 後來撤銷了它已經核准的退款，你會收到 REFUND_REVERSED，訂閱會恢復。你的工作是讀取這些通知並切換存取權，而不是投票。

Apple 按時間而非你的指標來衡量訂閱

對於消耗型商品，你可以透過消耗資料告訴 Apple 使用了多少。對於自動續訂訂閱，Apple 會自行根據已經過去的時間計算消耗。Apple 自己的例子是一位在年度訂閱中已過去六個月的客戶，已消耗其中約 50%。所以你的用量指標並不決定訂閱的這個數字。你唯一能拉動的槓桿是 refundPreference，而對於訂閱，相關的值是 GRANT_PRORATED，它表示你希望 Apple 只退還未使用的部分。這是一種偏好，不是決定。仍然由 Apple 裁定。

Google Play 如何處理訂閱退款

Google Play 把決定權交到你手裡。有一個 Play Console 介面和一組 API 方法，讓你直接為訂閱退款、選擇退多少，並決定是否結束存取權。這與 Apple 的姿態正好相反，也伴隨著你必須做對的選擇。

全額還是按比例，由你決定

目前退款並撤銷訂閱的方式是 purchases.subscriptionsv2.revoke，呼叫時帶上一個 revocationContext。傳入 fullRefund，Google Play 會終止訂閱並退還目前計費週期的全部金額。傳入 proratedRefund，Google Play 會終止訂閱，只退還剩餘的、未使用的權益時間。較舊的方法只能做全額退款，這正是使用較新方法的理由。按比例撤銷是一個兩行的請求主體，一個包裹著 proratedRefund 的 revocationContext，你把它換成 fullRefund 就能退整個週期。任何一種撤銷都會觸發一則 SUBSCRIPTION_REVOKED 即時開發者通知，這就是你切斷存取權的訊號。

你對哪一筆訂單退款會改變結果

Google Play 還允許你透過 orders.refund 在不撤銷的情況下為訂單退款，這裡有一條微妙的規則會起作用。如果你對訂閱中最近的一筆訂單退款，該訂單被退款，訂閱會立即被移除，未來的續訂被取消。如果你對這串訂單中較早的一筆退款，那筆訂單被退款，但訂閱仍然有效。在 orders.refund 上，revoke 參數只在訂單是最近一筆時才會撤銷，因此要結束一個有效訂閱的存取權，你應改用 purchases.subscriptionsv2.revoke。

讓開發者栽跟頭的那些限制

有幾個硬性的邊界會絆住人，而且沒有一個位於順利路徑上。

• 超過 three years 的訂單根本無法退款。
• 部分退款僅適用於 March 2018 之後下的訂單，且永遠不適用於付費應用程式購買。
• 你可以在一筆訂單上疊加多次部分退款，但總額不能達到或超過訂單金額。
• 退款一經發放就無法撤銷。

Google Play 通常在一天內傳回退款決定，不過也可能長達四天。當退款需要反映到你自己的存取控制中時，要為這段延遲做好準備。

訂閱退款實際會讓你付出什麼

被退還的扣款從來都不是全部帳單。訂閱訂單被交付的那一刻，你就已經為它花掉了真金白銀：運算、模型 API 呼叫、儲存空間，以及與該週期掛鉤的任何分潤支付。退款退還的是銷售額。它不退還你為提供服務所花掉的東西。對訂閱而言，損失的形態取決於你發放哪種退款。

全額還是按比例，是一個關於錢的決定

在 Google Play 上，全額退款退回整個目前週期，因此你損失整個週期的收入，同時保留你在該週期已經產生的每一筆成本。按比例退款只退回未使用的那一小塊，因此你保留客戶實際擁有的那部分收入。如果客戶在一個 10 美元的月度方案中已過完 60%，全額退款會讓你損失整整 10 美元，而按比例退款只讓你損失約 4 美元，即未使用的 40%。Apple 在確定訂閱退款額度時，在它那一側也採用同樣的按已過時間計算的邏輯。

那些永遠回不來的成本

無論你發放哪種退款，該週期的下游成本都已經沒了。你付費的一次模型 API 呼叫、你算繪的一段影片、你佈建的儲存空間、你已經發出的一筆創作者分潤，當訂閱退款結清時，這些都不會逆轉。按客戶實際使用的量來確定退款額度，永遠不要按他們訂閱了多久，因為已經過去的時間不是成本，兩家商店也都不把它當成成本。而且在 August 3, 2026 之後，如果一筆 Google Play 訂閱扣款以銀行拒付而非你發放的退款收場，你還要承擔銀行的拒付費用，而先由你主動發放退款則可以避免這筆費用。

如何在無人盯守的情況下處理訂閱退款

這一切都不應該等著某人去看儀表板。通知在任何時刻都會到達，存取權應在退款落地的那一刻切換，而不是等到第二天早上。

讀取結果並在兩家商店上撤銷存取權

在 App Store 上，監聽 REFUND、REFUND_DECLINED 和 REFUND_REVERSED，並利用 revocationDate 和 autoRenewStatus 自動結束或恢復存取權。在 Google Play 上，監聽 SUBSCRIPTION_REVOKED 和已作廢購買的訊號，做同樣的事。這就是 RefundHalt 為你運行的管線：通知進來，比對帳戶，切換存取權，無人介入。

在爭議發生前就備好證據

那些確實需要你輸入的狹窄視窗，Apple 針對消耗型商品的 12 小時 CONSUMPTION_REQUEST 和 Google Play 的 24 小時拒付審核，只有在證據已經存在時才有用。給每一筆購買附上一個帳戶識別碼，在 Apple 上是一個 appAccountToken UUID，在 Google Play 上是一個 64 characters 或更短的雜湊 setObfuscatedAccountId，並記錄每個付費週期交付了什麼。這樣當權杖到達時，案件已經建好，在視窗內作答就成了機器的活兒，而不是一場手忙腳亂。