tags: [vr-ar]
In-app purchase integration for VR applications
Meta Quest Store, SteamVR and PCVR have different IAP requirements. App for Quest must use native Meta IAP SDK — third-party payment processors in Meta Store apps prohibited. For Steam — Steamworks API. If releasing on both platforms, need abstraction layer switching implementation by platform.
Starting IAP integration without understanding target store requirements — guaranteed review rejection.
Meta Platform SDK: IAP for Quest
Meta Platform SDK (com.meta.xr.sdk.platform) provides IAP via IAP.GetProductsBySKU and IAP.LaunchCheckoutFlow. All SKUs created beforehand in Meta Developer Console under specific App ID. Without this SDK calling LaunchCheckoutFlow returns PURCHASE_NOT_ALLOWED error even in test mode.
Testing IAP on Quest: in Developer Console add test users in Test Users section of organization. Only they can make test purchases without actual charges. Without this setting developers regularly hit "IAP not working" — problem is test account rights, not code.
Subscriptions in Meta IAP are separate product type (SUBSCRIPTION). Subscriptions have trialPeriodDays, billingPeriod, startDate. When checking active subscription use IAP.GetCurrentEntitlements — returns all active entitlements including subscriptions. Important: entitlement doesn't disappear immediately on subscription cancellation — it's active until end of paid period. Need to check ExpirationTime, not just presence.
Restore purchases: Meta automatically restores non-consumable purchases on app login with same Meta account via IAP.GetViewerPurchases. Consumable purchases (coins, consumables) aren't restored — must be marked consumed via IAP.ConsumePurchase after giving to player.
Steamworks and PCVR
For Steam use Steamworks.NET — C# wrapper over Steamworks API. Microtransactions via Steam work through SteamUser.GetSteamID + server-side verification via Steam Web API. Unlike Meta, Steam recommends server verification: client initiates purchase → Steam returns OrderID → game server verifies via ISteamMicroTxn/FinalizeTxn → give item. Without server verification purchases can be faked via memory editing.
For VR-only games on Steam without dedicated server (single-player or P2P), verification via Steam Inventory Service — Steam itself stores inventory items, and client-side cheats don't affect Steam Inventory.
Unity IAP as cross-platform abstraction
Unity In-App Purchasing (com.unity.purchasing) supports Meta Store via Meta Appstore IAP and Steam via Steam IAP in single API. IStoreController.InitiatePurchase(product) works same on both platforms with correct config Builder.
Problem of Unity IAP on Meta Quest: package uses Google Play Billing as base for Android. Quest also Android-based, and Unity IAP by default might try Google Play Store instead of Meta Store. Need explicitly set StandardPurchasingModule.useFakeStoreAlways = false and add Meta Store via builder.AddStoreConfiguration.
Limitation: Unity IAP doesn't support all native SDK features — for example, Meta-specific subscriptions with trial require code outside Unity IAP. If project needs native features, Unity IAP used only as fallback, Meta SDK as primary.
Server verification and chargeback protection
Chargeback and refund in Meta Store — user requests refund, Meta approves, but entitlement already activated in game. If game gave item on purchase without checking entitlement later, player got item free.
Protection: don't give expensive items immediately on client. Pattern: LaunchCheckoutFlow → GetViewerPurchases (status check) → delivery via server with DB record. On each app launch — recheck active entitlements via GetViewerPurchases and compare with server record. On mismatch — block item.
For Free-to-Play VR with cosmetic purchases server verification often not critical (stolen skin doesn't break economy), but for games with pay-to-win elements or subscriptions — 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 |
Cost calculated after analyzing requirements: platforms, product types, server infrastructure presence.





