待處理購買看起來像一筆銷售，但錢還沒到帳，提前發放就等於把產品白白送出去

有人在你的應用程式裡點了購買。你的記錄檔顯示一筆新訂單，你的計費監聽器觸發，於是你交付了商品。對絕大多數購買來說，這樣做完全正確。但對待處理購買來說這是個錯誤，因為訂單存在，錢卻不存在。客戶選擇了一種稍後才結算的付款方式，商店還在等著收款，而你剛剛為一筆可能永遠不會到帳的收費交付了一項付費功能。這是退款那沉默的表親。這裡沒有任何東西被撤銷，因為從來就沒有收到過任何錢。你只是把產品白白送了出去。

待處理購買是一筆處於尚未付款狀態的真實訂單，App Store 和 Google Play 都有這種狀態。兩家商店都明白地告訴你要等待。陷阱在於，待處理訂單在你的程式碼裡看起來幾乎和已完成訂單一模一樣，因此一個把每筆新購買都當作銷售的整合，會在商店還在嘗試收款的訂單上就交付商品。處理得當，你不會有任何損失。處理不當，每一筆未能成立的慢速付款都是純粹的成本，由你自掏腰包交付。

待處理購買究竟是什麼

待處理購買是商店已經記錄但尚未扣款的訂單。買家開始了流程，商店受理了它，而結算正在你的應用程式看不到的某個地方進行。Google Play 把這稱為 PENDING 狀態。Apple 稱之為待處理交易，或延遲交易。名稱不同，事實相同：商店在等待收款的同時讓一筆訂單保持開放，並且它已經告訴你不要把那筆訂單當作錢。

Google Play：付款正在別處進行

有些付款方式是透過外部管道結算的。實體門市現金、銀行轉帳以及部分電信帳單代收，都在點擊與扣款之間需要額外的步驟。當客戶選擇其中一種時，Google 回傳的購買處於 PENDING 狀態而不是 PURCHASED。對於現金付款，客戶會透過通知和電子郵件收到一組代碼，帶著它前往參與門市，向收銀員付款。在此之前，Google 什麼都沒收到，你也一樣。Google 的規則只有一句話：使用 getPurchaseState()，只有在狀態為 PURCHASED 時才發放權益。它還告訴你不要在購買處於 PENDING 時確認它，因為確認屬於已付款的訂單，而不是一個被承諾的訂單。

Apple：這筆購買在等別人點一下

Apple 的待處理狀態意味著這筆交易在完成之前需要一個外部動作。最常見的是 Ask to Buy，孩子發起一筆購買，需要家庭組織者批准。在 StoreKit 2 中，購買呼叫會回傳 Product.PurchaseResult.pending。在較舊的 StoreKit 中，這筆交易被回報為 deferred。無論哪種方式，Apple 都還沒有向任何人扣款，而完成後的交易（如果會來的話）會透過 Transaction.updates 非同步送達。向客戶顯示等待狀態，在已完成的交易到達之前不要解鎖任何東西。

為什麼發放待處理購買會讓你付出真金白銀

這裡的損失不是退款那種，把你已經入帳的錢抽回去。它在一個特定方面更糟：根本沒有錢可抽回，因為從來就沒有收到過。

你交付了，商店卻從未收款

當你在一筆隨後被取消的待處理訂單上解鎖時，你已經為服務它花了錢。執行該功能的運算資源、你付費的第三方 API 呼叫、你配置的儲存空間，以及對消耗型商品來說你所售之物的實際發放。所有這些都隨著一筆沒有產生任何收入的訂單流了出去。退款至少始於一筆真實發生過的收費。而一筆被錯誤發放的待處理購買根本就沒有過收費，所以它甚至不會顯示為流出的錢。它什麼都不顯示，而這正是它容易被忽略、也容易反覆發生的原因。

取消訊號，以及它的含意

當一筆待處理訂單失效時，商店確實會通知你。在 Google Play 上，一款未能成立的一次性商品會發送 ONE_TIME_PRODUCT_CANCELED 通知，類型 2，而一個曾處於待處理的訂閱會發送 SUBSCRIPTION_PENDING_PURCHASE_CANCELED，類型 20。當同樣的訂單反過來成功時，你會收到 ONE_TIME_PRODUCT_PURCHASED，類型 1，或 SUBSCRIPTION_PURCHASED，類型 4。在 Apple 上沒有可以捕捉的取消事件，因為一筆被拒絕的延遲交易根本就不會變成已完成的交易。如果你提前解鎖了，那份沉默就是帳單。

這段等待期，以及誰在等誰

待處理購買不是一個你在與之賽跑的計時器。從你這一側看，它是一個還沒有開始走的計時器。

Google Play 給客戶的是數天，而不是數分鐘

現金或銀行轉帳付款按客戶的節奏結算，而不是你的。訂單會停留在 PENDING，直到客戶付款，或者時限用盡、Google 取消它。你自己的三天確認時限，也就是那個在你未確認購買時會自動退款的時限，要等到購買從 PENDING 轉為 PURCHASED 之後才開始計時。所以沒有必要急著去服務一筆待處理訂單。需要的只是等待狀態改變的那份自律。

Apple 的批准在家庭組織者的手機上

一個 Ask to Buy 請求會作為提示出現在組織者的裝置上，他們會在有空的時候批准或拒絕。那可能是幾分鐘、幾小時，或一天之後，你的應用程式無法催促它。唯一正確的做法是呈現等待狀態，並讓 StoreKit 在批准到來時（如果會到來的話）把已完成的交易交給你。

如何在不造成損失的情況下處理待處理購買

整件事歸結為四個習慣。沒有一個是難事，而漏掉其中任何一個，就是錢流失的地方。

在已付款狀態上發放，絕不在待處理狀態上發放

在 Google Play 上，檢查 getPurchaseState()，只在 PURCHASED 時發放，並且不要在購買處於 PENDING 時確認它。在 Apple 上，只在已完成的交易上解鎖，絕不在待處理結果上解鎖。這一條規則就堵住了整個漏洞。其餘的一切都是為了確保你在已付款狀態到達時真的能注意到。

應用程式回到前景時重新檢查

從待處理到已付款的轉變常常發生在你的應用程式沒有執行的時候。在 Google Play 上，在你的 onResume() 處理常式中呼叫 queryPurchasesAsync()，以擷取在背景變為 PURCHASED 的訂單，並把你的 Real-time Developer Notifications 監聽器作為伺服器端的事實來源。在 Apple 上，在應用程式的整個生命週期內監聽 Transaction.updates，因為一筆獲批的交易可能在原始購買呼叫回傳很久之後才到達。

啟用待處理支援，並測試兩種結局

Google 要求你在建立 BillingClient 時呼叫 enablePendingPurchases()，而且為一次性商品支援待處理交易是強制的，不是可選的。在發布之前測試它。授權測試者會取得兩種額外的延遲付款測試工具，其中付款會在幾分鐘後自動完成或自動取消，這樣你就能端到端地觀察付款路徑和未成立路徑。

告訴客戶訂單還沒完成

一個處於待處理狀態的買家是一位正處在購買中途的真實客戶，不是一次失敗。告訴他們訂單正在等待他們的付款或一次批准，並給他們一條清晰的返回路徑去完成它。一個沉默的待處理狀態會流失那些被清晰標註就能挽回的銷售，因為這些買家中的大多數仍然想要那件東西，只是還差一步。

RefundHalt 為退款和拒付已經在讀取的那些 Real-time Developer Notifications 和 App Store Server Notifications 資料流，同樣攜帶著這些訊號。那條表示一筆待處理訂單終於到帳的已購買通知，以及那條表示它沒有到帳的已取消通知，都會落在你的儀表板裡，與其餘的收入事件並排，這樣一筆未能成立的待處理訂單就成了你看得見的東西，而不是你意外為之買了單的東西。

簡而言之

待處理購買是一筆沒有付款的訂單，兩家商店都明確表示你應該等待。Google Play 把現金、銀行轉帳以及部分電信帳單代收的訂單以 PENDING 狀態回傳，並告訴你只在 PURCHASED 時才發放存取權限。Apple 為 Ask to Buy 和其他必需操作回傳一筆待處理或延遲交易，並在稍後透過 Transaction.updates 送達已完成的交易。在已付款狀態上解鎖，在應用程式恢復時重新檢查，啟用並測試待處理支援，並為客戶標註這筆等待中的訂單。做到這些，待處理購買就不會讓你付出任何代價。跳過它，你就為一筆從未到來的收費交付了一款付費產品，而這是唯一一種拿不出收據來指認的損失。