大多數應用程式拒付都能在銀行介入之前被預防，而現在阻止一次，省下的比那筆交易還要多

拒付不是退款，把兩者等同看待，正是應用程式工作室白白損失本不必損失的錢的方式。退款走的是商店：客戶向 Apple 或 Google 提出請求，錢退回去，事情就到此為止。拒付則繞過商店，直接找銀行。客戶告訴發卡機構這筆扣款有誤，發卡機構把錢抽走，往往還有一筆單獨的費用一同發生。對於在 August 3, 2026 之後下單的 Google Play 訂單，那筆費用和損失的交易由開發者承擔，而不是 Google。正是這一處改動，讓應用程式拒付如今值得去預防，也讓它們之中的大多數，都能在銀行介入之前很久就被阻止。

下面這部分對你有幫助。相當大一部分的應用程式拒付並不是精密的詐欺。它們始於一個無法分辨某筆扣款用途的客戶，或者一筆本就不該通過的購買。這兩者你都能採取行動。接下來講的是一套操作手冊：一次敗訴的爭議實際上會花掉什麼、哪些爭議你能預防、哪些詐欺你能從源頭攔截，以及當銀行已經在做決定時，你唯一能發聲的兩個短暫窗口。

為什麼一次拒付比一次退款代價更高

退款和拒付都以客戶拿回錢告終，所以工作室把它們歸進同一個心理帳戶。它們的成本並不相同。退款只退回交易金額，別無其他。拒付退回交易金額，還加上銀行的爭議費用，而這筆費用是固定的，你的價格卻不是。

App Store 與 Google Play 以不同方式分攤這筆帳

在 App Store 上，一次卡片拒付在銀行和 Apple 之間解決，由 Apple 承擔其中的機制。在 Google Play 上，規則變了。對於在 August 3, 2026 之後下單的訂單，Google 只承擔它已經收取的服務費，而開發者要吸收購買價格扣除該服務費的部分，再加上銀行收取的任何拒付費用。Google 將這一變動描述為讓 Play 與支付產業的其餘部分保持一致。

你已經花掉的成本不會回來

被退款或被爭議的金額只是看得見的損失。你已經為服務那筆購買付過錢。跑過生成的運算資源、你被計費的第三方 API 呼叫、你預置的儲存空間，以及你發給創作者的任何分潤，都不會隨著這筆扣款一起沖回。在一件低價的消耗型商品上，僅銀行一筆固定的拒付費用就可能超過客戶所付的金額，而已經沉沒的服務成本還壓在其上。這就是為什麼一次被預防的拒付，價值超過它的標價。

如何在銀行介入之前預防拒付

你無法阻止每一次爭議，但你可以消除它被提出的兩個最常見原因：客戶認不出這筆扣款，以及這筆購買從一開始就是詐欺。處理好這兩點，數量就會下降。

混淆引發的爭議比詐欺更多

當客戶掃過一份對帳單、認不出某一行時，許多人會先致電銀行，才想到聯絡你。你能控制的那個標籤很單薄。Apple 在每一筆購買上都印著 apple.com/bill，並且不給你任何可以更改的設定，所以你的應用程式名稱永遠不會出現。Google Play 會加上 GOOGLE 前綴，然後顯示你在 Play Console 裡設定的對帳單名稱，這是兩家商店給你的唯一一個描述欄位。把它設成你的客戶認得出的名字。

在其他每一處都讓這筆扣款可被辨認

既然你無法修正 Apple 的描述文字，就把它周圍的一切都修好。一筆意外扣款是一種經典的爭議，所以在它到達對帳單之前，就把意外消除掉。

• 一張帶品牌的應用程式內和電子郵件收據，寫明產品名稱和金額，在購買一通過就立即發送。
• 在年度和高價訂閱續訂之前發送一封續訂提醒，讓續訂永遠不會是一場驚嚇。
• 應用程式內的訂閱管理，以及一鍵申請退款的方式，讓客戶先找到你。
• 在爭議窗口內的客服回覆，因為一次迅速的回答往往能阻止客戶把事情升級到銀行。

這些做法中的每一個，都會把一次本會發生的拒付，轉化為一次客服對話或一次普通退款，而退款不帶銀行費用。

從源頭阻止詐欺性購買

那些你沒法用言語開脫的爭議，是那些購買本就是詐欺的。這些你要在它們通過之前，在你的伺服器上，用兩家商店都有文件記載的工具攔下來。

在你自己的伺服器上驗證每一筆購買

永遠不要憑客戶端的一面之詞發放權益。把購買權杖發送到你的後端，對照商店確認它，並把它存起來。Google Play 讓 purchaseToken 全域唯一，所以你可以把它當作主鍵，拒絕任何你見過的權杖，這就扼殺了重放和收據共享。在解鎖任何東西之前，用 Play Developer API 驗證，在 App Store 上則以同樣方式驗證已簽署的交易。

永遠不要交付一筆仍處於待處理狀態的購買

一筆待處理的購買不是到手的錢。Google Play 告訴你，只有當購買狀態為 PURCHASED 時才發放權益，絕不要在它是 PENDING 時發放，因為一筆待處理的扣款仍可能失敗。過早交付，你就把產品交在了一筆可能永遠不會入帳的付款上，這是你自己製造的損失，而不是一場你能抗辯的爭議。

把每一筆購買標記到買家身上

兩家商店都允許你在一筆購買上附加一個帳戶識別碼，這既幫它們發現可疑模式，也幫你把一場爭議對應到某個使用者。在 Google Play 上，用 setObfuscatedAccountId 和 setObfuscatedProfileId 在計費流程上設定混淆後的帳戶 id 和個人資料 id。在 App Store 上，設定一個 appAccountToken，它必須是一個 UUID。給商店餵入好的訊號，它就會在交易完成之前攔下一部分詐欺。

追回並切斷慣犯

當一筆購買被沖銷、撤銷或拒付時，Google Play 的 Voided Purchases API 會通知你，於是你可以追回未使用的商品或把餘額設為負數。對初犯者先警告，然後對再犯的帳戶停用購買或存取權限。一個保住其存取權限的慣性退款者，就是對下一次爭議的邀請。

當一場爭議已經被提出，回應那個窗口

一旦拒付開始運轉，你無法自己沖回它。你能做的，是在一個短暫的窗口內把證據交給商店，讓商店拿著它去與銀行抗辯。

Apple 給你 12 小時

當客戶對一件消耗型商品或一份自動續訂訂閱申請退款時，Apple 會向你的伺服器發送一條 CONSUMPTION_REQUEST，並最多等待 12 小時來獲取消耗資料：你是否交付、用了多少，以及你更希望這筆退款被核准還是被拒絕。仍由 Apple 裁定，但你的回答是這個裁定的一個有文件記載的輸入。

Google Play 給你 24 小時

對於一筆需要審核的有爭議 Play 購買，一條 PendingRefundReviewNotification 會透過 Real-time Developer Notifications 送達，並啟動一個 24 小時的計時。透過 orders.reviewrefund API 提交你的意見和證據，Google 會用它代表你去向銀行抗辯不正當的拒付。讓這個窗口在沉默中關閉，爭議就會在沒有你的情況下推進。

為什麼你無法自己提交銀行證據

支付團隊會談到 Visa 的 Compelling Evidence 3.0，這是一條規則，允許商家透過展示同一憑證上兩筆此前未被爭議的交易來擊敗一場友善詐欺爭議，每筆交易的時間在 120 到 365 天之間，並帶有相符的資料，例如 IP 位址或裝置 id。對於你的應用程式內銷售，你不是登錄商家。Apple 和 Google 才是。所以是商店，而不是你，去組織那種證據，而你的資料抵達這場較量的唯一途徑，就是上面那個審核窗口。這就是 12 小時和 24 小時計時如此重要的現實原因。它們是你在談判桌上的全部席位。

爭議前檢查清單

這些都不稀奇。這是一份你可以在下一個計費週期之前落實的短清單。

• 設定一個可被辨認的 Google Play 對帳單名稱，並在其他每一處發送帶品牌的收據。
• 在年度和高價扣款之前發送續訂提醒。
• 把訂閱管理和退款申請放到應用程式內一鍵可達的位置。
• 在你的伺服器上驗證每一筆購買，並把權杖作為唯一鍵儲存。
• 只在 PURCHASED 狀態下發放權益，絕不在 PENDING 狀態下發放。
• 給每一筆購買附加一個帳戶 id 或一個 UUID appAccountToken。
• 設定 Apple 和 Google 的通知消息流，並在窗口內回應每一次消耗請求和退款審核。