A pending purchase looks like a sale, but the money hasn't arrived, and granting it early gives the product away

Someone taps buy in your app. Your logs show a new order, your billing listener fires, and you hand over the goods. On most purchases that is exactly right. On a pending purchase it is a mistake, because the order exists but the money does not. The customer picked a payment method that settles later, the store is still waiting to be paid, and you just delivered a paid feature for a charge that may never clear. This is the quiet cousin of a refund. Nothing gets reversed here, because nothing was ever collected. You simply gave the product away.

A pending purchase is a real order in a not-yet-paid state, and both the App Store and Google Play have one. Both stores tell you plainly to wait. The trap is that a pending order looks almost identical to a completed one in your code, so an integration that treats every new purchase as a sale ships goods on orders the store is still trying to collect. Handle it correctly and you lose nothing. Handle it wrong and every slow payment that falls through is pure cost, delivered on your dime.

What a pending purchase actually is

A pending purchase is an order the store has recorded but not yet charged. The buyer started the flow, the store accepted it, and settlement is happening somewhere your app cannot see. Google Play calls this the PENDING state. Apple calls it a pending, or deferred, transaction. Different names, same fact: the store is holding an order open while it waits to be paid, and it has told you not to treat that order as money.

Google Play: the payment is happening somewhere else

Some payment methods settle out of band. Cash at a physical store, bank transfers, and some carrier billing all take extra steps between the tap and the charge. When a customer picks one, Google returns the purchase in the PENDING state instead of PURCHASED. For a cash payment the customer receives a code by notification and by email, carries it to a participating store, and pays the cashier. Until that happens, Google has collected nothing, and neither have you. Google's rule is one line: use getPurchaseState() and grant entitlement only when the state is PURCHASED. It also tells you not to acknowledge a purchase while it is PENDING, because acknowledgement belongs to a paid order, not a promised one.

Apple: the purchase is waiting on someone else's tap

Apple's pending state means the transaction needs an external action before it can complete. The most common one is Ask to Buy, where a child starts a purchase and a family organizer has to approve it. In StoreKit 2 the purchase call returns Product.PurchaseResult.pending. In the older StoreKit the transaction is reported as deferred. Either way, Apple has not charged anyone, and the finished transaction, if it comes, arrives asynchronously through Transaction.updates. Show the customer a waiting state and unlock nothing until the completed transaction lands.

Why granting a pending purchase costs you real money

The loss here is not the refund kind, where money you booked gets pulled back. It is worse in one specific way: there is no money to pull back, because none was ever collected.

You deliver, and the store never collects

When you unlock on a pending order that later cancels, you have already spent to serve it. The compute that ran the feature, the third-party API calls you paid for, the storage you allocated, and for a consumable the actual payout of the thing you sold. All of that goes out the door on an order that produced no revenue. A refund at least starts from a charge that happened. A wrongly granted pending purchase never had a charge at all, so it does not even show up as money going out. It shows up as nothing, which is exactly why it is easy to miss and easy to repeat.

The cancel signal, and what it means

The store does tell you when a pending order dies. On Google Play, a one-time product that falls through sends a ONE_TIME_PRODUCT_CANCELED notification, type 2, and a subscription that was pending sends SUBSCRIPTION_PENDING_PURCHASE_CANCELED, type 20. When the same orders instead go through, you get ONE_TIME_PRODUCT_PURCHASED, type 1, or SUBSCRIPTION_PURCHASED, type 4. On Apple there is no cancel event to catch, because a deferred transaction that gets declined simply never becomes a completed transaction. If you unlocked early, that silence is the bill.

The window, and who is waiting on whom

A pending purchase is not a clock you are racing. It is a clock that, from your side, has not started.

Google Play gives the customer days, not minutes

A cash or bank-transfer payment settles on the customer's schedule, not yours. The order sits in PENDING until the customer pays or the window runs out and Google cancels it. Your own three-day acknowledgement window, the one that auto-refunds a purchase you fail to acknowledge, does not even begin until the purchase transitions from PENDING to PURCHASED. So there is no rush to serve a pending order. There is only the discipline to wait for the state to change.

Apple's approval is on the family organizer's phone

An Ask to Buy request lands on the organizer's device as a prompt they approve or decline whenever they get to it. That can be minutes, hours, or a day later, and your app cannot hurry it. The only correct behavior is to reflect the waiting state and let StoreKit hand you the completed transaction if and when the approval comes.

How to handle pending purchases without leaking

The whole job comes down to four habits. None of them is hard, and skipping any one of them is where the money goes.

Grant on the paid state, never on the pending one

On Google Play, check getPurchaseState() and grant only on PURCHASED, and do not acknowledge a purchase while it is PENDING. On Apple, unlock only on a completed transaction and never on the pending result. This single rule closes off the entire leak. Everything else is about making sure you actually notice when the paid state arrives.

Re-check when the app comes back

The transition from pending to paid often happens while your app is not running. On Google Play, call queryPurchasesAsync() in your onResume() handler to pick up orders that became PURCHASED in the background, and keep your Real-time Developer Notifications listener as the server-side source of truth. On Apple, listen to Transaction.updates for the whole life of the app, because an approved transaction can arrive long after the original purchase call returned.

Enable pending support and test both endings

Google requires you to call enablePendingPurchases() when you build the BillingClient, and supporting pending transactions for one-time products is mandatory, not optional. Test it before you ship. License testers get two extra test instruments for delayed forms of payment, where the payment automatically completes or automatically cancels after a couple of minutes, so you can watch both the pay path and the fall-through path end to end.

Tell the customer the order is not done

A pending buyer is a real customer in the middle of a purchase, not a failure. Show them the order is waiting on their payment or on an approval, and give them a clear way back to finish it. A silent pending state loses sales that a well-labeled one recovers, because most of these buyers still want the thing and just have one step left.

The same Real-time Developer Notifications and App Store Server Notifications feeds RefundHalt already reads for refunds and chargebacks carry these signals too. The purchased notification that says a pending order finally cleared, and the canceled notification that says it did not, land in your dashboard next to the rest of your revenue events, so a pending order that fell through is something you can see instead of something you paid for by accident.

The short version

A pending purchase is an order without a payment, and both stores are explicit that you should wait. Google Play returns cash, bank-transfer, and some carrier-billing orders in a PENDING state and tells you to grant access only on PURCHASED. Apple returns a pending or deferred transaction for Ask to Buy and other required actions and delivers the completed transaction later through Transaction.updates. Unlock on the paid state, re-check when your app resumes, enable and test pending support, and label the waiting order for the customer. Do that and a pending purchase costs you nothing. Skip it and you deliver a paid product for a charge that never came, which is the one loss with no receipt to point at.