每種應用程式內購買類型的退款規則都不同，而只有其中兩種會向你徵詢意見

你在 App Store Connect 或 Play Console 中選擇的應用程式內購買類型，所決定的遠不止商品如何販售。它決定了退款發生時的行為方式，決定了客戶之後能否免費重新拿回該商品，以及在款項移轉之前是否會徵詢你的意見。一個金幣包、一個終身解鎖、一個月度訂閱和一個一次性的賽季通行證，是四種不同的法律與技術物件，退款規則也是這樣對待它們的。大多數開發者用同一段購買程式碼發布它們全部，然後不明白為什麼退款感覺如此不一致。它們並非不一致，而是因類型而異。

以下是每種應用程式內購買類型的定義、退款如何作用於它，以及為什麼四種中只有兩種會把決定路由到你的伺服器。

四種應用程式內購買類型，以及退款為何沿著它們分道

Apple 定義了四種商品類型。消耗型商品是用掉後再買的：遊戲貨幣、提示、能量補充。非消耗型商品是買一次就永久保留的：專業版解鎖、去廣告升級、可下載的關卡包。自動續訂訂閱按重複週期計費，直到客戶取消。非續訂訂閱在一段固定期限內授予存取權，且不會自動續訂，比如作為單一期限販售的一季內容。

Google Play 對同樣的目錄分類方式不同，卻落在同一處。它把商品分為一次性商品和訂閱，而一次性商品是否被標記為消耗型，取決於你的應用程式在購買後是否將其消耗。用詞不同，退款後果卻相同。

消耗型商品才是退款詐欺真正瞄準的類型

消耗型商品是你會遇到的最棘手退款情形，而它恰恰是 Apple 圍繞其打造消耗請求的那一種，這絕非偶然。當客戶購買 10,000 個金幣、你的伺服器發放的那一刻，價值就已交付。如果他們花掉這些金幣再申請退款，商店可以退還他們的錢，但金幣已經沒了，你為兌現它們所付出的成本也一樣。Apple 自己的工具也反映了這一點：消耗型商品一旦完成，就會離開交易記錄，且永遠不帶取消日期，因為沒有任何持久的東西可供取消。

這就是為什麼消耗型是證據能帶來回報的商品類型。當客戶對消耗型商品申請退款時，Apple 會向你的伺服器發送一個 CONSUMPTION_REQUEST，並等待最多 12 hours 以接收一次 Send Consumption Information 呼叫。在該呼叫中，你設定一個 deliveryStatus，並且在你已交付時，設定一個 consumptionPercentage。該百分比是以 milliunits 表示、從 0 到 100,000 的整數，其中 100,000 表示客戶用掉了全部購買。一份你的記錄顯示已完全花掉的金幣餘額就是你可以回報的 100,000，也是你能在非本意購買主張面前擺出的最有力的單一事實。

消耗型商品無法復原，所以時機就是一切

因為消耗型商品無法復原，你不能像撤銷訂閱那樣把它追回來。一旦退款獲批，你唯一的保護就是你在販售時保留的記錄。如果你沒有在交付和消耗發生時記錄它們，你就要在 12 hours 的時鐘下重建它，而那是去找資料最糟糕的時刻。在進入時記錄它，而不是在退出時。

訂閱按你無法控制的時鐘退款

自動續訂訂閱是多數應用程式賺錢的地方，而 WWDC24 的退款更新終於把它們路由到了與消耗型相同的證據視窗。自 App Store Server Notifications version 2.11 起，對自動續訂訂閱的退款請求也會觸發一個 CONSUMPTION_REQUEST。所以那些過去完全不經你手就被裁定的訂閱退款，如今到來時附帶了一個 12 hours 的視窗。

關鍵在於消耗如何被度量。對於自動續訂訂閱，Apple 不希望你捏造一個使用百分比。它會自行從已過去的時間計算消耗，所以一個年度計劃已用滿六個月的人無論你發送什麼都會被讀作大約消耗了一半。你的槓桿不是百分比，而是一份誠實的 refundPreference，即 GRANT_FULL、GRANT_PRORATED 或 DECLINE，並由你實際掌握的任何使用訊號來支撐。發送證據所支持的偏好，讓 Apple 去權衡。

非續訂訂閱更接近一次性解鎖

非續訂訂閱是客戶購買一次的固定期限，就退款而言，它的表現更像非消耗型商品，而不像自動續訂計劃。Apple 極少向它路由 CONSUMPTION_REQUEST，也沒有可供比例攤算的自動續訂。你的應用程式負責追蹤該期限並在客戶的各裝置上復原它，所以退款意味著結束一個由你自己管理的存取視窗，而不是一個 Apple 在為你計時的視窗。

非消耗型商品是永久的，這一點是雙面刃

非消耗型商品是最乾淨俐落的販售對象，也是退款時的一個隱蔽陷阱。它只買一次，永久與客戶的商店帳戶綁定，商店可以隨時按需將其復原到任何裝置。這種永久性在退款到來之前都是一項優點，因為現在你得撤銷一項帳戶仍然記得的權益。如果你的撤銷邏輯只在購買時檢查、從不重新驗證，那麼被退款的客戶可以復原購買，逕直走回付費功能。

Google Play 在這裡增加了一條會絆倒新開發者的硬邊界。如果你的應用程式沒有在 72 hours 內確認一筆購買，Google 會自動退款並撤銷權益。一個你的計費程式碼忘記確認的非消耗型商品不會懸而未決，它會自我逆轉，客戶會失去他們付了錢的東西的存取權，而這並非出於他們自己的任何請求。

到底誰能發放退款，會因商店和類型而變

在你規劃任何退款應對之前，先弄清楚誰握著筆。在 App Store 上，只有 Apple 能發放應用程式內購買退款，對每種商品類型都是如此。你的 StoreKit 程式碼無法為一筆購買退款，你的客服台也不能。你可以在開啟視窗的那兩種類型上發送消耗資料來影響 Apple 的決定，而這就是你直接控制的全部。

Google Play 恰恰相反。你可以自己從 Play Console 或 Voided Purchases 和退款 API 為一次性商品或訂閱訂單退款，全額或部分皆可。這份自由也是一份責任：你對一個消耗型商品發放的退款，仍然必須在你自己的後端撤銷該商品，因為 Google 不知道你的金幣已被花掉。你所選的商品類型決定了那次撤銷有多乾淨俐落。

每種退款類型實際上讓你付出什麼

被退款的價格是每個人都盯著看的那一行，也是帳單中最小的部分。當任何商店發放退款時，它會連同退回自己的佣金，所以你損失的是你的淨收益，而不是全額標價。這是好消息，也就到此為止。商店退還的是它抽走的那一份。它永遠不退還的，是你為完成這筆販售已經花掉的成本，而這個數字會因商品類型而急劇變化。

消耗型商品是昂貴的退款

被退款的消耗型商品是那種可能比其價格花費更多的商品。假設一個客戶購買了 5,000 個額度，每個額度都觸發一次付費推論呼叫，他們花掉了其中 4,000 個，然後申請退款。商店退還價格及其佣金，但運算、按 token 計費的 API 帳單、你生成的圖像，以及這些額度資助的任何創作者分潤，全都已被花掉。非消耗型商品的退款至少能把一項權益拉回你的掌控。消耗型商品的退款拉回的，是一筆你已經付清了全部成本的販售。

拒付是同一張帳單的更重版本

退款和拒付是不同的事件，而兩者之間的差距現在有了一個日期。當客戶不是向商店申請、而是向他們的銀行爭議這筆扣款時，一次完成的拒付是銀行終局的。對於在 August 3 2026 當天或之後下的 Google Play 訂單，一次敗訴的拒付會向開發者收取購買價格減去 Play 的服務費，再加上銀行的拒付手續費，這是一筆由卡組織設定的固定費用。Google Play 會透過 orders.reviewrefund 把拒付路由給你審查，附帶一個 24 hours 的視窗，這是唯一向你索取證據的 Google 流程，而且它可能落在任何商品類型上。

當類型決定規則時該如何應對

你無法在販售之後改變退款落在哪種商品類型上，但你可以停止用同一種方式處理全部四種。

• 在消耗型商品的交付和消耗發生的那一刻就記錄它們。那份日誌是你在唯一無法復原的類型上的全部防禦，而 12 hours 的視窗遠遠不夠從零建構它。
• 在退款之後重新驗證非消耗型商品的權益，而不只是在購買時。一次復原呼叫應當檢查目前狀態，這樣被退款的客戶就無法走回付費功能。
• 自動應答兩個證據視窗。一個 12 hours 的消耗請求和一個 24 hours 的拒付審查，等不了某個人去讀收件匣，也不會為時區而延長。
• 只在兩種可爭議的類型上評判你的退款防禦。在從不開啟視窗的類型上退款數量的上升，是一個產品或定價訊號，而不是你證據的失敗。

這一切都不是要戰勝商店，而是要讓你的應對匹配那個真正被賣出的對象。RefundHalt 會在視窗之內、用你在販售時記錄的交付與使用證據，自動應答消耗型和訂閱的 CONSUMPTION_REQUEST 以及 Google Play 的 orders.reviewrefund 審查，並把那些沒有任何視窗曾讓你爭議的退款保存在它們自己的帳本裡，這樣你用來評判自己的那個數字才保持誠實。