Skip to main content
Use RevenueCat Test Store to automate in-app purchase flows without an App Store or Google Play test account. Test purchases update CustomerInfo, grant entitlements, and appear as sandbox data in RevenueCat. To test native Apple or Google purchase flows, see Native in-app purchases on private devices. Contact Autosana before preparing a build or configuring devices for this workflow.

​
RevenueCat

​
How it works

RevenueCat Test Store replaces the native store purchase sheet with a test modal. Autosana can select a successful, failed, or cancelled outcome and then verify how your app responds. Use this workflow to test:
  • Paywall navigation and product selection
  • Successful purchases and entitlement unlocks
  • Failed and cancelled purchases
  • Entitlement state after the app is reopened

​
Configure RevenueCat Test Store

  1. Check that your RevenueCat SDK supports Test Store in the RevenueCat Test Store requirements.
  2. In RevenueCat, open Apps and providers and create or select a Test Store.
  3. In Product catalog, create the products used by your test paywall.
  4. Attach each product to a package in an offering. Make sure your app fetches that offering.
  5. Initialize the RevenueCat SDK with the Test Store API key. Test Store keys begin with test_.
Never submit a build configured with a Test Store key to the App Store or Google Play. Use build configuration or environment variables to select the Test Store key only for dedicated test builds.

​
Build a standalone test app

Create a development or debug build that:
  • Uses the RevenueCat test_ key
  • Includes the app code and assets needed to run without a development server
  • Does not depend on Metro, hot reload, or another process on your computer
If your framework’s normal debug build connects to a local bundler, create a dedicated standalone testing configuration that remains a development/debug build while bundling the app locally. See Building Your Mobile App for Our Cloud for supported artifact formats and platform-specific build requirements.

​
Upload the build to Autosana

  1. Open Apps in Autosana.
  2. Create or select your iOS or Android app.
  3. Upload the standalone test artifact and make it the active build: a zipped .app for an iOS Simulator, or an .apk or .aab for Android.
  4. Run the purchase flows on a compatible virtual device.

​
Create purchase flows

Create separate flows for outcomes that need a clean starting state. Replace the bracketed text with the screens, plans, and premium state used by your app.

​
Verify the result in RevenueCat

After a run, open the customer in RevenueCat and enable sandbox data. Confirm that:
  • The purchase is associated with the expected App User ID
  • A successful purchase activated the expected entitlement
  • A failed or cancelled purchase did not activate the entitlement
If you use RevenueCat webhooks or integrations, you can also confirm that the matching sandbox event was delivered.

​
Troubleshooting

​
Before you ship

Replace the test_ key with the correct platform-specific RevenueCat key before releasing the app. RevenueCat also recommends completing final purchase validation through Apple or Google platform sandboxes; follow RevenueCat’s sandbox testing guide for those steps.

​
Native in-app purchases on private devices

Native purchase testing exercises the Apple StoreKit or Google Play Billing purchase flow, including the store’s purchase UI and sandbox transactions. This also applies to apps that use RevenueCat with its Apple or Google store integration instead of Test Store.
Native purchase testing on AWS Device Farm private devices requires an enterprise contract with Autosana and coordinated onboarding. Contact us first to confirm feasibility, device availability, commercial terms, and setup for your app. Selecting Real device in a standard run does not configure native purchase testing.

​
What to share with us

  • Your target platform and app bundle ID or package name
  • Whether you use StoreKit, Google Play Billing, or RevenueCat
  • The scenarios you want to test, such as a first purchase, cancellation, restore, or subscription expiry
  • Any required device models or OS versions
We will agree on the device and build configuration, test-account setup, and how purchase state will be prepared between runs. Use dedicated test accounts that your team controls rather than personal accounts. We will agree on sign-in and any secure credential-sharing process during onboarding; do not include passwords in your initial email.

​
iOS build and sandbox setup

AWS Device Farm normally re-signs uploaded apps. Private devices allow us to preserve the app’s original signing using Skip app re-signing, which matters for native Apple capabilities. During onboarding:
  1. We confirm the private devices and signing approach before you build. If the provisioning profile requires registered devices, we provide the private devices’ UDIDs for your Apple Developer account.
  2. You prepare the agreed device build. For Apple’s documented sandbox workflow, use a development-signed build. Register the supplied UDIDs where required, update the agreed provisioning profile, and export the signed .ipa. A Simulator .app is not suitable for physical devices.
  3. You configure Apple sandbox testing. Prepare your in-app purchase products and Sandbox Apple Accounts in App Store Connect.
  4. We configure and validate the private-device session. We coordinate Developer Mode and sandbox sign-in on the private device, preserve app signing, and validate a sandbox purchase before running your automated flows.
An Apple Developer Enterprise account is not a prerequisite. If you already use Enterprise signing, discuss it with us first: installing an Enterprise app and validating native sandbox purchases are separate checks. AWS also requires its support team to trust Enterprise apps on private devices running iOS 18 or later. See AWS’s private-device signing requirements and Apple’s sandbox setup for the underlying platform requirements.

​
Android build and test-account setup

Contact us before preparing an Android build. During onboarding, we agree on the installation path, private-device configuration, and Google account used for purchases.

​
Prepare Google Play and the test account

  1. Confirm the app and product catalog. Share the package name and the product IDs, subscription base plans, and offers your flows should exercise. Configure them in Play Console and confirm that they are available to the intended tester. If you use RevenueCat, connect the Google products to the appropriate offerings and entitlements, and use the Google store integration in this build instead of a test_ key.
  2. Add the agreed Google account as a license tester. Follow Google’s license-testing setup. We coordinate sign-in on the private device with you.
  3. If distributing through Google Play, grant test-track access too. Publish the build to an internal or closed testing track, add the tester, and share the opt-in link with us. Track membership and license-testing status are separate settings. See Google’s testing-track setup.
Joining an internal or closed testing track does not make purchases free. The purchasing account must also be a license tester to use Google’s test payment methods. We confirm the test-purchase UI during onboarding before automated purchase flows begin.

​
Choose the build and installation path

We confirm which path fits your app before you upload anything: Google allows license testers to sideload matching-package builds, including debug-signed builds, without uploading every new version to Play. A separate .debug package name must correspond to its own configured Play app. See Google’s billing test guide. For AWS private-device uploads, we coordinate Skip app re-signing to preserve your APK’s signature. Tell us if the app depends on Play Integrity or certificate-bound services so we can validate those requirements with the selected installation path. See AWS’s signing requirements.

​
Validate the first purchase and repeat runs

We verify the purchasing account and test payment method, then check the resulting entitlement with you. Share which success, decline, cancellation, and subscription-state scenarios matter for your app so we can define separate flows and their starting states. Google test subscriptions run on accelerated schedules. We can discuss Play Billing Lab for repeat trial or subscription-state scenarios during onboarding; any Lab setup must be included in the agreed workflow. See Google’s billing test guide. Before automating repeated purchases, we agree on how your team will prepare account state and verify backend purchase processing. The flow’s assertions should cover both access being granted after a purchase and access changing when the scenario calls for it.

​
Keeping purchase tests repeatable

Purchases change the test account’s state. Reinstalling the app alone does not establish that an account is eligible for a first purchase or free trial again. During onboarding, we agree on the starting state for each flow and the account reset or rotation process needed between runs. For each successful purchase, verify both the app’s unlocked state and the corresponding sandbox transaction or entitlement in your billing backend or RevenueCat.