退單和退款的差別在於由誰決定，而只有一種是無法挽回的

有兩個詞經常被當作同義詞來用。反正顧客都會拿回錢，誰還在乎到底是哪一種。可對於透過 App Store 或 Google Play 銷售的應用程式開發者來說，退單和退款的差別決定了這個結果由誰掌控、你本可以做出什麼改變，以及從本月起，這次款項撤銷會從你帳戶裡拿走多少。

簡短版本是這樣。退款是商店把錢退回去，由商店決定。退單是顧客的銀行把錢拉回去，由銀行決定，沒有申訴餘地。在這兩種情況裡，你所處的位置截然不同。下面來看它們在 Apple 和 Google 上分別是什麼樣子，商店真正會向你索取東西的兩個時刻，以及兩者之間的差距如今要花你多少錢。

退單和退款的差別在於由誰決定

剝去支付術語，有一個問題把兩者區分開來：由誰做最終決定。退款是在商店自己的系統內部做出的決定。退單是在顧客的銀行做出的決定，比任何商店設定能觸及的範圍還要往外一層。僅憑這一點，就決定了其餘的一切，從你能否申辯到它要花你多少錢。

誰發起，誰決定

退款可以有兩種發起方式。顧客向商店索取退款，或者你自己發起退款。無論哪種，商店，也就是 Apple 或 Google Play，都會核准並把錢退回去。退單只有一種發起方式。顧客完全繞過商店，直接向自己的銀行或卡片組織對這筆扣款提出爭議，銀行便從商店的支付系統裡把錢扒回去。商店沒有選擇它，你也沒有。

賣家是商店，不是你

這一點常讓從傳統電商轉行過來的開發者栽跟頭。當你透過 App Store 或 Google Play 銷售時，你不是記錄在案的商家。Apple 和 Google 才是。顧客的信用卡帳單上寫的是 Apple 或 Google，而不是你公司的名字。所以當那位顧客對扣款提出爭議時，退單會先落到商店的支付系統上。跟銀行通電話的不是你。你只能透過商店得知，前提是商店願意告訴你。

兩者對照

退款在 App Store 和 Google Play 上是什麼樣子

大多數退款不是一場讓你能參與的對話。商店接下請求，對照自己的規則核查，然後把錢退回去。你事後才被告知，前提是你接好了傳遞這個消息的通知。

Apple 先決定，再告訴你的伺服器

Apple 顧客在 reportaproblem.apple.com 上請求退款，Apple 有自購買起最長 90 days 的時間來受理這項請求以供審核。Apple 會自行審核每個案例並做出決定。當它核准退款時，你的伺服器會透過 App Store Server Notifications V2 收到一則 REFUND 通知，該交易此時會帶上一個 revocationDate。當它拒絕請求時，你會收到 REFUND_DECLINED。如果 Apple 之後撤銷了一筆已經核准的退款，你會收到 REFUND_REVERSED，這筆銷售又回來了。在這些情況裡，你都沒有投票權。你只是做出反應。

Google Play 退掉大多數購買時不會問你

Google Play 允許顧客在購買後 48 hours 內直接從帳戶自助退款，全程完全沒有開發者參與。超過 48 hours 後，顧客會被引導到你這裡，你可以按自己的政策核准或拒絕。客服可以發起退款，而一筆未確認的購買會在大約 72 hours 後被自動退款。所有這些都在 Google 那一側運行。你透過一則已作廢購買通知或 Voided Purchases API 看到結果，你的任務是撤銷存取權限，而不是核准退款。

商店真正會向你索取東西的兩個流程

在兩家商店裡，恰好有兩個時刻，商店會停下來，在做決定之前向開發者索取證據。當顧客請求退款時，Apple 會發出一則 CONSUMPTION_REQUEST，給你 12 hours 透過 Send Consumption Information 附上使用資料來回應。Google Play 會發出一次退單審核，給你 24 hours 透過 orders.reviewrefund API 來回應。其餘一切都在沒有你的情況下決定。這兩個視窗是你的輸入唯一能改變結果的地方，正因如此它們值得自動化，其餘的則值得監控。

退單是什麼樣子，以及它為什麼無法挽回

退單不是多幾個步驟的退款。它是一套不同的機制，決策者也不同，而這改變了你能對它做些什麼。

是銀行把錢拉回去，不是顧客

在退單裡，顧客告訴自己的銀行這筆扣款有問題，可能是詐欺、無法辨識，或從未交付。銀行預設站在自己的持卡人一邊，撤銷這筆交易，透過卡片組織把錢拉回去。商店沒有核准它。在任何人問起產品是否已交付之前，錢已經沒了。這就是為什麼退單又慢又重，而退款又快又乾淨：它要走卡片組織的爭議流程，那需要數週或數月，而不是幾分鐘。

銀行的決定是最終的

你沒法像撤銷退款那樣推翻一次退單。銀行一旦裁定，那個裁定就成立了。你唯一能施加影響的地方，是在它被決定之前。在 Google Play 上，銀行發起的爭議可能會開啟一次審核，Google Play 會給你的伺服器發一則通知，附帶一個 24 小時的倒數計時。透過 orders.reviewrefund 附上退款傾向和真實的消費證據來回應，Google Play 就會把你的輸入納入它替你申辯退單的方式裡。錯過這個視窗，爭議就會在唯一知道產品如何被使用的一方缺席的情況下了結。

每一種到底要花你多少錢

很長一段時間裡，誠實的答案是：退單和退款對應用程式開發者的成本大致相同，就是這筆銷售，加上你為交付它已經花掉的一切。本月起，這對 Google Play 開發者來說不再成立了。

退款從來都不是唯一的數字

無論這次撤銷是退款還是退單，那筆付款從來都不是你唯一的成本。一段生成的影片、一批模型 API 呼叫、一筆創作者分潤、你預置的儲存空間，所有這些錢在你交付訂單的那一刻就離開了你的帳戶，而當扣款被撤銷時，它們一分都不會回來。銷售是看得見的數字。運算資源、API 呼叫、儲存空間和分潤，才是那些已經落袋的數字。要以已交付的價值來為這次撤銷申辯，絕不要以顧客等了多久來申辯，因為流逝的時間不是成本，Apple 和 Google 也不把它當成本。

從 2026年8月3日 起，退單會多出一筆銀行手續費

這就是兩者不再花費相同的地方。到目前為止，Google Play 一直吸收退單的下游成本。對於在 2026年8月3日 之後下的訂單，Google Play 會把這筆成本轉給開發者。爭議敗訴時，你要退回扣除 Play 服務費後的購買款，除此之外，你還要支付金融機構收取的退單手續費。Google Play 仍然繼續承擔服務費那一部分。退款不帶這筆銀行手續費。所以一筆以退單收場的扣款，如今花你的錢嚴格多於同樣一筆被退款的扣款，多出來的就是銀行的手續費。

這一變化背後的規模

Google Play 表示，它在 2025 年攔截了 US$3.4B 的詐欺與濫用，並且在整個 2026 年仍在增加詐欺偵測。把退單成本轉到開發者身上是這股推力的一部分。它給了你一個直接的理由，把證據餵進審核流程，好讓系統去申辯更多不正當的爭議。你的證據才讓申辯成為可能，而一份空白的回應，就是投票讓一次善意詐欺式的退單，在你的錢上成立。

如何讓退款不變成退單

最便宜的退單，是那筆從未發生的退單，因為這筆訂單先被退了款，或者被一份早已備好的證據申辯掉了。這一切都不需要有人在恰當的時刻醒著盯著。它需要的是在爭議發生之前就把管線鋪好。

搶在銀行之前自己把壞訂單退掉

如果一筆訂單擺明著要被提出爭議，自己把它退掉比輸掉退單更便宜。你自己發起的退款不帶銀行的退單手續費。在 Google Play 上，你只需一次 orders.refund 呼叫，就能退掉任何不到三年的訂單，撤不撤銷存取權限都行。搶在顧客找上銀行之前做到這一點，你就把一筆銀行手續費加一筆損失的銷售，變成了僅僅一筆損失的銷售。

自動回應這兩個證據視窗

Apple 的 12 小時視窗和 Google Play 的 24 小時視窗，對機器來說很從容，對必須一直盯著的人來說卻很折磨。回應應當是自動的：通知進來，查出帳戶，組裝好消費資料，一次呼叫出去，中間沒有人。這正是 RefundHalt 替你運行的部分。我們偵聽 CONSUMPTION_REQUEST 和 Google Play 的退單審核，把訂單匹配到我們本就在追蹤的使用情況，並在視窗內附上退款傾向和真實的消費證據來回應。

提前附上身分標識並記錄消費

在爭議發生時你需要的證據，必須在爭議之前就已存在。給每一筆購買設定一個帳戶識別碼，讓一則通知能直接對映到某個使用者，在 Apple 上是一個 appAccountToken UUID，在 Google Play 上是一個不超過 64 characters 的雜湊 setObfuscatedAccountId，絕不要用明文個人資料。記錄下每一筆付費訂單交付了什麼、何時交付、交付給誰，以一種你能隨時轉換成消費百分比的形式。做到這些，那個狹窄的視窗就足夠了，因為當權杖到來時，案子早已備好。