Integrating In-App Purchases for VR Applications
We often face the task of integrating in-app purchases (IAP) for VR applications. Meta Quest, SteamVR, and PCVR impose different requirements on payment systems. A Quest application must use the native Meta IAP SDK — third-party processors are prohibited in the Meta Store. For Steam — Steamworks API. If the project targets both platforms, an abstraction that switches the implementation based on the runtime platform is needed. Starting IAP integration without understanding the target store's requirements is a guaranteed revision.
How to Avoid Mistakes When Testing IAP on Quest?
The Meta Platform SDK (com.meta.xr.sdk.platform) provides IAP via IAP.GetProductsBySKU and IAP.LaunchCheckoutFlow. All SKUs must be set up in advance in the Meta Developer Console under a specific App ID. Without this, calling LaunchCheckoutFlow will return a PURCHASE_NOT_ALLOWED error even in test mode. Testing IAP on Quest: In the Developer Console, add test users in the Test Users section of your organization. Only they can make test purchases without real charges. Without this setting, developers regularly encounter IAP 'not working' — although the issue is the lack of test account permissions. Subscriptions in Meta IAP are a separate product type (SUBSCRIPTION). Subscriptions have trialPeriodDays, billingPeriod, startDate. To check an active subscription, use IAP.GetCurrentEntitlements — returns all active entitlements, including subscriptions. Important: an entitlement does not disappear immediately upon subscription cancellation — it remains active until the end of the paid period. You must check ExpirationTime, not just the existence. Restoring purchases: Meta automatically restores non-consumable purchases when logging in with the same account via IAP.GetViewerPurchases. Consumable purchases (coins, consumables) are not restored — they must be consumed via IAP.ConsumePurchase after granting to the player.
Steamworks and PCVR: Server-Side Verification Is Mandatory
For Steam, we use Steamworks.NET — a C# wrapper over the Steamworks API. Microtransactions through Steam work via SteamUser.GetSteamID + server-side verification via the Steam Web API. Unlike Meta, Steam recommends server-side purchase verification: the client initiates a purchase → Steam returns an OrderID → the game server verifies via ISteamMicroTxn/FinalizeTxn → grants the item. Without server verification, purchases can be faked through memory editing. For VR-only games on Steam without a dedicated server (single-player or P2P), verification is handled via Steam Inventory Service — Steam itself stores inventory items, and client-side cheats do not affect Steam Inventory.
Unity IAP as a Cross-Platform Abstraction
Unity In-App Purchasing (com.unity.purchasing) supports Meta Store via Meta Appstore IAP and Steam via Steam IAP in a single API. IStoreController.InitiatePurchase(product) works identically on both platforms with proper Builder configuration. Unity IAP reduces development time by 30–40% compared to integrating two native SDKs separately. The issue with Unity IAP on Meta Quest: Unity IAP uses Google Play Billing as a base for Android. Quest is also an Android-based platform, and Unity IAP may default to using Google Play Store instead of Meta Store. You must explicitly set StandardPurchasingModule.useFakeStoreAlways = false and add Meta Store via builder.AddStoreConfiguration. Limitation: Unity IAP does not support all native SDK features — for example, Meta-specific subscriptions with trials require additional code outside Unity IAP. If the project requires native features, Unity IAP is used only as a fallback, with Meta SDK as primary.
Why Is Server-Side Verification Mandatory for Pay-to-Win VR Games?
Chargebacks and refunds in Meta Store: a user requests a refund, Meta approves it, but the entitlement in the game is already activated. If the game granted the item upon purchase and does not re-check the entitlement, the player received the item for free. Protection: do not grant expensive items instantly on the client. Pattern: LaunchCheckoutFlow → GetViewerPurchases (check status) → grant through the server with a database record. At each application launch — re-check active entitlements via GetViewerPurchases and reconcile with the server record. On mismatch — block the item. For free-to-play VR games with cosmetic purchases, server verification is often not critical (a stolen skin does not break the economy), but for games with pay-to-win elements or subscriptions, it is mandatory.
| Platform / Complexity | Estimated Timeline |
|---|---|
| Meta Quest IAP (consumable + non-consumable) | 1–2 weeks |
| Steam IAP via Steamworks | 1–2 weeks |
| Cross-platform Unity IAP + native SDKs | 2–4 weeks |
| Server verification + chargeback protection | +1–3 weeks |
| Verification Method | Protection Level | Implementation Complexity |
|---|---|---|
| Client-side (SDK only) | Low | Fast |
| Server-side + Steam Inventory | High | Medium |
| Server-side + Meta Entitlements | High | High |
What Is Included
- Setup of Meta IAP SDK with correct SKUs in Developer Console
- Integration of Steamworks for microtransactions with server-side verification
- Creation of a cross-platform abstraction via Unity IAP with fallback to native SDKs
- Testing on real devices with test accounts
- Documentation of the IAP system and maintenance instructions
- Post-launch support: purchase monitoring and refund issue resolution
We have implemented IAP for 15+ VR projects over many years. We will assess your project and offer the optimal solution — from simple integration to comprehensive fraud protection. Contact us to discuss the details.
The cost is calculated individually after requirements analysis: platforms, product types, server infrastructure availability.