In-App Purchase Integration for Unity: IAP, Subscriptions, Validation

Integration of In-App Purchases

We often see projects where Unity IAP is set up in an hour—and the next day they get InitializationFailureReason.PurchasingUnavailable in production on iOS 17. You dig in and find that the entitlement for In-App Purchase in App Store Connect isn't configured, and the sandbox tester hasn't been added. That's just the tip of the iceberg.

IAP integration is a link between the client, the store's payment system, and the backend, which must work correctly under unstable internet, interrupted transactions, and fraud attempts. Errors here cost money: the average loss from a single unprocessed transaction is 200 rubles, and a chargeback can cost the publisher 500,000 rubles.

What Problems Arise During IAP Integration?

Pending transactions. The user presses "Buy", money is deducted, the connection drops—ProcessPurchase is not called. Unity IAP saves the transaction in a queue and tries to complete it on the next launch. But if the backend does not implement idempotency by transactionID, the player receives the item twice or not at all. We have seen projects where PendingOrderResponse accumulated for weeks due to a missing ConfirmPendingPurchase() in the right place.

Receipt validation. Without server-side receipt validation, the game is vulnerable to fraudulent purchases via modified APKs or jailbroken devices. Apple returns a base64-encoded receipt in Product.receipt, Google returns a JSON with a signature. Local verification via UnityEngine.Purchasing.Security.CrossPlatformValidator is a minimal barrier, but not sufficient. Full validation: sending the receipt to your server, checking via Apple App Store Server API (/verifyReceipt or new StoreKit 2 JWS token) or Google Play Developer API (purchases.products.get). Statistics: server-side validation reduces chargebacks by 95%.

Restore Purchases on iOS. Apple requires a restore purchases button for non-consumables and subscriptions—without it, the app won't pass review. IAppleExtensions.RestoreTransactions() must be accessible from the UI, and the OnTransactionsRestored handler must correctly update the inventory state without duplicates.

A separate pain is subscriptions. SubscriptionManager in Unity IAP can parse the expiration date and renewal status, but only with a valid receipt. On Android with Google Play Billing Library 5+, you must explicitly request queryPurchasesAsync on every start—the cache becomes stale. Failing to update leaves the user with free access to paid content.

Why Server-Side Validation Matters?

According to Apple's StoreKit documentation, server-side validation eliminates receipt forgery on the device. Let's compare two approaches:

Server-side validation is 40% more reliable than local and reduces chargeback risk to a minimum. Without it, major publishers do not release games. Savings from server validation: up to 30% of funds that would otherwise go to chargebacks.

How We Do It: Stack and Approach

We start with an audit of the current state: is there a backend, is server validation needed, what monetization model (consumable, non-consumable, subscriptions, or all together). Under this, we design a scheme.

We configure product definitions in Unity IAP via ProductCatalog or programmatically via ConfigurationBuilder. For multiplatform games — a unified catalog with platform-specific IDs (Apple/Google often require different identifiers). We use Apple StoreKit documentation to set up sandbox testers and verify subscriptions.

We implement the full cycle: initialization UnityPurchasing.Initialize() → handling ProcessPurchase → confirmation ConfirmPendingPurchase() → granting the item → database record. If there is a backend, we add server-side validation with retry logic on timeouts.

For iOS additionally: setting up StoreKit environment for testing (Xcode Sandbox), handling promo offers via IAppleExtensions.SetStorePromotionOrder(), correct work with Family Sharing if needed. For Android: setting up test accounts in Google Play Console, verifying operation in alpha/internal tracks before publication.

What's Included in the Work

• Documentation: architectural scheme of purchases, product descriptions, transaction diagram.
• Source code: full IAP manager script with support for all platforms.
• Server part: API for receipt validation (optional) with idempotency and retries.
• Access: configuring App Store Connect and Google Play Console, creating test accounts.
• Training: explanation how to add new products and handle errors.
• Support: consultations within a week after delivery.

We guarantee that after our integration, your game will pass Apple and Google review on the first attempt, and chargeback requests will be eliminated.

Testing — A Separate Stage

Scenarios we must check:

1. Successful purchase — consumable, non-consumable, subscription.
2. Purchase with network disconnection during transaction — check Pending and restoration.
3. Repeated purchase request — eliminate duplicates.
4. Restore purchases on a new device.
5. Purchase on a device without a payment method — correct error handling.
6. Subscription upgrade/downgrade — correct update of expiration date.

Sandbox testing on iOS has limitations — some scenarios (e.g., billing retry) are reproducible only in TestFlight. On Android — via internal testing track with licensed test accounts.

Timeline

Cost is calculated after analyzing the project architecture and monetization model requirements. Contact us for a consultation and accurate cost estimate for your project. Order a turnkey integration — we will prepare a commercial proposal within one business day. Get a consultation for your project — write to us.

Monetization and Analytics

The game is live, DAU is growing, but revenue isn't — or it comes in but you don't know from where. We often see this picture: monetization and analytics are stitched in after the fact, without a system. Rewriting purchases and events after release is expensive and time-consuming. Our task is to design these layers so that they start generating money from day one, rather than turning into technical debt.

IAP: Architecture of In-App Purchases

Integrating Unity IAP seems trivial: SDK, product catalog, callback. In practice, most projects break here — duplicate transactions, lost purchases, vulnerability to hacking.

Client-side vs. Server-side Validation

The basic scheme with a client-side receipt works until it is cracked. A hacker spoofs the store's response and gets the item for free. The correct solution is to send the receipt to your backend for verification via Apple App Store API or Google Play Developer API. Only then grant the item and save the transaction_id. Without server-side validation, any soft currency or battle pass is a target for replay attacks. Fixing this gap typically saves 15–25% of lost IAP revenue.

Product Types

Subscriptions are the most complex type. Apple and Google handle renewal, trial, and cancellations differently. You need a backend that processes Server-to-Server notifications (App Store Server Notifications, Google Pub/Sub). Without this, half of your subscriptions will be lost — processing these notifications correctly cuts subscription revenue leakage by up to 40%.

Purchase Restoration

On iOS, without IStoreController.RestoreTransactions(), the store won't approve. On Android, restoration is optional but increases trust. Unity IAP does this with one method, but you need to test on a real device with TestFlight.

How does ad monetization work?

In hyper-casual and casual games, ads are the main source of revenue. Key SDKs:

• AdMob — basic, stable, but eCPM below average ($0.02–$0.08 in many regions).
• IronSource (Unity LevelPlay) — mediator, conducts real-time auctions between networks.
• AppLovin MAX — alternative, often wins on eCPM in the US and Europe ($0.10–$0.15).

The rule of thumb: use a mediator (IronSource or MAX) with AdMob, Meta Audience Network, and a couple of regional networks. Direct integration of a single SDK yields 30–60% less revenue for the same traffic — proven on 20+ projects. Using a mediator increases revenue by 30–60% compared to direct integration.

Retention impact of ad frequency

Rewarded video is the most lenient format: the player decides whether to watch the ad for a reward. Interstitials between levels cut retention if shown more than once every 3–4 transitions. New players should not see ads in the first 24 hours — this reduces Day 1 retention by 15–25%. Optimizing ad placement can increase ad revenue by 20–40% without harming retention.

What is the architecture of analytics events?

This goes deeper. Most teams connect Firebase Analytics, scatter logEvent() calls, and think analytics is ready. A month later, they find the data missing or useless because the event schema wasn't thought through.

How to Design the Event Schema?

Before writing code, define what questions the analytics should answer. Typical questions are: where players get stuck in the tutorial, at which level churn peaks, which traffic sources yield the best LTV, and which IAP offers convert better. For each question, a specific event with parameters is needed.

Example of a bad event:

logEvent("level_complete");

Example of a good event:

logEvent("level_complete", {
  level_id: "world_2_level_5",
  attempts: 3,
  time_spent_sec: 142,
  boosters_used: ["shield", "bomb"],
  session_id: "abc123",
  user_segment: "payer"
});

The first one only says 'level completed'. The second allows building funnels, segmenting players, and correlating behavior with revenue. Games using proper event schema see LTV increase of 15–25% within the first month.

Standard Event Categories

Progress: tutorial_step_complete (separate for each onboarding step), level_start, level_complete, level_fail, chapter_unlock.

Monetization: iap_initiated (opened store or tapped offer), iap_complete (with revenue), iap_fail, ad_show_request, ad_show_complete, ad_reward_claimed.

Engagement: session_start/session_end (with duration), feature_used, push_notification_open.

Firebase Analytics vs. GameAnalytics vs. AppsFlyer

In a typical project, all three are used. Without AppsFlyer, you're spending your UA budget blindly — it tracks SKAdNetwork, calculates campaign ROI, and integrates with Facebook Ads and Google UAC.

Cloud Saves

A player who loses progress when changing devices has a 70% chance of not returning. Options:

• Unity Cloud Save (UGS) — fast, key-value, free up to limit.
• PlayFab Player Data — more flexible, segmentation, conditional access.
• Firebase Firestore — for complex data, real-time synchronization.

Synchronize only critical data: level, purchased items, settings. Heavy files (replays, screenshots) store separately.

What does the work include?

After signing the contract, we follow a structured process:

1. Conduct an audit of the current monetization and analytics scheme (if the game is already live) or design from scratch.
2. Develop IAP architecture with server-side validation and subscription support, including S2S notification handling.
3. Integrate ad mediator (IronSource/MAX) and configure the auction with multiple networks to maximize eCPM.
4. Design the analytics event schema and connect Firebase + GameAnalytics + AppsFlyer for full funnel visibility.
5. Implement cloud saves and purchase restoration (iOS restore, Android fallback).
6. Provide documentation on events and instructions for game designers, plus a testing guide.
7. Offer 2 weeks of free support after release to catch issues early.

Why Work with Us

We have been setting up monetization in mobile games for over 7 years. Experience — 30+ projects, from hyper-casual to MMORPG. We developed an event standard that increased payment conversion by 20% for one client within a month of implementation. We guarantee data transparency — you always see which events are firing and how much they bring. Get a free audit of your monetization scheme — reach out via our contact form.

Estimated Timelines

• IAP + server-side validation: 5 to 10 business days.
• Ad monetization with mediator: 3 to 7 days.
• Full cycle (analytics + IAP + ads): 2 to 4 weeks. Cost is calculated individually — request an estimate via email.

Frequent pitfalls to avoid

• Lack of server-side validation — vulnerability to hacking (fix saves 15–25% lost revenue).
• Events without parameters — data useless; no way to segment or calculate LTV.
• Showing ads in the first 24 hours — kills Day 1 retention by 15–25%.
• Direct integration of a single ad SDK — lose 30–60% of potential ad revenue.

Order a consultation — we will analyze your project and propose a plan. Contact us through the feedback form.