How to Fix a Double Charge From Rapid Repeated Buy-Button Taps

A tap that triggers an async balance check and grant has a window where a second tap can slip in and double-charge the player. Guarding the transaction against re-entrancy closes that window. Here is how.

How to fix it

1. Lock the UI immediately

On the first tap, synchronously disable the buy button and show a pending state before any await, so the player cannot fire a second request.

2. Guard with an in-flight flag

Keep a boolean or a set of in-flight item ids; reject a purchase whose item is already being processed rather than entering the async path again.

3. Make the grant idempotent

Tag each purchase attempt with a unique transaction id and have the server (or save layer) ignore a repeated id, so even a duplicate that gets through cannot charge twice.

4. Re-enable in finally

Clear the in-flight flag and re-enable the button in a finally block so a failed or cancelled purchase does not leave the shop permanently locked.

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 HTML5 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.