game-iaplisted

# Game IAP Purchases are the part of a game most likely to lose real money to a bug, and the part least covered by tests because the store is remote and asynchronous. This skill gives the architecture that makes IAP testable, the platform APIs, and the policy rules that cause rejection. ## Decide first Answer these three before writing code. They determine everything else. | Question | Consequence | |---|---| | **Consumable, non-consumable, or subscription?** | Non-consumable (level pack, remove-ads) → entitlement, must survive reinstall via restore. Consumable (gem pack) → must be *consumed* after granting or the user can never rebuy. Subscription → renewal state, grace periods, a server is effectively mandatory. | | **Does the game have a server?** | No server → entitlements live in local save and the store is the only source of truth. Yes → validate receipts server-side and keep entitlement server-side; the client becomes a cache. | | **Must purchased content work offline?** | Yes → you must cache entitlements locally and define what happens when the store is unreachable (see [Offline and refunds](#offline-and-refunds)). This is the single most common source of angry reviews. | **Never gate content on a network call at launch.** A player who paid and boarded a plane must still have their content. ## Core architecture One interface, three implementations. This is the whole trick — it makes IAP unit-testable without a store, and it is what lets you ship a desktop or w