Apple 的 Retention Messaging API 能把你的話放上取消畫面，但退款申請從不經過那裡

在 iPhone 上點選取消的訂閱者，現在可以在確認之前看到你選擇的訊息、一個更便宜的方案或一項折扣。這就是 Apple 的 Retention Messaging API，也是開發者第一次能在 Apple 自己的取消畫面上發聲。它仍是預先發布功能，必須申請才能加入。如果你在意退款，它還有一條硬性界線：它面對的是即將停止付費的人，而不是要求退錢的人。退款申請走的是另一條路。

Apple 的 Retention Messaging API 能做什麼

Retention Messaging API 是一項伺服器對伺服器的服務。你事先把訊息文字和圖片上傳給 Apple，Apple 審核後，你再決定訂閱者在即將取消自動續訂型訂閱時看到哪一則已核准的訊息。Apple 的文件列出四種訊息類型：

• 文字訊息，可以包含項目符號。
• 附圖片的文字訊息。
• 換方案訊息，建議同一訂閱群組中的另一項訂閱。
• 促銷優惠訊息，以相同或不同級別的折扣價提供優惠，使用你在 App Store Connect 中設定並在伺服器上簽署的促銷優惠。

訊息會在顧客於訂閱詳細資料頁面點選 Cancel Subscription（取消訂閱）之後出現。接著 Apple 會顯示 Confirm Cancellation（確認取消）頁面。顧客仍然可以取消、點選 Keep Subscription（保留訂閱），或接受你建議的優惠或方案。你無法隱藏退出的路徑，Apple 也要求開發者不要上傳誤導或不正確的內容。

預設訊息與即時流程

執行方式有兩種。簡單的一種是預設訊息：依產品和語言地區指定的文字，可附或不附圖片、項目符號。更豐富的一種是即時流程：Apple 呼叫你伺服器上的 Get Retention Message 端點，你以一個訊息 ID 回應。只有即時流程才能顯示換方案和促銷優惠訊息。

實務上預設訊息並非可有可無。每當即時呼叫失敗，Apple 都會以預設訊息作為備援；對於缺少預設訊息的語言地區，Apple 不會為該產品顯示任何挽留訊息。

即時呼叫中 Apple 會告訴你的伺服器什麼

請求是一個由 App Store 簽署的 JWS。解碼後包含 originalTransactionId、appAppleId、productId、userLocale、一個 requestIdentifier UUID、環境以及 signedDate。Apple 要求你核對 appAppleId 是否與你的 App 相符，不相符就不要回應。真正有用的是 originalTransactionId，因為它讓你在決定要說什麼之前，先查出這位訂閱者在你的 App 裡實際做過什麼。

挽留訊息會出現在哪裡，又不會出現在哪裡

Apple 只在一個畫面上放置這則訊息，也就是顧客點選 Cancel Subscription 之後的 Confirm Cancellation 步驟，例如從 Apple Account > Subscriptions 或 App Store 上某項訂閱的頁面進入。這個畫面關乎下一次續訂是否發生，不涉及已經收取的錢。

退款申請是另一回事。Apple 的支援頁面會引導顧客前往 reportaproblem.apple.com，在那裡選擇 Request a refund（申請退款），挑選原因和項目，然後等待 24 到 48 小時取得進度。在你的 App 內，StoreKit 的 beginRefundRequest 會開啟 Apple 的退款表單，Apple 表示 App Store 最多需要 48 小時核准或拒絕。兩條路徑都不經過 Confirm Cancellation 畫面。

挽留訊息能阻止退款申請嗎？

不能。退款申請根本不會抵達顯示訊息的那個畫面。Apple 的通知文件中有一個細節讓這點非常具體：當顧客在你的 App 內透過退款申請 API 申請退款時，Apple 會自行關閉自動續訂，並傳送子類型為 AUTO_RENEW_DISABLED 的 DID_CHANGE_RENEWAL_STATUS。從「訂閱項目」設定頁面取消的顧客產生的類型和子類型完全相同。你的伺服器為兩種截然不同的顧客收到同一種通知，而其中只有一位看過你的挽留訊息。

如果退款申請繼續進行，提交證據的管道是 CONSUMPTION_REQUEST。Apple 會針對任何產品類型的退款申請傳送它，你有 12 小時以 Send Consumption Information 回覆。只有在顧客同意的情況下你才可以回覆。之後，Apple 的決定會以 REFUND 通知送達；若 Apple 拒絕了顧客在你 App 內發起的退款，則以 REFUND_DECLINED 送達。

Google Play 有取消訊息 API 嗎？

Google 的訂閱生命週期文件中沒有。Google Play 訂閱者在 Play 訂閱中心取消，存取權會保留到目前帳單週期結束，在此之前可以點選 Resubscribe（重新訂閱）撤銷取消，Google 稱之為恢復。你會在事後透過 SUBSCRIPTION_CANCELED 通知得知，訂閱資源中的 userInitiatedCancellation 欄位會告訴你使用者離開的原因。暫停功能是 Google 用來降低主動流失的主要內建手段，Google 表示所有訂閱預設啟用此功能。

在退款方面，Google Play 有自己的證據管道。當退單需要開發者審查時，會收到 PendingRefundReviewNotification，你有 24 小時透過 orders.reviewrefund 回覆。對於 2026 年 8 月 3 日之後成立的訂單，退單一旦成立，Google 會把購買價格（扣除 Play 服務費）連同銀行的退單手續費一併轉嫁給開發者。

取消畫面在金錢上讓你付出什麼

挽留訊息看起來是免費的。其實不是，帳單落在三個地方。

每次頁面瀏覽都要消耗運算資源

Apple 會在有效訂閱者檢視帶有取消按鈕的訂閱詳細資料頁面時呼叫你的端點，而不只是在他們取消時。每一次造訪都是一個請求，你的伺服器必須在 700 ms 內完成驗證、查詢和回應，否則 Apple 會改用預設訊息。這就排除了偶爾需要兩秒冷啟動的函式。你要為始終保持暖機的容量付費，還要負擔決策邏輯在每個請求中產生的資料庫讀取和付費第三方 API 呼叫。

折扣是你選擇放棄的營收

留住訂閱者的促銷優惠是實實在在保住的錢。給了一個本來就會留下的人，就純粹是讓利。以下是示意，不是基準數據。一個 $9.99 的月訂方案以半價提供三個月，每接受一次優惠就少收 $14.99。如果接受優惠的人中有三分之一本來就會以全價留下，那麼一千次接受就代表約 $5,000 的折扣給了根本不需要的人。帳本的另一邊，是那些真的要離開的訂閱者。

糟糕的退出體驗招來的退款

Apple 會把 Cancel Subscription 按鈕留在頁面上，所以你困不住任何人，但你仍然可能惹人厭煩。感到被逼迫的顧客還有另一個選擇，就是向 Apple 要回最近一筆扣款。退款一旦發生，錢會退回去，而與該訂閱者相關的運算、儲存、API 呼叫和聯盟分潤都已經花掉了。這些成本是任何挽留訊息都收不回來的。

如何使用挽留訊息而不推高退款率

把取消畫面當作講求準確的地方，而不是耍小聰明的地方。以下幾條規則能讓它留在退款界線的安全一側：

• 依訂閱者個別決定。用 Apple 請求中的 originalTransactionId 查詢近期使用情況。給真正在使用產品的人提供折扣或更便宜的方案。給好幾週沒開啟過的人一則簡短、誠實的訊息。
• 保持快速回應。在使用資料變動時預先算好決策，讓請求本身只需一次查詢，輕鬆控制在 700 ms 以內。
• 為每個產品和語言地區都寫一則預設訊息。沒有預設訊息，呼叫失敗就代表什麼都不顯示。
• 密切留意 AUTO_RENEW_DISABLED。如果同一個 originalTransactionId 隨後出現 CONSUMPTION_REQUEST，你面對的就是退款申請而不是取消，12 小時的倒數已經開始。
• 回覆每一個你被允許回覆的 CONSUMPTION_REQUEST。RefundHalt 會在 12 小時期限內向 Apple 傳送準確的消費資料，並在 24 小時內回覆 Google Play 的退單審查，因為這是兩家商店僅有的兩個徵詢你方說法的時刻。

值得向 Apple 申請權限嗎？

如果你銷售自動續訂型訂閱，而且已經在處理 App Store Server Notifications V2，那麼大概值得。取消畫面是訂閱者離開前你能接觸到他們的最後一個地方，而換方案的代價比徹底失去他們要小。只是要為一個在每次訂閱頁面瀏覽時都要回應的端點編好預算，並把退款防線放在退款真正發生的地方。