Don't acknowledge a Google Play purchase within three days and Google refunds it, here's what that costs you

A customer buys your product, the charge clears, and three days later Google Play quietly refunds it and pulls back what you delivered. Nobody asked for that refund. The customer did not request it, and no support agent granted it. It fired because your server never told Google the purchase was handled. If you do not acknowledge a Google Play purchase within three days, Google refunds the buyer and revokes the purchase, every time. It is one of the few refunds on either store that is entirely your integration to prevent, and one of the quietest ways to leak revenue.

This is not a fraud problem or a policy dispute. It is a missed callback. The fix is small and the cost of skipping it is real money, so it is worth knowing the rule exactly, why purchases slip through unacknowledged, and what each lost sale actually takes with it.

What the three-day rule actually says

Google's Play Billing documentation is blunt about it. After your app grants entitlement and tells the user the purchase succeeded, it has to notify Google that the purchase was processed. In Google's words, this "must be done within three days so that the purchase isn't automatically refunded and entitlement revoked." The one-time product page repeats it with no softening: "If you don't acknowledge a purchase within three days, the user automatically receives a refund, and Google Play revokes the purchase." Subscriptions carry the identical rule for the initial purchase.

Acknowledgement is a signal, not a formality. It tells Google that entitlement reached the user. Google treats the absence of that signal as a delivery that never happened, and it unwinds the transaction on the customer's behalf. From the buyer's side it looks like a free refund they never asked for. From your side it looks like a sale that evaporated.

The clock starts at PURCHASED, not at checkout

The three-day window does not begin when the user taps buy. It begins when the purchase state transitions to PURCHASED. A purchase can sit in PENDING first, which happens with cash payments, slow bank transfers, or a parent approving a child's request. Google is explicit: "The three-day acknowledgement window begins only when the purchase state transitions from PENDING to PURCHASED."

That has two consequences. Grant entitlement only when the state is PURCHASED, never on PENDING, or you hand out product for a payment that may never complete. And do not acknowledge a PENDING purchase either. You call enablePendingPurchases() when you build the BillingClient, wait for the transition, and only then start the acknowledgement clock in your head.

Acknowledge or consume, and which one you owe

There are two ways to satisfy the requirement, and which one you use depends on the product. Both clear the three-day deadline. The difference is what else they do.

For a consumable, you consume it. On a secure backend that is purchases.products.consume, or client-side consumeAsync() in the Play Billing Library. Consuming both acknowledges the purchase and makes the product buyable again, which is exactly what you want for coins, credits, or a one-shot generation. For a non-consumable or a subscription, you acknowledge it: purchases.products.acknowledge or purchases.subscriptions.acknowledge on the backend, or acknowledgePurchase() client-side. Acknowledging clears the deadline without freeing the product for repurchase.

Renewals are already handled, initial purchases are not

You only owe acknowledgement on the first purchase of a subscription. Google states plainly that "you don't need to acknowledge subscription renewals," and it stamps renewals ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED on its own. A new purchase arrives as ACKNOWLEDGEMENT_STATE_PENDING and stays your responsibility until you clear it. Before you acknowledge, check acknowledgementState on the backend or isAcknowledged() client-side so you do not double-acknowledge.

Prepaid plans get a shorter fuse

Prepaid subscription plans tighten the window. Google's rule: prepaid plans lasting one week or longer must be acknowledged within three days, but "prepaid plans with a duration shorter than one week must be acknowledged within half of the plan duration." A three-day prepaid plan gives you a day and a half, not three days. If you sell short prepaid top-ups, your acknowledgement path has to be fast and server-driven, not dependent on the user reopening the app.

Why purchases go unacknowledged in the first place

Nobody sets out to skip acknowledgement. It slips because the code that acknowledges lives in the wrong place. The common anti-pattern is a client that acknowledges only when the purchase flow returns in the foreground. That works for a user who finishes buying and keeps using the app. It fails everyone else.

Developers hit this constantly. Threads in Google's own developer community read the same way every time, some variant of "a user automatically got refunded after buying from my app after three days" and "why are payments automatically refunded after three days." The answer is almost always the same: the acknowledgement call never fired because the app was never in a state to fire it.

The free trial and the user who never comes back

The worst version is the free trial or a purchase right before the user closes the app for good. If your acknowledgement depends on the next app open, and there is no next app open, the purchase ages out. On day three Google refunds and revokes it. For a trial that would have converted to a paid subscription, you lose the first billing you never got to collect, plus a customer entitlement that silently disappeared. Neither event shows up as a support ticket. It shows up as a voided purchase you have to go looking for.

What an unacknowledged refund actually costs

The refund line understates the loss. When Google reverses the sale, you give back the price, and that is the visible number. It is not the whole bill.

Think about a consumable that triggers real work the moment it is bought. A batch of image generations, a run of calls to a model provider's API, a video export, a payout to a creator. You paid for that compute, those API calls, that storage, and those payouts at the time of use. The refund returns the sale price to the customer. It does not return the provider invoice to you. You delivered a real cost and got nothing back for it.

For subscriptions and trials, the loss is the first billing you never collect and the customer relationship that ended before it started. And starting August 3, 2026, Google Play shifts chargeback purchase price and bank fees onto developers for orders placed after that date, which makes any avoidable revenue leak worth closing now rather than later. An unacknowledged refund is not a chargeback, but it is the same lesson: money you already spent is not automatically money you keep.

How to acknowledge a Google Play purchase server-side

The reliable pattern removes the app from the critical path. Do it on your backend, driven by notifications, not by the user reopening the screen.

• Listen for Real-time developer notifications. A ONE_TIME_PRODUCT purchase or a SUBSCRIPTION_PURCHASED event tells your server a purchase exists the instant Google knows, whether or not the app is open.
• Verify the purchase token against the Play Developer API and confirm the state is PURCHASED, not PENDING.
• Grant entitlement in your own records, keyed to the user.
• Acknowledge or consume immediately. Consume consumables, acknowledge non-consumables and initial subscriptions. Check acknowledgementState first so you never acknowledge twice.
• Backfill on the client too. Call queryPurchasesAsync() in onResume() so any purchase that completed while the app was closed still gets processed. This is a safety net, not the primary path.

The point is that acknowledgement fires from an event Google sends you, not from a user action you cannot count on. A user who buys and never returns is fully covered because your server acted the moment the purchase landed.

A reconciliation net for the ones that slip

Even a clean pipeline benefits from a check. The Voided Purchases API lists purchases that were refunded, revoked, or charged back, and it names the case where the reason is that the purchase "was never acknowledged by the developer, and therefore may not exist in the developer's records." Poll it and you can revoke entitlement you granted for anything Google has already unwound. Note the limit: the API only returns voided purchases from the past 30 days, so reconciliation has to run on a schedule, not once a quarter.

Apple has no equivalent, and that matters

This is a Google Play problem specifically. Apple's StoreKit has a finishing step too, finishing a transaction, but it does the opposite thing on failure. If you never finish a StoreKit transaction, Apple keeps it in the queue and redelivers it every time your app launches or the observer attaches, so you get another chance to grant entitlement. Apple does not refund an unfinished transaction. There is no three-day auto-refund on the App Store.

So the mental model has to stay platform-specific. On Google Play, an unhandled purchase is a refund waiting to happen and a deadline you are racing. On the App Store, an unhandled purchase is a redelivery waiting to happen and no clock at all. Porting the Apple assumption to Android is how teams end up with a wall of unacknowledged refunds they cannot explain.

This is why RefundHalt acknowledges Google Play purchases automatically the moment the store notification arrives, and reconciles against the Voided Purchases API so an entitlement granted for a purchase Google later unwound does not stay live. The three-day rule stops being a race you can lose and becomes a step that already happened.