Google Play 的拒付審查給你 24 小時反擊，以下是你該傳送的內容

當客戶的銀行撤銷一筆 Google Play 扣款時，Google Play 不會只是退款然後就此了事。它會向你的伺服器傳送一則 PendingRefundReviewNotification，並啟動一個 24 小時的倒數計時。透過 ReviewRefund API 回應這則通知，附上退款傾向以及客戶實際使用情況的證據，Google Play 就會把你的意見納入它對這筆拒付的抗辯。保持沉默，這場爭議就會在唯一知道產品如何被消費的一方一言不發的情況下被裁定。

Google Play 的拒付審查是 Android 上唯一一個向你索取證據的退款流程，是 Apple 的 CONSUMPTION_REQUEST 的直接對應物。它如今比過去更重要。從 2026 年 8 月 3 日起，Google Play 把拒付的成本轉移到開發者身上，所以一場你未能回應的爭議將從你的帳戶裡扣除，而不是 Google 的。以下就是這則通知攜帶了什麼、你要回傳什麼、構成你證據的各個欄位，以及沉默在哪裡變成了金錢。

Google Play 拒付審查究竟是什麼

拒付並不是一次退款請求。客戶找到他們的銀行或卡組織並對這筆扣款提出異議，然後銀行把資金撤回。Google Play 大多數情況下會自行處理這些。對於其中一部分，它會開啟一次審查並先詢問你，因為你掌握著 Google 沒有的資訊：訂單是否已交付，以及客戶消費了其中的多少。那次審查就是 ReviewRefund API 背後的流程。

這是 Android 退款系統中唯一一個你的證據能改變結果的地方。其他每一條 Google Play 退款路徑都在沒有你的情況下運行。客戶可以在購買後 48 小時內自助退款，客服可以給予退款，未確認的購買會被自動退款，全部由 Google 裁定。拒付審查是例外，值得把它當作你實際能參與的唯一一次退款對話來對待。

它是 Apple 證據視窗的 Android 版本

兩家商店，兩個向開發者索取證據的流程，全部就這些。Apple 傳送一則 CONSUMPTION_REQUEST，給你 12 小時用 Send Consumption Information 來回應。Google Play 傳送一則 PendingRefundReviewNotification，給你 24 小時用 orders.reviewrefund 來回應。機制不同，但道理完全一致：當商店問客戶使用了什麼時，一個精確的回答就是留住這筆銷售和把它交回去之間的區別。

有一個差別在實務中很重要。Apple 的消費酬載是五個數字欄位，別無其他。Google Play 的證據更豐富。你可以傳送一個消費百分比，外加一份逐條的使用事件清單，每條都帶有時間戳記、一個帳戶識別碼，甚至一個 IP 位址和粗略位置。Google Play 給了你更多空間來描述交付，也就意味著更多讓人信服的空間。

24 小時倒數計時以及通知如何抵達你

這次審查作為一則 Real Time Developer Notification 抵達你的 Cloud Pub/Sub 主題，與投遞你的訂閱和購買事件的是同一條通道。訊息是一段 base64 編碼的酬載，裡面有一個 pendingRefundReviewNotification 物件。倒數計時在那則通知被發佈時開始，而不是在你恰好讀到它時，所以一個每天只輪詢一次的消費者就是一個會錯過爭議的消費者。

PendingRefundReviewNotification，逐個欄位來看

這則通知很小。它告訴你哪個訂單正在被審查，把你必須回傳的權杖交給你，並寫明原因。以下是它攜帶的每一個欄位。

只有拒付才會開啟一次待處理審查

待處理審查上的 refundReason 始終是 CHARGEBACK，以整數 7 的形式送達。Google Play 的世界裡還存在其他退款原因，但它們不會透過這個流程抵達你，因為你對它們沒有發言權。如果你看到一則 PendingRefundReviewNotification，說明一家銀行已撤銷了一筆扣款，而 Google Play 正在決定是否對它提出抗辯。那是唯一的觸發條件。

你透過 ReviewRefund API 回傳什麼

你用一次向 orders.reviewrefund 的 POST 來回應。完整路徑是 POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}:reviewrefund，用 https://www.googleapis.com/auth/androidpublisher 範圍授權，就是你的 Play Developer API 整合已經在用的那個 OAuth 範圍。成功會回傳一個空正文，附帶 HTTP 200。

正文才是你的案情所在。你回傳通知裡的 pendingRefundToken，聲明一個退款傾向，並附上消費證據。

你的退款傾向是一個建議，不是一個裁決

refundPreference 欄位取三個值之一，它是給 Google Play 的建議，而不是一個最終決定。結果仍由 Google 掌控。但它是有 Google 自己看不到的資料支撐的建議，所以它有分量。

支撐 DECLINE 的證據欄位

一個光禿禿的 DECLINE 是沒有證明的主張。消費欄位就是那份證明。consumptionPercentageMilliunits 是一個以毫單位計的整數，所以 100000 表示客戶消費了他們所購買的 100%，而 50000 表示一半。consumptionUsageEvents 是一個可選陣列，其中每個事件可以攜帶一個 obfuscatedAccountId、一個 obfuscatedProfileId、一個 consumptionTime、一個 ipAddress、一個 consumptionItemDescription，以及一個粗略的 location。sampleContentProvided 是一個布林值，用於你給了客戶付費內容免費樣本的情形。它們合在一起，用 Google Play 自己的架構說明，產品已經交付並被使用。

你的第一次呼叫就是你唯一的呼叫

Google Play 會記錄你針對一則通知發出的第一次 ReviewRefund 呼叫，並忽略它之後的每一次呼叫，同時仍然回傳一個 OK 狀態。沒有草稿，也沒有修訂。如果你的第一次回應是一個匆忙的、沒有證據的 NEUTRAL，因為你的流水線還沒準備好，那就是記錄在案的回應，而後面那次帶著完整消費歷史的呼叫會被悄悄丟棄。在你傳送任何東西之前，先建構好完整的答案。

這次審查在金錢上讓你付出什麼

多年來，一場輸掉的 Google Play 拒付只讓開發者損失這筆銷售，別無其他，因為 Google Play 吸收了下游的費用。這在 2026 年 8 月 3 日結束。對於在那個日期之後下的訂單，Google Play 與開發者分擔拒付成本，而開發者那一份是購買價格減去 Play 的服務費，再加上金融機構收取的相關拒付費。Google Play 繼續承擔服務費那一部分。銀行費用是壓在你這一側帳本上的新重量。

退款從來不是真正的數字

這場爭議退回了客戶的付款，但那筆付款從來不是你唯一的成本。一段生成的影片、一批模型 API 呼叫、一筆創作者分成、你預置的儲存空間，所有這些錢都在訂單交付的那一刻離開了你的帳戶，而其中沒有一分錢會隨著拒付回來。現在再加上銀行的拒付費。你在支付供應商的帳單、退還銷售款，並承擔爭議費，為一個你本有證據可以辯護的訂單支付三重成本。

Google 正在對抗的規模

Google Play 表示它在 2025 年攔截了 US$3.4B 的詐欺和濫用，並將在整個 2026 年增加詐欺偵測。這項成本分擔的變化是同一推動的一部分：給開發者一個把證據餵進系統的理由，系統就會對更多不正當的爭議提出抗辯。ReviewRefund API 就是你的證據進入系統的途徑。一個空白的回應，就是投票讓一場善意詐欺的拒付用你的錢站住腳。

如何在通知落地之前就做好準備

24 小時的視窗不是問題。問題在於你需要的證據必須在爭議之前就已存在，在購買和消費時擷取，而不是在權杖出現之後再重建。一個在通知抵達時才開始蒐集資料的團隊已經輸了。

在購買時附上身分

在每一筆購買上用 setObfuscatedAccountId 設定一個 obfuscatedAccountId，這樣通知裡的帳戶 id 就能直接對應到你系統裡的一個使用者。把它保持為一個雜湊值，64 個字元或更少，絕不能是明文電子郵件或其他個人資料，因為明文識別碼會導致購買被攔截。沒有那條連結，你就無法把 pendingRefundToken 連到一段真實的使用歷史，你的 DECLINE 背後也就一無所有。

在消費發生時就記錄它

記錄一筆付費訂單交付了什麼、何時、給了誰，以一種你能按需轉換成 consumptionPercentageMilliunits 和 consumptionUsageEvents 的形式。

• 給每一個消費單位打上時間戳記，這樣每個事件上的 consumptionTime 是真實的，而不是估算的。
• 對照購買來追蹤交付，這樣你就能有信心地陳述一個消費百分比，而不是猜測。
• 把帳戶和檔案識別碼保存在使用記錄旁邊，這樣當權杖抵達時，一個事件就能在一次查詢裡組裝出來。
• 如果你有的話，擷取請求 IP 和粗略位置，因為 Google Play 接受這兩者作為事件欄位。

在視窗內自動回應

24 小時的視窗對一台機器來說很從容，對一個必須清醒並保持專注的人來說卻很殘酷。回應應該是自動的：通知進來，帳戶被查出，消費被組裝，一次 ReviewRefund 呼叫發出，全程沒有人參與。那正是 RefundHalt 為你運行的部分。我們監聽 PendingRefundReviewNotification，把訂單匹配到我們已經為那個帳戶追蹤的使用資料，並在視窗內用一個退款傾向和真實的消費證據回應 orders.reviewrefund。權杖是那根線，證據是那件案子。把兩者都準備好，你能參與的這一次退款對話就是一次你能贏的對話。