你的消耗資料只是為 Apple 的退款決定提供參考，而非決定它

客戶點了退款，一分鐘內你的伺服器就收到了來自 Apple 的 CONSUMPTION_REQUEST。你有 12 小時用消耗資料來作答，而人們很容易把這則回覆當成一票否決：傳送傾向拒絕，把錢留住。它不是一票否決。Apple 自己的文件寫道，App Store 會用眾多因素來決定一筆退款申請是獲准還是被拒，而你提供的消耗資訊被用來為它的退款決定提供參考。是提供參考，不是決定。這篇文章會梳理你的消耗資料實際能撼動什麼，為什麼一筆你標記為傾向拒絕的購買仍可能被退款，以及一旦把你已經花掉的錢計算在內，整件事到底值多少。

Apple 究竟拿你的消耗資料做什麼

Send Consumption Information 端點的存在，是為了讓你能在退款存疑的那一刻把背景資訊交給 Apple。它並不把決定權交給你。以正確的順序理解這個流程，是在合理設定預期，與針對一個文件已寫明的行為提交 bug 之間的區別。

App Store 作決定，而你作推薦

Apple 對這種分工說得很明白。在 Send Consumption Information 參考文件裡，Apple 寫道 App Store 會用眾多因素來決定一筆退款申請是獲准還是被拒，並且它會用你提供的消耗資訊為其退款決定提供參考。在 refundPreference 欄位本身的說明裡，Apple 表示你的退款偏好是 App Store 用來為其退款決定提供參考的眾多因素之一。所以你能發出的最強訊號，一個乾脆的傾向拒絕，仍然只是你無法掌控的模型中的一個輸入。客戶的歷史紀錄、他們給出的理由、商品類型，以及 Apple 自己的詐騙訊號，全都和你的回覆並列在同一個模型裡。

CONSUMPTION_REQUEST 如今涵蓋訂閱，而不僅是消耗型商品

這曾經是一個只關於消耗型商品的故事。自 WWDC24 起，當客戶為一件消耗型應用程式內購買或一項自動續訂的訂閱申請退款時，CONSUMPTION_REQUEST 通知都會觸發。這是涵蓋面的一次大幅擴張。同樣的 12 小時回覆如今也適用於訂閱退款，而你在那裡的籌碼有所不同，因為 Apple 會自行為自動續訂商品計算消耗量，並且不會接受你給出的按比例偏好。在決定你的回覆能推得多用力之前，先讀一讀每個請求上的商品類型。

你被允許傳送的五個輸入

Apple 接受的 V2 請求主體很小，五個欄位承擔了全部工作，其中三個是必填的。每一個都是 Apple 會權衡的輸入，而不是一個強制結果的開關。以下是你能放進回覆裡的內容，以及它告訴 Apple 什麼。

12 小時的視窗，以及大多數團隊會漏掉的同意關卡

有兩個機制決定了你的回覆是否算數。一個是時鐘。另一個是一個同意標誌，它會把許多出於好意的回覆擋在門外。

在 12 小時內回應，否則時機就過去了

Apple 的指示很直白：在收到 CONSUMPTION_REQUEST 通知後的 12 小時內回應。這就是全部視窗。一筆退款申請不會等你下一個工作日，而一條遲到的消耗回覆，是一條 Apple 從未權衡過的回覆。如果你在手工作答，這個 12 小時時鐘正是會最先悄悄失守的部分，在週末、在假日、在你所在時區的凌晨三點。回覆必須自動化才可靠，因為這個視窗不在乎你的團隊什麼時候醒著。

除非客戶同意，否則你無法傳送資料

這就是讓各團隊栽跟頭的關卡。對於一個 customerConsented 值不為 true 的 Send Consumption Information 請求，Apple 會拒收。用 Apple 的話說，如果客戶提供了同意，就透過呼叫 API 並傳送消耗資料來回應；如果沒有，就不要回應 CONSUMPTION_REQUEST 通知。Apple 還把責任明明白白地壓在你身上：在分享客戶個人資料之前，你必須取得客戶的有效同意，而作為開發者的你，對取得它負全部責任。所以每個請求上的第一個問題不是他們用了多少，而是這位客戶是否同意讓我們告訴 Apple。沒有同意，就沒有回覆，而這筆退款會在除你那一方陳述以外的一切之上被決定。

究竟是什麼在撼動 Apple 的退款決定

如果這條回覆是一份推薦，那麼誠實的問題是它推薦得有多重。答案是，你的資料恰恰在人會猶豫的地方最要緊，而在結果本就毫無懸念的地方最不要緊。

為什麼你傳送了傾向拒絕，仍會看到退款

有開發者反映，他們在一筆客戶已完全消耗的購買上傳送了傾向拒絕，卻眼看 Apple 照樣退了款。這不是 API 壞了。Apple 告訴過你它會權衡眾多因素，而在任何一個具體請求上，其中某些因素都可能壓過一件已完全消耗的消耗型商品：一位歷史紀錄乾淨的客戶、一個被 Apple 視為有力的陳述理由、一筆小額金額、一次首次申請。你的回覆在向退款反向施力。其他輸入施力更狠。教訓不是停止回覆，而是不要再指望一件乾淨的消耗型商品總能撐過去。在訊號確實混雜的地方，一個部分消耗狀態、一份有記錄的交付問題，以及一個誠實的偏好，才是能把一個臨界情形扳向你這一邊的輸入。

一份推薦值多少錢

一筆退款不等於這筆銷售的價格。它等於銷售價格加上你為交付它已經花掉的一切，而消耗回覆觸及的永遠只有前一部分。

請求到來時，錢早已花掉

等到 Apple 問是否要退款時，客戶早已用掉了那件東西。在一件消耗型商品上，這意味著運算已經跑過、第三方 API 呼叫已經計費、圖像或 token 或生成結果已經產出、儲存已經寫入。這些在你這一方都是已付成本，如果 Apple 拒絕退款它們不會回來，如果 Apple 批准退款它們就賠了兩次。你的消耗回覆能在一個臨界情形上贏回銷售價格。它贏不回你已經交出去的貨物成本。這才是一件已完全消耗的購買是退起來最貴的那一筆的真正原因，而這與它是多久以前買的毫無關係。

• 銷售價格：在 Apple 抽成後你的淨收入，若退款獲准則被沖回。這是你的回覆唯一能影響的部分。
• 交付成本：運算、API 呼叫、儲存，以及你已針對這筆購買作出的任何支付。無論決定如何都已不再。
• 人力時間：每一筆手工作答的退款都是某人一天裡的幾分鐘，而 12 小時視窗意味著這些分鐘落在不方便的時段。
• 你漏掉的模式：一位一次又一次退款的客戶是一項成本，而你只有在跨請求追蹤消耗與歷史、而不是把每一筆都當成一次性事件時，才看得見它。

Google Play 如何處理同樣的問題

Apple 並不是唯一一家先請你發表意見、再自行決定的商店。Google Play 為銀行拒付款運行著一套平行的流程，而其形態是一樣的：你傳送證據，商店作決定。差異在於那個時鐘，以及你被允許傳送什麼。

兩家商店給出的要點是一模一樣的。你的工作是在視窗內用準確的消耗證據和一個誠實的偏好來作答。商店的工作是作決定。把兩者搞混，就是一個團隊最終要麼因為回覆只是一份推薦而忽視視窗，要麼把回覆當成一票否決、在退款照樣落地時被打個措手不及的原因。兩者都不對。每次都作答，作答要準確，並把結果當成一個你為之提供了參考的決定，而不是一個由你作出的決定。

RefundHalt 會在 Apple 發出 CONSUMPTION_REQUEST 的那一刻就將它接住，核對同意，組裝消耗狀態、交付狀態和一份基於證據的退款偏好，並在 12 小時視窗內作答，無需你團隊裡的任何人盯著時鐘。它為 Google Play 的拒付款審核在其 24 小時視窗內做的是同樣的事。你無法讓 Apple 按你的意思來決定。但你可以確保 Apple 永遠不會在沒有你那一方陳述的情況下作出決定，在每一筆退款上，且都趕得及。