Testing in-app purchases and subscriptions in sandbox without losing money

Key takeaways

• Test in layers: StoreKit configuration files for failure cases and time control, then the App Store sandbox and Play license testing for the real store flow.
• Sandbox and license-tester subscriptions renew in minutes and expire after a few cycles, so you can test renewal, expiry and grace periods in one session.
• Play purchases must be acknowledged within three days or they are refunded; the sandbox enforces this.
• Restore purchases is the most-skipped test and a review requirement: buy, reinstall, restore, and try it on a second device, with no purchase, and offline.
• With RevenueCat, test restore behavior, anonymous-to-identified aliasing and every webhook event type from sandbox events.

In this article

1. The layers, and what each one is for
2. iOS layer 1: StoreKit Testing in Xcode
3. iOS layer 2: the App Store sandbox
4. Android: Google Play license testing
5. RevenueCat and other entitlement services
6. Restore purchases: the test everyone skips
7. The checks that have nothing to do with money
8. Mistakes that cost real money
9. Related guides
10. Automating the purchase regression

In-app purchase bugs are expensive in both directions. A paywall that fails loses the sale; an entitlement that does not unlock after payment creates a refund and a one-star review. Yet purchase flows are the least tested part of many mobile apps, because developers are afraid of charging themselves or because the sandbox feels like a maze. It is not. Both stores give you free, documented test environments, and a layered approach lets you test everything from the first tap to a subscription expiring months later without a real card ever being charged.

The layers, and what each one is for

Think of purchase testing as four layers, each closer to production than the last.

Test the bottom layers first because they are fast, then move up to confirm what the store actually does.

iOS layer 1: StoreKit Testing in Xcode

Apple's StoreKit Testing in Xcode lets you define products in a local configuration file and run purchases entirely on the simulator or a device with no App Store connection and no account. You can also sync the file from your App Store Connect products.

What it is uniquely good for:

• Failure cases on demand. The StoreKit transaction manager lets you fail purchases with specific errors, simulate interrupted purchases that require the user to act, and test Ask to Buy approvals and declines.
• Time control. Subscription renewal rates can be sped up so a year passes in minutes, and you can expire, refund or revoke a transaction from the Xcode transaction manager and watch your app react.
• Fresh state. Clear all transactions between runs.

Tests to run here: buy each product, cancel at the payment sheet, fail with a network error, complete an interrupted purchase, refund a non-consumable, let a subscription lapse and renew, and switch between subscription tiers in the same group. For each, confirm the entitlement in your app matches what StoreKit shows.

iOS layer 2: the App Store sandbox

The sandbox uses real App Store servers with test accounts you create in App Store Connect under Users and Access, Sandbox Testers. Apple's sandbox testing guide covers the setup; the points that matter in a beta:

• Sandbox accounts need a real device. On iOS 12 and later you add the account under Settings, App Store, Sandbox Account, so you do not have to sign out of your personal Apple ID.
• TestFlight builds use the sandbox automatically. Testers are not charged, and they do not need a sandbox account for TestFlight purchases, though receipts behave as sandbox receipts.
• Renewal is accelerated. Apple documents that a one-month subscription renews every five minutes and a one-year subscription every hour in the sandbox, with the rate adjustable in App Store Connect since 2022. Subscriptions renew a limited number of times and then expire, which is useful for testing the expiry path.
• You can clear purchase history for a sandbox account from App Store Connect, and you can change the account's storefront to test pricing and currency display.

Tests to run: a full purchase with the real payment sheet, a trial that converts, an expiry after the accelerated renewals finish, a grace period if you have one enabled, and a purchase on one device followed by restore on a second device with the same sandbox account. Check your server receives App Store Server Notifications in the sandbox and handles each notification type.

Android: Google Play license testing

Google's equivalent is license testing in Play Console. You add Gmail addresses as license testers, and those accounts can purchase in any build uploaded to a testing track without being charged. The details that trip people up:

• The build must be uploaded to a track, at least internal testing, and the tester must install from the Play testing link. A sideloaded debug build signed with your debug key will fail with a "item not available" error.
• Products must be active in Play Console before they appear.
• License testers see test payment methods at checkout: "always approves", "always declines", "approves after a delay" and "declines after a delay". Use all four.
• Subscription renewals are shortened to minutes for license testers, and the subscription expires after a few renewals. Google's test subscriptions documentation lists the current durations.
• Play Billing Library requires you to acknowledge purchases within three days or they are refunded; the sandbox enforces this too, which is a good way to find a missing acknowledgement.

Tests to run: each product with each test card, a cancellation from the Play Store subscriptions page followed by an app relaunch, a reinstall followed by restore, account hold and grace period if configured, and a purchase while the app is offline. Confirm Real-time developer notifications reach your backend.

RevenueCat and other entitlement services

If you use RevenueCat, the SDK wraps both stores and your entitlement logic moves to RevenueCat's servers. Its sandbox testing documentation explains that purchases made with sandbox or license tester accounts show up as sandbox transactions in the dashboard, separated from production data, and that the same App Store sandbox and Play license rules apply underneath.

The RevenueCat-specific things to test:

• Restore behavior. RevenueCat lets you configure what happens when a receipt already belongs to another app user: transfer to the new user, keep with the original, or share. Test the configuration you chose by purchasing as user A, logging out, logging in as user B and restoring.
• Identity. Anonymous app user IDs that get aliased to a real account after login. Buy anonymously, then sign in, and confirm the entitlement follows.
• Webhooks. Each event type, initial purchase, renewal, cancellation, billing issue, expiration, delivered to your backend from sandbox events.
• Offerings and paywalls. Products in each offering load on both platforms, and the paywall shows the right prices for the device's storefront.

Restore purchases: the test everyone skips

Both stores require a restore mechanism for non-consumables and subscriptions, and both review teams check for it. It is also the most common purchase bug in beta reports, because it is a feature most developers never use themselves.

The minimum restore test matrix:

1. Buy, delete the app, reinstall, restore. Entitlement returns, no second charge.
2. Buy on device A, install on device B with the same store account, restore.
3. Restore with no previous purchase. The app should say so, not spin forever or claim success.
4. Restore while offline. A clear error, not a crash.
5. Restore after the subscription has expired. The app should not re-unlock.

The checks that have nothing to do with money

Purchase flows fail for ordinary UI reasons too, and these are worth including in every round:

• The paywall at the largest text size; prices and periods must remain readable.
• The paywall in a storefront with long currency formats, which the sandbox lets you switch.
• Double-tapping the buy button; one purchase, one entitlement.
• Backgrounding during the payment sheet and returning.
• Subscription management: the "Manage subscription" link opens the store's subscription page, not a web page.
• Terms, price per period, trial length and renewal disclosure on the paywall, which both stores require and which review reads.

Our payment flow testing guide covers the equivalent list for web checkouts.

Mistakes that cost real money

• Testing with a production build installed from the store instead of a testing track. This is how developers charge themselves.
• Leaving a backend in sandbox-verification mode at launch, so real receipts fail validation.
• Not handling the App Store's sandbox-receipt-in-production case, where Apple's reviewer tests your production build against the sandbox. Apple documents that you should retry verification against the sandbox when the production endpoint returns the corresponding status.
• Forgetting to acknowledge Play purchases, so every real purchase is refunded three days later.
• Shipping with a RevenueCat or store product ID typo that only appears for one platform.

Related guides

• In-app purchase testing with StoreKit and Play Billing sandboxes
• Sign in with Apple: when it is required and how to test it
• App Store rejection reasons and how to avoid them

Automating the purchase regression

Every build that touches the paywall, the entitlement check or a store SDK update deserves the same run: buy each product with a test account, restore after reinstall, cancel and check the state, open the paywall at large text, double-tap the buy button. That is tedious to repeat by hand and easy to skip.

betatest.ing runs these flows on real devices and emulators as part of its mobile beta tests. You provide the sandbox or license tester credentials and the goals, for example "purchase the monthly plan with the always-approves card, reinstall, restore, confirm the Pro screen is unlocked", and the AI beta tester works through them, filing each problem with steps, severity, annotated screenshots and a recording. Its Store readiness category also checks the paywall disclosures and the presence of a working restore, two of the items store review looks for. The test case generator can turn the matrices above into a shareable test case list.

Start for $1 and run your purchase and restore flows in sandbox on real phones today.

Related guides

Each ends with a test task you can send to your AI beta tester.

• Payment flow testing in test mode
• Mobile app beta testing for Android and iOS
• Test case generator

All beta testing guides

Keep reading

• AI mobile app testing: what an AI beta tester can and can't do on a phone — An AI beta tester on a phone sees the accessibility tree and the screen, taps, types, reads crash logs and records everything. It cannot be a real camera, notification or wallet. Here is the line.
• Beta testing a React Native or Flutter app: platform bugs you only find on a device — Cross-platform frameworks share your logic, not your bugs. The failures that slip past a simulator and show up on a tester's phone: keyboards, safe areas, back gestures, font scaling and native modules.
• Checkout and payment flow testing in test mode: a safe walkthrough — Payment bugs are the most expensive bugs you can ship. How to test the whole checkout in test mode: declines, authentication challenges, webhooks and the paths that double-charge or never upgrade.

All articles

Sources

• StoreKit Testing in Xcode
• sandbox testing guide
• license testing
• test subscriptions documentation
• sandbox testing documentation