In-App Purchase Implementation Guide for Mobile Games

The short answer

Implement purchases as a flow with a server in the middle: fetch products from the store, start the purchase, validate the resulting transaction on your server, grant the item, then tell the store the transaction is complete. Handle interrupted, pending and refunded purchases, offer restore for permanent items, and test with the stores' sandbox tools. Skipping server validation is the most expensive shortcut in mobile games.

Product types

Type	Examples	Behaviour
Consumable	Coins, gems, lives, boosters	Bought repeatedly, used up
Non-consumable	Remove ads, unlock a character, premium upgrade	Bought once, owned permanently, must be restorable
Auto-renewing subscription	VIP membership, monthly pass	Renews until cancelled, has states such as grace period
Non-renewing or prepaid	Season pass for a fixed period	Expires, does not renew automatically

Apple and Google use slightly different names, but the categories match. Decide the type carefully, because it determines restore behaviour and how the stores treat refunds.

The purchase flow

Configure products in App Store Connect and the Play Console with identifiers and price tiers.
Fetch products at runtime. Always show the price string the store returns, which is localised with the right currency and tax. Never hard-code prices.
Start the purchase when the player taps buy. The store shows its own payment sheet.
Receive the transaction. It may succeed, fail, be cancelled or be pending.
Validate on your server. Send the transaction data to your backend, which checks it with the store's server API.
Grant the item in the player's server-side inventory.
Finish the transaction. On iOS, finish it. On Android, consume or acknowledge it. Google refunds purchases that are not acknowledged within three days.
Confirm to the player with a clear success state.

Do steps six and seven in that order. If you finish first and the grant fails, the player has paid for nothing.

Why server validation matters

Without it, a modified app or a fake receipt can tell your game that a purchase happened. With it, your server asks the store directly whether the transaction is real, whether it has been used before and whether it belongs to this product. Combine it with:

A server-held inventory, so currency is not just a number on the phone.
A record of processed transaction identifiers to block replay.
Store server notifications, which tell your backend about refunds, renewals and cancellations as they happen.

A small managed backend is enough. See Firebase vs PlayFab vs custom backend. Even single-player games benefit from validating purchases of high-value items.

States you must handle

Situation	What to do
App closed during purchase	On next launch, read unfinished transactions and complete the grant
Pending payment	Show a pending state and grant only when the store confirms
Ask to Buy or family approval	Wait for the deferred transaction to resolve
Network loss after payment	Retry validation, never lose the transaction
Refund or chargeback	Receive the notification and decide whether to remove the item
Subscription expiry or billing retry	Follow store status, including grace periods
Reinstall or new device	Restore non-consumables and subscriptions

Most support tickets about purchases come from the first four rows.

Restore purchases

Apple requires a way to restore non-consumable purchases and subscriptions. Add a visible restore button in the shop or settings. On Android, query existing purchases at launch. For consumables, the only reliable protection is an account system with server-held balances, so progress survives a new phone. See cross-play and cross-progression.

Engine tools

Unity's In-App Purchasing package wraps StoreKit and Google Play Billing behind one interface, which saves duplicate work, and Unreal has equivalent online subsystem support. Cross-platform subscription services add dashboards, validation and analytics. Wrappers do not remove the need to understand the flow, especially for pending and restored transactions. Keep the store libraries current, because the stores retire old billing versions on a schedule, a routine item in game maintenance cost.

Store rules to know

Digital goods used inside the app must generally use the store's purchase system, with exceptions that vary by region and are changing. See Google Play fees in 2026.
Prices and what the player receives must be clear before purchase.
Randomized items must disclose odds.
Apps for children have stricter rules, including purchase gates. See rules for kids games.
Subscriptions need clear terms, renewal information and an easy path to manage or cancel.

Rejections for purchase problems are common, as listed in our submission checklist.

Shop design that respects players

Show value clearly: quantity, bonus and price.
Offer a low-priced first purchase.
Avoid confusing layered currencies.
Never interrupt play with a purchase prompt at a moment of frustration that the game itself engineered.
Confirm large purchases.

Long-term revenue comes from players who trust the shop. The underlying structure is covered in game economy design and battle pass design.

Testing

Sandbox and test accounts. Apple provides sandbox testers and local StoreKit testing. Google provides licence testers and test tracks.
Every product on both platforms.
Interruptions. Kill the app mid-purchase, turn off the network, switch accounts.
Pending and declined payments.
Restore on a clean install.
Refund handling through server notifications.
Subscriptions through renewal, expiry and grace periods using accelerated test timings.
Localisation. Check price display in several regions.

Budget real time for this. Purchase bugs cost money directly and generate angry reviews. See game QA and testing cost.

Analytics

Track shop opened, product viewed, purchase started, purchase completed and purchase failed with reason. The drop between each step shows where revenue is being lost. See game analytics events to track and mobile game KPIs.