Store Setup

How the Store Is Selected#

Keep every store credential in the project — the Horizon app id and the Amazon AppstoreAuthenticationKey.pem are inert on the other stores — and let the build pick the store. The Gradle wrappers (React Native, Expo, and Flutter) apply the whole rule, first match wins, and so does the OpenIAP Gradle plugin in native Android and KMP apps. A Godot export applies it with the openiap/android_store export option as the explicit step and no Variant step, and a MAUI build the same way with the OpenIapStore MSBuild property:

1. Explicit — openiapStore=play|horizon|amazon as a Gradle property: -PopeniapStore=horizon, ORG_GRADLE_PROJECT_openiapStore=horizon in an EAS profile, or gradle.properties. fireOsEnabled=true declares a Fire OS build as openiapStore=amazon does. auto means no pin. The legacy horizonEnabled still pins with a deprecation warning and is removed in the next major release. Only flutter_inapp_purchase accepts openiapStore=none (or the legacy openiapPlatform=none) to build without a store SDK.
2. Variant — the requested task names a store flavor: assembleHorizonRelease, installAmazonDebug, or flutter build apk --flavor amazon in a Flutter app that declares those flavors. Only a spelled-out task name is read: once the task graph is ready, an abbreviation such as aHR, a lower-cased name or a prefix that builds another store stops the build instead of shipping the wrong SDK. Name one store per invocation, and name it play, horizon or amazon — the aliases work in openiapStore, not in a flavor name. An anchor task such as assembleDebug or bundleRelease is not a second store, and it does not give each flavor its own: the build links the one store this rule chose into every flavor the anchor produces. To ship a different store per flavor, name one flavor — or one pin — per invocation.
3. Device — debug builds only (a Godot debug export, a MAUI Debug build): the adb device ANDROID_SERIAL names (for MAUI, the IDE's AdbTarget first), or the single attached one, is a Quest or a Fire device. Release builds never look at a device, and several attached devices select nothing unless ANDROID_SERIAL picks one. The device pickers in flutter run -d, expo run:android --device, and react-native run-android --deviceId are not passed to Gradle, so export ANDROID_SERIAL yourself when several devices are attached.
4. Play otherwise.

The decision is logged once per build as openiap: store=horizon (source=device; ...), at Gradle's quiet level, so -q runs show it too. A store pin against a different task flavor, two flavors in one invocation, and a pin against a store flag or openiapPlatform=none each fail the build, so a pinned release train cannot quietly ship the wrong billing SDK. The device is a fallback rather than a competing signal: a pin or a flavor simply outranks it. The device step also works with the configuration cache: plugging in a different device reconfigures the build. The aliases google/gplay/googleplay/google-play/gms, meta/quest, and fire/fireos/fire-os normalize to the three store ids.

Native Android and KMP apps get the rule from the OpenIAP Gradle plugin, applied once in settings.gradle.kts with mavenCentral() in the pluginManagement repositories. Depend on openiap-google with a version of its own, not one only a BOM or constraint supplies; the plugin links the chosen store's build in its place, and a store artifact declared directly must name the same store or the build stops. A module that declares its own platform flavors keeps them: kmp-iap matches each flavor, and one openiap-google dependency links each flavor's store.

// settings.gradle.kts — keep mavenCentral() in pluginManagement.repositories
plugins {
    id("io.github.hyochan.openiap") version "3.6.3"
}

Store Targets#

Framework Model#

Every store guide shows two setup paths, so know which one your project uses. Expo projects declare store values in the Expo config, and a config plugin writes the native files during expo prebuild. Bare React Native, Flutter, KMP, MAUI, Godot, and native Android projects edit their native build files directly.

• Fire OS and Vega OS are separate release artifacts even though both use Amazon receipt verification — do not reuse one build for the other.
• Onside is currently expo-iap only; other frameworks have no Onside build option.