Use this page with AI
Copy this into your coding assistant and add your request.
Read https://openiap.dev/docs/foundation/about and https://openiap.dev/llms.txt. Follow the reading instructions, detailed reference, and linked guides relevant to my task before making changes.
Inspect my existing project and reuse its framework and conventions. Ask me for missing product decisions. Implement the requested behavior and run the applicable checks.
Show the working result, the commands and actual test results, and any remaining limitations. Keep your explanation brief.
My request: [describe what customers should be able to do]OpenIAP: Neutral Interoperability Layer for In-App Purchase APIs and Verification
The Problem#
Every framework — React Native, Expo, Flutter, Kotlin Multiplatform, .NET MAUI, Godot, native iOS and Android — implements in-app purchases on its own: its own types, error model, verification flow and edge cases.
And the stores keep multiplying. Meta Horizon OS, Vega OS, HarmonyOS and Amazon Fire OS each have their own billing API, as do Galaxy Store, Huawei AppGallery and alternative marketplaces such as Onside, while Google Play and the App Store change theirs with every major release. The result:
- Duplicated effort across ecosystems, with each SDK maintaining its own interpretation of store APIs
- Inconsistent behavior causing revenue leakage, failed transactions, and poor user experiences
- Security gaps where receipt validation and fraud prevention are left as afterthoughts
- High maintenance burden as Apple, Google, and an expanding set of stores frequently change their billing APIs
What OpenIAP Is#
OpenIAP is an open standard for in-app purchases: two specifications, and the SDKs and tests that hold implementations to them.
- Client Protocol 0.1.1 — The purchase API every SDK implements.
- Commerce Protocol 0.3.1 — The server-side contract backends implement.
Around the specifications#
| Component | Description |
|---|---|
| Code generation | Typed bindings for TypeScript, Swift, Kotlin, Dart, GDScript and C# from the Client Protocol schema |
| Native implementations | openiap-apple (StoreKit 2) and openiap-google (Play Billing 9.1.0, Amazon Appstore, Meta Horizon) |
| Conformance | A versioned behavioral contract. Expo, React Native, Android, Apple and IAPKit each cover documented subsets; Flutter, KMP, MAUI and Godot do not have adapters yet. See behavioral conformance. |
What Neutral Means Here#
- Everything is open source: MIT, and Apache-2.0 for kmp-iap.
- Neither protocol routes a purchase through a service the project runs: an app, its backend and the store talk to each other directly.
- IAPKit, the maintainer's hosted verification service, is held to the same schema and conformance checks as any other implementation.
Governance describes how decisions are made today and how that opens up as maintainers and sponsors join.
Official SDKs#
Apps built on them are listed in the showcase.
| Ecosystem | SDK |
|---|---|
| Expo | expo-iap |
| React Native | react-native-iap |
| Flutter | flutter_inapp_purchase |
| Kotlin Multiplatform | kmp-iap |
| .NET MAUI | maui-iap |
| Godot | godot-iap |
| Native iOS and macOS | openiap-apple (StoreKit 2) |
| Native Android | openiap-google (Play Billing, Amazon Appstore, Meta Horizon) |
Adoption#
- Downloads: react-native-iap 14M+ and expo-iap 4M+ on npm (September 2026)
- Sponsors: Meta (Angel), Amazon Developer (Angel)
What We're Building Next#
The roadmap, with each item's status, is on Roadmap & Budget.
Why Now#
- Regulation: the EU Digital Markets Act and Epic v. Apple opened alternative payment paths that apps may now offer next to store billing.
- Platform API churn: Apple (StoreKit 2) and Google (Billing 8 and 9) have both made breaking changes in recent years.
Contact#
- Project Lead: Hyo (hyo.dev) — contact the project lead
- GitHub: github.com/hyodotdev/openiap