In-Game Monetization Development
Monetization is part of game mechanics, not an overlay. When a purchase system is added late in development, it either breaks game balance or feels foreign to the player. Both lead to poor reviews and low ARPU.
Monetization types and technical implementation
IAP (In-App Purchases)
The primary tool for mobile games. On Unity implemented via Unity IAP package — unified API for Google Play Billing and Apple StoreKit. Basic integration is straightforward, but has nuances:
Receipt validation. Checking receipt on the client is useless — any rooted Android allows generating a fake receipt. Server-side validation is mandatory: client sends receipt to backend, backend validates via Google Play Developer API or Apple App Store Server API, then credits currency. Without this, any cheater gets free currency in 5 minutes.
Consumable vs. Non-consumable vs. Subscription. Consumables (crystals, coins) require transaction confirmation after crediting: controller.ConfirmPendingPurchase(product). If not called — Google/Apple will reverse the purchase on next launch. Non-consumables (content unlocks) must be restored via RestorePurchases() — this is App Store requirement.
Offline resilience. Purchase can start with good connection and complete with poor. We store transaction state locally (PlayerPrefs or SQLite), handle pending purchases on next launch.
Game currency and economy
Dual currency (soft + hard) is standard for midcore games. Technical implementation:
- Backend as source of truth. Currency balance is stored on server, client only displays. Local cache for UI responsiveness, but always syncs with server. PlayFab Virtual Currency — ready-made solution with transactional guarantees and operation history.
- Race condition protection. Parallel requests to deduct currency (simultaneous purchase button clicks) must be handled atomically. PlayFab CloudScript executes sequentially per user — this solves the issue. Custom backend requires database transactions.
- Audit trail. Every balance change — logged with reason, amount, timestamp. Without this, impossible to investigate player complaints and detect anomalies.
Ad Monetization
For hyper-casual and casual games — primary revenue source. Stack:
- UnityAds — simplest integration for Unity projects.
- IronSource / AppLovin MAX — mediation platforms let multiple ad networks compete for impressions. Rates 20-40% higher vs. single network.
- Rewarded Video requires correct gameplay integration: show ads only at organic points (Game Over, before bonus level), not forcefully.
Interstitial between levels — use counter, not after every level. Frequency determined by A/B testing via Firebase Remote Config or PlayFab Experiments.
LiveOps and events
Timed events, battle pass, seasonal content — separate infrastructure. Event config lives on server, client downloads on startup. PlayFab Title Data or custom CMS. Critical: client shouldn't hardcode event dates — guaranteed bug when schedule changes.
Battle Pass technically: track progress in PlayFab Statistics, milestone rewards via PlayFab CloudScript, display via Addressable bundles with reward icons (to avoid bloating base build).
Why monetization can't be added late
Real case: mobile match-3, progression balance designed for fun, not monetization. During IAP integration we found players complete all content in 4 hours without single purchase. Had to rework difficulty curve and add energy system — required reworking 60% of gameplay systems.
Monetization model must be part of GDD from day one. This determines: progression curve, currency structure, conversion points, resource value.
Work process
Audit or design (3-5 days). Analyze genre and competitors, choose monetization model, design economy (sink/source resource balance).
Backend infrastructure (1-2 weeks). PlayFab or custom backend setup: currencies, item catalog, CloudScript for transactions, server receipt validation.
Client integration (1-2 weeks). Unity IAP, shop UI, gameplay integration, edge case handling (no network, failed purchase, restore).
Analytics (3-5 days). Configure conversion funnels in Firebase/Amplitude: shop view → purchase initiation → successful purchase. Track retention by monetization segments.
QA. Sandbox IAP testing on Google and Apple test accounts. Check all edge cases: purchase cancellation, failed payment, purchase restoration.
| Integration Type | Timeline |
|---|---|
| Basic IAP (1-3 products) | 1 week |
| IAP + ads + analytics | 2-3 weeks |
| Full economy + battle pass | 1-2 months |
| LiveOps infrastructure | 2-4 weeks (depends on stack) |
Cost is calculated after analyzing requirements and chosen stack.