In-Game Monetization and Game Economy Development: IAP, Ads, Battle Pass

We develop in-game monetization systems with a focus on balance and user experience. For over 8 years, we have integrated IAP, ads, and subscriptions for games of various genres—from hyper-casual to midcore RPG. Our team has implemented monetization in 40+ projects using proven stacks: Unity IAP, PlayFab, AppLovin MAX. When monetization is added at the end of development, it either breaks game balance or feels tacked on—leading to lower ARPU and ratings. Contact us for an audit or monetization model design.

How IAP Works in Unity and Unreal

The primary tool for mobile games is IAP (In-App Purchases). In Unity, it's implemented via the Unity IAP package—a unified API for Google Play Billing and Apple StoreKit. Basic integration is straightforward, but there are nuances.

Receipt validation. Client-side receipt validation is useless—any rooted Android device can generate a fake receipt. Server-side validation is mandatory: the client sends the receipt to the backend, the backend verifies it via Google Play Developer API or Apple App Store Server API, then grants the currency. Without this, any cheater can get free currency in 5 minutes. Apple App Store Server API docs recommend this approach.

Consumable vs. Non-consumable vs. Subscription. Consumables (crystals, coins) require transaction confirmation after granting: controller.ConfirmPendingPurchase(product). If not called, Google/Apple will return the purchase on next launch. Non-consumables (content unlocks) must be restored via RestorePurchases()—an App Store requirement.

Offline resilience. A purchase may start with a good connection and finish with a poor one. We store transaction state locally (PlayerPrefs or SQLite) and handle pending purchases on next launch. This reduces lost transactions by 10x compared to ignoring PlayFab documentation.

Game Currency and Economy

Dual currency (soft + hard) is the standard for midcore games. Technical implementation:

• Backend as source of truth. Currency balance stored on server, client only displays. Local cache for UI responsiveness, but always synchronized with server. PlayFab Virtual Currency is a ready-made solution with transaction logging and history.
• Race condition protection. Parallel spend requests (simultaneous button taps) must be processed atomically. PlayFab CloudScript executes in a single thread per user—solving the problem. Custom backend requires database transactions.
• Transaction audit. Every balance change is logged with reason, amount, timestamp. Without this, investigating player complaints and detecting anomalies is impossible.

Ad Monetization

For hyper-casual and casual games, ads are the primary revenue source. Stack:

• UnityAds—simplest integration for Unity projects.
• IronSource / AppLovin MAX—mediation platforms that allow multiple ad networks to compete for impressions. Rates are 20-40% higher compared to a single network.
• Rewarded video requires correct integration with gameplay: show ads only in organic points (Game Over, before bonus level), never forced.

Interstitial between levels: we use a counter, not after every level. Frequency is determined by A/B testing via Firebase Remote Config or PlayFab Experiments.

LiveOps and Events

Temporary events, battle pass, seasonal content—a separate infrastructure. Event configuration lives on the server; client downloads on launch. PlayFab Title Data or custom CMS. Important: client should never hardcode event dates—that's a guaranteed bug when schedule changes.

Battle pass technically: track progress in PlayFab Statistics, milestone rewards via PlayFab CloudScript, display progress via Addressable bundles with reward icons (to avoid bloating base build).

Why Monetization Should Not Be Added at the End

Real case: a mobile match-3 game, progression balanced purely for fun, without monetization. During IAP integration, it turned out players complete all content in 4 hours without a single purchase. We had to rework the difficulty curve and add an energy system—requiring a 60% rework of gameplay systems.

Monetization model must be part of GDD from day one. It determines: progression curve, currency structure, conversion points, and value of each resource.

What's Included

• Monetization model audit—analysis of current economy, conversion points, competitors.
• Economy design—sink/source balance, dual currency, item value.
• IAP integration—Unity IAP, server-side validation, edge case handling.
• Ad setup—UnityAds, IronSource/MAX, rewarded video, interstitial.
• Battle Pass & LiveOps—event configuration, progress tracker, rewards.
• Monetization analytics—conversion funnels, Firebase/Amplitude setup.
• Documentation and training—tool transfer, process description.
• Post-launch support—monitoring, A/B tests, refinements.

Process

1. Analysis and design (3-5 days). Analyze genre and competitors, choose monetization model, design economy (sink/source resource balance).
2. Backend infrastructure (1-2 weeks). Set up PlayFab or custom backend: currencies, catalog, CloudScript for transactions, server-side receipt validation.
3. Client integration (1-2 weeks). Unity IAP, shop UI, gameplay integration, edge cases (no network, failed purchase, restore).
4. Analytics (3-5 days). Set up conversion funnels in Firebase/Amplitude: shop view → purchase initiation → successful purchase. Track retention by monetization segments.
5. QA and sandbox. Sandbox test IAP on test accounts for Google and Apple. Test all edge cases: cancel purchase, failed payment, restore purchases.

Cost is calculated after requirements analysis and chosen stack. Contact us for an assessment and optimal solution.

What makes our game design services comprehensive?

Before discussing game design, let's clarify: game design is not about "coming up with an idea." Anyone can do that. The task is to design a system of rules that produces a specific emotional and behavioral outcome. It is an engineering discipline, but instead of a compiler, the human brain.

The first pain point: you feel the controls are "clunky" but can't pinpoint why. Often, the problem isn't the code but the absence of coyote time and jump buffering. Or linear acceleration that doesn't convey weight. We fix this at the prototype stage — and guarantee your players won't feel the stickiness.

Get in touch for a free project evaluation – we'll identify control issues in your current build within one day.

Game design services: from GDD to polished build

We deliver turnkey game design services: concept, documentation, balance tables, prototype of key mechanics in Unity/Unreal, and post-release support. Over a decade of experience and 50+ shipped titles across mobile, PC, and consoles.

Deliverables included:

• Game Design Document (GDD) with mechanic specs, narrative trees, and API references for developers
• Balance tables: progression curves, economy flows, DPS calculators (Google Sheets with formulas and pivot tables)
• Interactive prototype scenes covering core loop — movement, combat, inventory, or any custom mechanic
• Engine configuration: ScriptableObject data assets, animation events, state machine blueprints
• Playtest reports with metrics (retention, monetization) and iteration roadmap

Guarantee: every deliverable is reviewed by a senior engineer with 15+ years of experience. No template work — each solution is custom-fit to your genre and platform.

How do our game design services improve combat system tuning?

The combat system is the most expensive mistake: seemingly simple, but in reality, a nightmare of edge cases. Let's break down melee combat.

Choosing a hit detection method

Hitbox — colliders on weapons. Simple, but with fast attacks, tunneling occurs: the weapon passes through the enemy in one frame. Continuous Collision Detection (Physics.CCD) fixes this but costs CPU. Raycast/spherecast — cast rays along the weapon's trajectory. More accurate, less framerate-dependent. For action games spherecast is 3x faster than hitbox in high-speed scenarios because it doesn't miss thin targets.

Setting up attack windows

Each attack has three phases: startup, active, recovery. Long startup creates "heavy" hits. Short recovery gives an aggressive style. In Unity, the animator fires an event via AnimationEvent, code enables/disables the hitbox. Typical timings for melee combat: startup 200–400 ms, active 100–150 ms, recovery 300–500 ms. Tuning these windows reduces feel complaints by 60% in playtests.

Building the state machine

The character is a finite state machine. Basic states: Idle, Moving, Jumping, Attacking, Hurt, Dead. Business logic in C#, animator handles only transitions. Hierarchical state machines via Override Animator Controller allow nested substates without duplicating transitions.

Why is a mathematical economic model critical?

Economies designed "by eye" fail within a month of release — we've seen projects lose $50k in rework. Basic progression: linear (boring), exponential (XP(n) = base * multiplier^n, multiplier 1.5–2.0), polynomial (a * n^b, b 1.5–2.5). We build balance tables in Google Sheets in 2–3 days, verifying how many hours a player will spend on each level. Imbalance surfaces via DPS and TTK: if a weapon's TTK is half that of others, it becomes meta. Our prototype catches 80% of balance issues before full production, saving 2–3 weeks of later fixes.

Currency flows

Each currency must have a clear source (tap) and sink. Example of a two-currency system:

One-way conversion protects monetization. We detect imbalance early using a simple rule: if a single item dominates 40%+ of spending, the sink is broken. This approach reduces post-launch balancing costs by up to $15k.

How does environmental storytelling work in game design?

Environmental storytelling — placement of objects, sounds, traces — is often more effective than dialogue. For dialogue we use Ink (integration with Unity). Ink scripts are editable by a narrative designer without a programmer. Each level is validated by the principle: the player must understand the mechanic through action, not a hint. This approach improves first-time clarity by 30% in our playtests.

Our tech stack for game design

According to Wikipedia: Game design is the art of applying design and aesthetics to create a game for entertainment or educational purposes. We apply this principle from day one.

Process: how we work in 4 steps

1. Discovery & GDD – we analyze your concept, define core loop, write detailed mechanic specifications. (1–2 weeks)
2. Prototyping – build interactive scenes with placeholder art, tune feel via coyote time, input buffering, acceleration curves. (2–3 weeks)
3. Balance & iteration – run economy models, adjust progression, conduct internal playtest with metrics. (1 week per major mechanic)
4. Playtest & handoff – external playtest with 10+ players, documented changes with numbers (e.g., "startup 400ms → 250ms"), deliver final GDD and configuration files.

Iteration and playtesting: 2-week cycle

The first prototype is always uncomfortable — that's normal. Our cycle: playtest every 2 weeks. After that, a list of changes with numbers: "startup 400 ms → 250 ms". Opinions without numbers are not accepted. We record feelings, change numbers, repeat. Clients save 2 to 3 weeks on iterations thanks to this process.

Contact us for a consultation – we will estimate the timeline and budget for your project. Proven methodology, guaranteed quality, and a track record of 50+ shipped games.