How to Test In-App Purchases in Sandbox Mode on iOS and Android

Sandbox mode is a test environment inside Apple's and Google's real payment systems that lets you run a complete purchase, from tapping subscribe to the app unlocking paid features, without spending real money. It is not a mock or a fake screen. It calls the same StoreKit and Play Billing code your real customers will hit, using a designated test account instead of your personal one. If sandbox testing passes, the paywall itself is not the reason a launch fails.

The reason sandbox testing trips up so many first-time builders is not the concept. It is three specific setup steps that are easy to skip or get wrong, and each one produces a confusing, generic-looking error instead of a clear message telling you what to fix. The rest of this covers each one directly.

This is the mistake that stops purchases before sandbox testing even becomes the issue. Expo Go is a pre-built container app that runs your JavaScript, and it does not include native billing code. RevenueCat, StoreKit, and Google Play Billing all require native modules that only exist in a real build of your own app, so a purchase button tapped inside Expo Go either does nothing or throws an error that has nothing to do with sandbox setup at all.

iOS sandbox testing runs through a dedicated tester account, separate from both your developer account and your personal Apple ID, that Apple's servers recognize as a test purchaser.

Google Play uses a different mechanism: license testers, which are Google accounts you explicitly authorize to make test purchases against your app's real listing without being charged.

This is the setup step that produces the most confusing error, because it looks like your code is broken when the real cause is timing. After you create a new subscription product in App Store Connect, it needs to reach 'Ready to Submit' status before sandbox purchases will work at all, and that can take anywhere from a few minutes to a few hours the first time.

Google Play has the same delay after you first publish a subscription product to an internal testing track. If everything in your build and tester setup looks correct and purchases still fail, check the product status in the console before you touch any code.

A handful of specific errors cover most sandbox failures. Each one traces back to one of the three causes above rather than a bug in your paywall code.

If you are wiring your paywall through RevenueCat, its dashboard shows every purchase event with a Sandbox or Production tag, which is the fastest way to confirm the whole chain actually worked. Open the Customer History for your sandbox tester's app user ID after a test purchase and look for the event to show up tagged Sandbox within a minute or two.

If the purchase went through on-device but never appears in RevenueCat, the most common cause is an API key mismatch: a production key wired into a build you are testing with a sandbox account, or the reverse. Match the key in your Expo app's RevenueCat configuration to the environment you intend to test.

A purchase that completes is only half the test. Run the entire sequence a real customer will hit: open the paywall, start a free trial if you offer one, complete the sandbox purchase, close and reopen the app, and confirm the paid features are still unlocked after a fresh app launch. Sandbox subscriptions also renew on an accelerated schedule, so you can watch a trial convert to a paid period and confirm your app still recognizes an active subscription after that renewal, all inside a single testing session.

Passing sandbox testing before submission is what turns a paywall from a guess into something you know works. Join the App Store Launch Club at applaunchclub.co for $9/month for the full RevenueCat and Expo paywall setup, including the exact entitlement and product configuration members use before their first submission.