現在每一筆 Apple 退款請求都附帶一個理由，而 consumptionRequestReason 就是你讀取它的方式

Apple 改變了退款請求到達你伺服器的方式，而許多開發者從未察覺。自 WWDC24 上宣布的 App Store Server Notifications 2.11 更新起，每一個 CONSUMPTION_REQUEST 通知都攜帶一個名為 consumptionRequestReason 的欄位。它是客戶自己陳述的退款理由。一個純文字字串，五種可能取值，隨附在你本就有十二小時時間去回覆的同一份負載中。

Apple 退款請求理由本身並不決定任何事。它的作用是告訴你，你正身處五種截然不同的情形中的哪一種，從而讓你不再對一筆應當批准的退款與一筆應當抗辯的退款發送同樣通用的消費資料。以下說明這個欄位是什麼、Apple 可以發送的確切取值、每一個取值意味著什麼，以及它應當如何改變你所回覆的偏好與證據。

consumptionRequestReason 究竟是什麼

consumptionRequestReason 是 CONSUMPTION_REQUEST 通知 data 物件中的一個字串欄位。Apple 在 App Store Server Notifications 2.11 版本中加入了它，與 WWDC24 對退款流程的改動同步推出。在此之前，請求隨附已簽署的交易到達，卻不帶任何動機資訊。你只能盲目回覆。如今客戶陳述的理由隨請求一同抵達。

請仔細品味「陳述」這個詞。這是客戶在向 Apple 提交時所選擇的理由，並非 Apple 核實過的事實。UNINTENDED_PURCHASE 並不能證明該購買未被使用，UNSATISFIED_WITH_PURCHASE 也不能證明產品有瑕疵。這個取值是一副鏡片，不是一份裁決。你仍需將它與自己的交付與使用紀錄相互印證。

它搭載在你已經處理的通知裡

CONSUMPTION_REQUEST 是 Apple 唯一會向開發者索取證據的流程。它在 Google Play 中的對應物是透過 orders.reviewrefund 進行的拒付審查。當一個請求到達時，你有 12 小時時間透過呼叫 Send Consumption Information 來回覆，那是對交易消費端點發起的一次 PUT。consumptionRequestReason 現在已是同一份通知的一部分，因此沒有任何新東西需要訂閱。如果你已經在解析 CONSUMPTION_REQUEST，這個理由只是一個你多半一直忽略的欄位。

五個理由，以及每一個在告訴你什麼

Apple 明確記載了恰好五個取值。每次請求到達一個。以下是完整清單，以及在實務中如何讀懂每一個。

UNINTENDED_PURCHASE 是誤觸這一類

這是家長在孩子買了 10,000 枚金幣之後所選擇的理由，或者是某個成年人手誤點了確認。它與從未被開啟或使用的購買相關聯。這正是你自己的資料為何重要的原因。如果你的紀錄顯示該消耗型商品已被完整交付並被大量消耗，那麼「非有意購買」的主張與已被花光的餘額並不吻合，而這道落差值得透過 consumptionPercentage 回報。

FULFILLMENT_ISSUE 把矛頭指回你

FULFILLMENT_ISSUE 是唯一一個部分關乎你的應用、而非客戶的理由。它意味著他們說自己無法收到或使用其付費所購之物。在你反射式地提出異議之前，先調出你的交付日誌。如果你自己的伺服器顯示權益從未啟用、或額度從未入帳，那麼客戶是對的，而 DECLINE 就是錯誤的偏好。對一次真實的交付失敗進行抗爭，既浪費視窗，又可能把客戶推向其銀行，而在那裡一次拒付的代價會比原本的退款更高。

UNSATISFIED_WITH_PURCHASE 是證據說了算的地方

這是普通的買家後悔，也是你的消費資料發揮最大作用的理由。產品是好用的。客戶使用了其中一部分或全部，如今想要退款。一個高 consumptionPercentage、一個誠實的 DELIVERED 的 deliveryStatus，以及一個 DECLINE 或 GRANT_PRORATED 的 refundPreference，正是 Apple 要你陳述的案情。發送數字，而不是一番爭辯。

LEGAL 和 OTHER

LEGAL 意味著客戶援引了某項法律或監管權利。明理之人也會有分歧，但作為通則，這不是打官司的視窗。批准它，然後繼續前行。OTHER 是 Apple 在所陳述理由無法歸入上述四者中任何一個時所使用的兜底項。它本身不帶任何訊號，因此對待一個 OTHER 就應當完全等同於對待一個毫無理由的請求：以你的交付狀態與使用證據為先。

理由如何逐欄位改變你的回覆

你透過呼叫 Send Consumption Information 並附上一個 ConsumptionRequest 主體來回覆 CONSUMPTION_REQUEST。理由應當塑造該主體中的三個欄位。

customerConsented 必須為 true

只有當 customerConsented 為 true，即客戶同意分享消費資料時，Apple 才接受該提交。如果你沒有取得該同意，那麼無論理由如何，你根本無法發送任何資料。沒有同意，就沒有證據，請求會在沒有你的數字的情況下被裁決。

deliveryStatus 和 consumptionPercentage 承載事實

deliveryStatus 說明你是否交付了一個可用的購買。如果它是 DELIVERED 之外的任何值，Apple 要求 consumptionPercentage 為 0。當你確實交付了時，consumptionPercentage 是一個以 milliunits 表示、從 0 到 100,000 的整數，其中 100,000 表示客戶使用了整筆購買。這一對是你事實層面的核心，也正是應當承載一個 FULFILLMENT_ISSUE 或一個 UNSATISFIED_WITH_PURCHASE 案情的東西，而非理由本身。

refundPreference 是你唯一的槓桿

refundPreference 是你陳述所求的地方。Apple 記載了三個取值：GRANT_FULL、GRANT_PRORATED 和 DECLINE。讀懂理由，將它與你的資料權衡，然後做出選擇。日誌中顯示交付失敗的 FULFILLMENT_ISSUE 傾向於 GRANT_FULL。產品已被完整消耗的 UNSATISFIED_WITH_PURCHASE 傾向於 DECLINE 或 GRANT_PRORATED。LEGAL 傾向於 GRANT_FULL。

一筆退款究竟讓你付出多少

理由欄位之所以重要，是因為一筆退款很少僅僅是那筆銷售從你的帳本上抹去。對於一個已經跑過的消耗型商品，你為兌現它付出了成本。一個呼叫了付費推論 API 的額度包、一批燒掉了 GPU 時間的生成圖像、一份佔著你儲存帳單的已存匯出檔案、一筆你已經付出的創作者分潤：當購買被撤銷時，這些成本仍是花掉的。商店退還客戶的錢。它不退還你的運算。

這正是為什麼理由值得一讀。假設一位客戶購買了 5,000 個各自觸發一次付費 API 呼叫的額度，花掉了其中 4,000 個，然後以 UNSATISFIED_WITH_PURCHASE 提交。你的 deliveryStatus 是 DELIVERED，你的 consumptionPercentage 是 80,000 milliunits，而一個 DECLINE 或 GRANT_PRORATED 偏好，就是自己吞下這筆 API 帳單與追回其中大部分之間的差別。現在把理由翻轉為 FULFILLMENT_ISSUE，並附上顯示額度從未入帳的日誌，那麼誠實且更省錢的做法就是在客戶升級到其銀行之前選擇 GRANT_FULL。

讀懂理由而不反應過度

陷阱在於把理由當作證據。UNINTENDED_PURCHASE 不是對產品未被使用的招供，LEGAL 也並不總是一項真正的法律主張。理由縮小了情形的範圍。是你的交付日誌與消費紀錄做出定論。當它們與客戶一致時，盡早且低成本地批准。當它們與客戶相矛盾時，那份矛盾，以 deliveryStatus 和 consumptionPercentage 表達出來，就是你能發送的最有力的東西。RefundHalt 會在每一個 CONSUMPTION_REQUEST 上讀取 consumptionRequestReason，並自動將它與你真實的使用資料相配對，從而讓每一個理由在 12 小時視窗內都得到它應得的回應。

這個改動很小、很容易被忽略，但它把退款這場對話推向了對你有利的一方。Apple 現在會在你回覆之前告訴你原因。善用它。