Skip to main content
Skip to navigation

RevenueCat Test Store

Testing purchases in RevenueCat Test Store

AIAsk AIChatGPTClaude

Test Store is RevenueCat's built-in testing environment that works immediately without platform setup.

Test Store works automatically with the RevenueCat SDK—no additional configuration is required beyond using your Test Store API key. Test purchases made through Test Store behave like real purchases and subscriptions: they update CustomerInfo, trigger entitlements, and appear in your RevenueCat dashboard.

📘SDK Version Requirements

Test Store requires the following minimum SDK versions:

PlatformMinimum Version
iOS5.43.0
Android9.9.0
Flutter9.8.0
React Native9.5.4
Capacitor11.2.6
Cordova7.2.0
Unity8.3.0
KMP2.2.2
Web (JS)1.15.0

Older SDK versions will not support Test Store products.

Getting started​

During the setup of a new RevenueCat project, a Test Store will be automatically created with products. You can create them manually following the steps below.

  1. Create a Test Store
  2. Configure test products and offerings
  3. Initialize the SDK with your Test Store API key
  4. Make test purchases in your app

Create a Test Store​

If you have not created a Test Store for this project, create one on the Apps and providers tab in the sidebar. In the Test configuration section, create a new Test Store and you will be presented with an API key to use in the SDK.

Configure test products and offerings​

Next, create products and attach them to an offering so users can purchase them in your app. Do this in the Product catalog tab in the sidebar. Create products for the Test Store in the Products tab, then attach those products to an offering in the Offerings tab. Alternatively, if you already have an existing offering, you can create the Test Store products directly on the offering edit page.

Changing Test Store products and prices​

Test Store products are configured at creation time. You cannot edit an existing product's identifier, duration, or price in the dashboard after it has been saved — there is no in-place edit control on the product page.

To use a different price (or duration):

  1. Create a new Test Store product with the updated price.
  2. In Offerings, replace the old product in the package with the new one (or create the Test Store product from the offering edit page).
  3. Optionally archive the old product once nothing references it.

Creating a new product instead of editing also keeps historical data cleaner if you later compare prices in Experiments.

Initialize the SDK with your Test Store API key​

To configure your SDK to use the Test Store instead of the real store, use the Test Store API Key generated above whenever you initialize the RevenueCat SDK. Before shipping to production, switch this key back to the platform-specific API keys for each platform your app supports. You can find all your keys in Project Settings > API keys.

❗️Never submit apps with a Test Store API key

Never submit an app to the App Store or Google Play that is configured with a Test Store API key. Use build configurations or environment variables to select the Test Store API key for debug builds and the platform-specific API key for release builds. In release builds, the SDK crashes on purpose when it finds a Test Store API key.

Make test purchases in your app​

Once the SDK is configured with the correct Test Store API key, you can start making test purchases in your app. Instead of invoking the system in-app purchase flow, your app will present a modal with metadata about the product being purchased, along with buttons to simulate a successful purchase, a failed purchase, or cancel the purchase entirely.

Use these options to manually test how your code responds to different in-app purchase outcomes, or to write automated integration tests without interacting with real store flows.

Purchases through Test Store will be reported as sandbox data. Learn more at Viewing Non-Production Data.

Control test purchase behavior

You can control whether test purchases (both Test Store and platform sandboxes) grant entitlements using Sandbox Testing Access settings. This is useful for restricting testing to specific app user IDs.

Test Store API keys in release builds​

The SDK checks how your app was compiled, not how it is distributed. When you configure the SDK with a Test Store API key in a release build, the SDK logs an error, shows an alert that explains the problem, and then crashes on purpose so that a build using the Test Store cannot reach the stores.

The check triggers in:

  • iOS: any build compiled without the DEBUG flag, which is the default Release configuration.
  • Android: any build that is not debuggable (android:debuggable is false), which is the default release build type.

TestFlight builds and Google Play internal, closed, and open testing tracks are release builds, so a Test Store API key crashes them too. To test on those tracks, use your platform-specific API key with the platform sandbox. See Apple App Store & TestFlight and Google Play Store.

If you add the iOS SDK as a prebuilt XCFramework, the framework is compiled in the Release configuration, so the check also triggers in your debug builds.

Allowing the Test Store in a release build​

If you have an internal build that is compiled in release mode and never uploaded to the stores, such as a staging app with its own bundle ID, opt out of the check with the forceAllowTestStoreInReleaseBuilds dangerous setting. It is available in the iOS SDK 5.89.0 and later and the Android SDK 10.21.0 and later.

import RevenueCat

// Only for internal builds compiled in Release that are never uploaded to the App Store.
let configuration = Configuration.Builder(withAPIKey: <test_store_api_key>)
    .with(dangerousSettings: DangerousSettings(
        autoSyncPurchases: true,
        forceAllowTestStoreInReleaseBuilds: true
    ))
    .build()

Purchases.configure(with: configuration)

Only enable this setting in a build configuration or flavor that cannot be promoted to production. It removes the last safeguard against shipping a Test Store API key to the App Store or Google Play.

The Flutter, React Native, Capacitor, Cordova, Unity, and Kotlin Multiplatform SDKs do not expose this setting yet. On those platforms, use the Test Store API key in debug builds only, and use your platform-specific API key with the platform sandbox for release builds.

Subscription renewals and expiration​

When testing subscriptions in the Test Store, renewals and expirations occur much faster than with real purchases. Each test subscription will renew automatically up to 5 times, after which it will cancel and its associated entitlements will become inactive.

Product DurationTest Store Renewal IntervalTotal Time Until Subscription Ends (after 5 renewals)
1 week5 minutes25 minutes
1 month5 minutes25 minutes
2 months10 minutes50 minutes
3 months15 minutes75 minutes
6 months30 minutes150 minutes
1 year1 hour5 hours
Was this page helpful?