Build a game

Purchase flow testing hub

Test every purchase state—not only the happy path

A credible IAP prototype covers the complete state machine: inspection, consent, failure, delivery, persistence, and recovery.

See the worked examplePlay the reference game
Authentic Block Matrix gameplay used as context for purchase flow testing testing
Real gameplay context: Block MatrixUse the playable result to evaluate placement and UI state—not as proof of a completed transaction.

Concrete design brief

Worked example: recover an interrupted 60 Koin unlock

Record a purchase attempt ID before confirmation. If the session closes after payment but before the success screen, reconcile the result on reload and unlock once—never deliver twice and never ask the player to repurchase.

Open the playable result →

Required state chain

Specify the whole IAP flow

  1. 01

    Preview the exact item or content

  2. 02

    Show the exact Koin price

  3. 03

    Branch to Confirm or Cancel

  4. 04

    Handle insufficient balance and retry

  5. 05

    Acknowledge success and deliver once

  6. 06

    Reload, reconcile, and restore ownership

Before release: replace mocked balances and local flags with authenticated transaction records, idempotent delivery, platform-required consent, security review, and a support/refund process.

Related IAP design hubs

Move to the closest purchase intent

Cosmetic IAP Content unlock Consumable IAP Convenience IAP Player trust

Focused questions

Purchase flow testing FAQ

Which failure state is easiest to miss?

An acknowledged purchase whose delivery response is interrupted. Reconciliation must restore the entitlement without creating a duplicate.

Is a front-end prototype enough for production billing?

No. It can validate interface and state logic, but production commerce also needs authenticated server records, platform compliance, security review, and support procedures.