What causes an Android consumable purchased but not granted?

You never acknowledged or consumed the purchase server-side, so the entitlement was granted on a fragile client callback that was lost before the item was awarded.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix an Android Consumable Purchased but Never Granted in Your Game

Quick answer: Grant the item from a verified purchase token, then call consumeAsync only after your backend confirms and records the grant, so a lost callback can be replayed.

A player pays for 500 gems and gets nothing. The charge went through Google Play, but your code awarded the gems inside the purchase callback and that callback never fired again after a crash. Verifying and consuming on a durable path fixes it.

How to fix it

1. Verify the token on your server

Send the purchaseToken to your backend and call the Google Play Developer API purchases.products.get to confirm purchaseState == 0 (purchased) before granting anything. Never trust the client-side product result alone.

2. Grant before you consume

Record the grant in your database keyed by the purchase token, award the currency, and only then call consumeAsync. Consuming first means a failure after consume leaves the player charged with no item and no way to replay.

3. Replay unconsumed purchases on launch

On every startup, query queryPurchasesAsync for owned products and re-process any consumable that was never acknowledged. This recovers purchases interrupted by a crash or network drop.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every mobile error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

The bug you can't reproduce isn't gone — it's just invisible until you capture it from the player's device.