Monetization design affects every system in your game — economy balance, progression, UI, analytics, and server infrastructure. Here's how to implement in-app purchases, rewarded ads, battle passes, and subscription models correctly.
Neha Gupta
Digital Strategy Lead
Mobile games monetize through four primary models: in-app purchases (IAP) for virtual goods and currency, rewarded ads (user watches an ad for a reward), subscriptions (recurring revenue for premium content), and battle passes/season passes (time-limited progression tracks with free and premium tiers). Most successful mobile games combine multiple models — IAP for whales, rewarded ads for non-spenders, and battle passes for the middle segment.
The monetization model choice should be made during game design, not after launch. A puzzle game designed for energy-based monetization has fundamentally different progression mechanics than one designed for cosmetic IAP. Retrofitting monetization into an existing game design usually produces worse results than designing the game around the monetization model.
Unity's IAP package (Unified IAP) abstracts Apple App Store, Google Play, and other store APIs into a unified interface. The implementation flow: initialize the IAP system with your product catalog, query available products, initiate purchase when the user taps buy, handle the store's purchase flow, and validate the receipt on your server before granting the item.
The critical implementation detail: never grant items before server-side validation. A modified client can fake a successful purchase response. The correct flow: client initiates purchase → store processes payment → client receives receipt → client sends receipt to your server → server validates receipt with the store's validation API → server grants the item in the player's account → client reflects the granted item. This server-authoritative approach prevents receipt forgery.
Rewarded ads are the highest-eCPM ad format (typically $15–40 eCPM vs $1–5 for banners). The user voluntarily watches a 15–30 second video ad in exchange for an in-game reward (extra life, currency, power-up). The implementation: integrate an ad mediation SDK (AppLovin MAX, ironSource, or AdMob) that aggregates multiple ad networks and selects the highest-paying ad for each impression.
The key design principle: rewarded ads should offer genuine value without being necessary. If the game is unplayable without watching ads, retention suffers. If the reward is too valuable, IAP revenue cannibalizes. The balance: rewarded ads should accelerate progression meaningfully but not be the only path. A good rule: a non-spending player who watches 3–5 rewarded ads per day should progress at roughly 50% the rate of a moderate spender.
Battle passes are time-limited (typically 4–8 weeks) progression tracks with free and premium tiers. Players earn XP through gameplay, unlock free rewards at every tier, and unlock premium rewards at tiers they've reached if they purchased the pass. The design challenge: the pass must feel achievable for engaged players but not so easy that it's purchased once and forgotten.
The implementation requires a server-side progression system: track player XP, calculate tier unlocks, and manage reward claims. The server must be authoritative — a client-side battle pass can be hacked to claim all rewards without playing. We implement battle pass logic in cloud functions (AWS Lambda or Google Cloud Functions) with a DynamoDB or Firestore backend for progression state.
Virtual economy design is the intersection of game design and economics. The core loop: players earn currency through gameplay (source), spend currency on items/progression (sink), and optionally purchase currency with real money (monetization). The balance between sources and sinks determines whether the economy inflates (too much currency, items feel worthless) or deflates (too little currency, progression feels impossible).
Model the economy before implementing it. Create a spreadsheet tracking all currency sources and sinks per day of player engagement. Simulate 30, 60, and 90-day player journeys. Adjust the balance until the economy feels right — players should always have enough currency to make meaningful choices but never enough to buy everything without engagement.
All purchase validation must happen server-side. For iOS, send the receipt to Apple's verification endpoint (or use App Store Server API v2 for server-to-server notifications). For Google Play, use the Google Play Developer API to verify purchases. For Unity IAP, the receipt contains the store-specific data needed for validation.
Implement replay attack prevention: each receipt should only be processed once. Store processed transaction IDs server-side and reject duplicates. For consumable purchases (currency, items), the server grants the item only after successful validation. For non-consumable purchases (permanent unlocks), the server tracks ownership and restores purchases when the player reinstalls. This server-authoritative validation is standard practice across every title our Unity 3D development team ships, and it's the first thing our casual game development practice audits when taking over an existing live-ops title.
Tags
Continue Reading
The game engine choice shapes your entire development process. Unity dominates mobile and indie; Unreal dominates AAA and photorealistic rendering. But the lines are blurring. Here's an honest comparison for 2025.
A practical guide to building AI agents that actually work outside of demos — covering tool selection, memory, error recovery, and deployment patterns we've validated in production.
Two approaches, very different trade-offs. RAG is faster, cheaper, and keeps your data current. Fine-tuning gives you style and behaviour control. Here's when each wins — and when to use both.
From AI agents to mobile apps — iMOBDEV builds what your business needs.
