Best Tools for Testing In-App Purchases and Subscriptions in 2026
Sandbox accounts, receipt validation and subscription state compared, plus which tools drive the purchase sheet itself rather than only the backend behind it.
- Read time
- 16 min read
- Published
TL;DR
- Autosana automates the purchase flow end to end through RevenueCat Test Store on virtual devices.
- StoreKit Testing in Xcode runs purchases locally with no App Store connection at all.
- Apple sandbox is the only place to verify real App Store behaviour before release.
- Google Play licence testers unblock billing on sideloaded debug builds with test payment methods.
- RevenueCat is free to $2,500 monthly tracked revenue and provides the Test Store.
- Adapty is free under $5,000 a month and leads on paywall A/B testing.
Search for in-app purchase tools and you get monetisation platforms. Search for in-app purchase testing and the field is almost empty, which is strange given that this is the one flow where a defect costs money on every single occurrence.
The gap exists because the purchase sheet is not yours. It belongs to Apple or Google, it refuses to appear in most automation contexts, and the usual outcome is a team that automates everything up to the paywall and then tests the actual transaction by hand, once, before each release.
Developers are vocal about how awkward it is. A r/iOSProgramming thread simply titled "Testing in app purchases. I'm confused. Help needed!" drew 24 comments, and a r/androiddev thread on testing purchases for an arbitrary country, at 5 votes and 22 comments, is the same frustration with a geography attached.
Why are in-app purchases so hard to test?
Four problems stack up, and no single tool solves all four.
The sheet is not your UI. The purchase dialog is rendered by the operating system. Automation frameworks that drive your app cannot reliably drive it.
State is sticky. Once a test account owns a subscription it owns it, and a first-purchase test needs a clean account or a reset, which is slow and manual.
Sandboxes behave differently from production. Renewal timing is accelerated, receipts differ, and some failures only exist in one environment.
Failure paths are the valuable ones. A declined card, a cancelled dialog, a restore on a new device, a lapsed subscription. These are where revenue leaks, and they are the hardest to produce deliberately.
Payment flows are where teams most want automation and least often get it. A r/QualityAssurance post on finally automating a checkout flow without touching a CSS selector, at 7 votes and 7 comments, reads like a small victory because it usually is one.
Worth holding onto: testing that the purchase succeeds is the easy half, and the half that never loses you money.
| Tool | Drives the Purchase UI | Real Store Behaviour | Cost |
|---|---|---|---|
| Autosana, RevenueCat Test Store | Yes, automated | No, test modal | Per agent-run |
| StoreKit Testing in Xcode | Yes, in simulator | No, fully local | Free with Xcode |
| Apple sandbox | Manually | Yes | Free, Apple account |
| Google Play licence testers | Manually | Yes | Free, Play account |
| RevenueCat | Via Test Store | Both, by configuration | Free to $2,500 MTR |
| Adapty | No, paywall layer | Via store integration | Free under $5,000 a month |
Which purchase testing tool belongs at which stage?
These are stages rather than competitors. Local testing comes first because it needs nothing configured. Automated flow testing comes next, because it is the only part that can run on every build. Store sandboxes come last, because they are slow, manual and the only place that proves the real thing works. A team that skips the middle stage ends up with the whole purchase path covered once a release, by hand.
1. Autosana: Best for Automating the Purchase Flow on Every Build
Autosana goes first because it is the only option here that puts the purchase path into an automated suite rather than a pre-release checklist. The in-app purchase guide describes using RevenueCat Test Store to automate purchase flows without an App Store or Google Play test account.
The mechanism is what makes automation possible. RevenueCat Test Store replaces the native store purchase sheet with a test modal, and Autosana selects a successful, failed or cancelled outcome and then verifies how the app responds. That turns the four scenarios worth testing into four ordinary flows: paywall navigation and product selection, a successful purchase unlocking the entitlement, a failed or cancelled purchase leaving it locked, and entitlement state surviving an app restart.
The flows read as plain instructions. Navigate to the paywall, choose the monthly plan, choose the failed purchase option in the RevenueCat Test Store dialog, verify the app shows an error and remains usable, verify the premium feature is still locked. Results are confirmed in RevenueCat by enabling sandbox data and checking the App User ID and entitlement.
Now the constraints, because they decide whether this fits. The default route runs on virtual devices and uses RevenueCat Test Store, not the real Apple or Google purchase sheet. You need a standalone development build using a test_ key, and the docs carry an explicit warning never to ship a build configured with that key. Native StoreKit or Google Play Billing testing is possible on AWS Device Farm private devices, but the docs state plainly that it requires an enterprise contract and coordinated onboarding, and that selecting Real device in a standard run does not configure it.
Autosana's own documentation also points past itself here, noting that RevenueCat recommends completing final purchase validation through the Apple or Google platform sandboxes. Treat this as the tool that covers the flow on every build, with sections 3 and 4 covering the store itself before release.
Good for: the purchase path in an automated suite rather than a manual checklist, failed and cancelled outcomes produced on demand, entitlement persistence across restarts, and no store test account to manage.
Poor for: real Apple or Google purchase sheets on a standard run, which need an enterprise contract and private devices. The default path is virtual devices and a test modal.
Cost: per agent-run, published on the Autosana pricing page.
Pick when: you want purchase regressions caught on every build instead of discovered during release testing.
2. StoreKit Testing in Xcode: Best Free Local Starting Point
Apple's StoreKit Testing in Xcode is a local test environment for in-app purchases that requires no connection to App Store servers. Products are defined in a StoreKit configuration file in your project, or synced from your App Store Connect settings, and the test environment uses that local data whenever your app calls StoreKit.
Apple names three cases where it is the right choice: developing purchase features before configuring anything in App Store Connect, testing when no network connection is available, and debugging cases that are harder to set up in sandbox, such as eligibility for promotional offers.
Crucially for anyone building a suite, Apple states that the full functionality of StoreKit Testing in Xcode is available for automation through StoreKit Test.
The limit is in the name. It is local, which means it proves your code handles the responses correctly and proves nothing about whether the App Store will send those responses.
Good for: zero-setup local testing, works offline, available for automation, and excellent for promotional offer eligibility that sandbox makes painful.
Poor for: anything about real store behaviour, since no App Store server is involved, and it is iOS only.
Cost: free, included with Xcode.
Pick when: you are building or debugging purchase code and want the fastest possible loop.
3. Apple Sandbox: Best for Proving Real App Store Behaviour on iOS
Apple's sandbox is where you test StoreKit on devices against real product information from App Store Connect. Apple's own description is precise: transactions from test accounts incur no charges because the sandbox simulates successful transactions using App Store infrastructure without processing actual payments.
The controls are better than most teams realise. Signing in with a Sandbox Apple Account on the device unlocks settings that change the subscription renewal rate, clear purchase history and simulate win-back offers, which is how you produce the lifecycle scenarios that matter. Sandbox Apple Accounts are created in App Store Connect.
It is also where most of the pain reports come from. A r/iOSProgramming thread on purchase history cleanup failing in sandbox, at 4 votes and 6 comments, and another on testing subscriptions with a sandbox account are typical of how much of this remains manual.
Good for: the only environment that proves real App Store behaviour pre-release, accelerated renewal rates, purchase history clearing, and win-back offer simulation.
Poor for: automation. It is a manual, device-bound, account-bound workflow, and account state management is the recurring complaint.
Cost: free with an Apple Developer account.
Pick when: you are about to ship and need the real store path verified by a human.
4. Google Play Licence Testers: Best for Unblocking Android Billing in Development
Google's billing test guidance recommends licence testers alongside Play Billing Lab, and the single most useful thing they do is remove a blocker most Android teams hit on day one.
Ordinarily the Play Billing Library is blocked for apps that are not signed and uploaded to Google Play. Licence testers bypass that check, so you can sideload a debug build with a debug signature and still exercise billing, provided the package name matches the configured app and the account is a licence tester on the Play Console account.
They also get test payment methods that avoid real charges and can simulate situations such as a declined payment, and they can test subscription features rapidly rather than waiting out real renewal periods.
Android has its own geography problem that none of this solves cleanly, visible in a r/androiddev thread on testing purchases for an arbitrary country at 22 comments, and the broader platform comparison in a r/androiddev thread on bypassing in-app purchases across Android and iOS, at 45 votes and 11 comments.
Good for: sideloaded debug builds exercising real billing, test payment methods including declined payments, and rapid subscription testing.
Poor for: automation, and configuration mistakes between package names, signing and tester accounts are the usual time sink.
Cost: free with a Google Play Console account.
Pick when: you are developing Android billing and need real Play behaviour before upload.
5. RevenueCat: Best Subscription Backend With a Testing Story Attached
RevenueCat is a monetisation platform rather than a testing tool, and it belongs here because it supplies the Test Store that makes section 1 possible. Pricing is published and unusually clear: nothing to pay up to $2,500 in monthly tracked revenue, then 1% of what you track above that.
For testing specifically, two things matter. Test Store gives a purchase dialog that automation can actually drive, and the dashboard lets you inspect results by enabling sandbox data, confirming the App User ID, the entitlement granted and whether webhook events fired.
The practical caution is configuration drift. The Autosana docs list the failure modes worth knowing in advance: empty offerings when products are not attached to a package, a native store sheet appearing because the build initialised with an Apple or Google key instead of the test_ key, and a test starting with an entitlement already granted because the App User ID was reused.
Good for: published percentage pricing with a real free band, a Test Store purpose-built for automation, and sandbox inspection by App User ID and entitlement.
Poor for: being a testing product in its own right. It is a billing backend, and its own guidance still sends you to Apple and Google sandboxes for final validation.
Cost: free to $2,500 monthly tracked revenue, then 1% of tracked revenue.
Pick when: you want one layer handling entitlements across both stores and a path to automating the flow.
6. Adapty: Best for Testing the Paywall Rather Than the Purchase
Adapty answers a different question. Its free band runs while you earn under $5,000 a month, moving to 1% of monthly revenue above that, and its strength is paywall A/B testing: changing products, titles, calls to action, images and video without shipping a new build.
That is testing in the experimental sense rather than the QA sense, and the distinction is worth keeping clear. Adapty tells you which paywall converts better. It does not tell you that your restore-purchase path is broken.
Include it when the question is commercial rather than functional. Most teams need a functional purchase test and a paywall experiment, and conflating the two leaves one of them unowned.
Good for: paywall A/B testing without a release, a free band up to $5,000 a month, and published percentage pricing above it.
Poor for: functional purchase testing. It does not drive the store sheet or verify entitlement edge cases.
Cost: free under $5,000 a month, then 1% of monthly revenue.
Pick when: the paywall is converting badly and you want to iterate without shipping builds.
Which approach fits your situation?
You are writing the purchase code now. StoreKit Testing in Xcode, for the fastest loop and no configuration.
You want purchase regressions caught on every build. Autosana with RevenueCat Test Store, accepting that it runs on virtual devices against a test modal.
You are shipping next week. Apple sandbox on iOS and licence testers on Android, by hand, including restore and cancellation.
Android billing is blocked on your debug build. Licence testers, which exist precisely to unblock it.
You need entitlements consistent across both stores. RevenueCat, free to $2,500 monthly tracked revenue.
The paywall converts badly. Adapty, and keep it separate from your functional purchase tests.
Test the paths that lose money, not the one that makes it. A declined payment, a cancelled dialog, a restore on a fresh device, a lapsed subscription still granting access, and a duplicate purchase. The happy path is the one scenario that cannot cost you revenue, and it is usually the only one covered.
Conclusion
The common shape is a suite that automates everything up to the paywall and stops, with the transaction itself checked manually once per release by whoever has the sandbox account configured.
That is not a tooling limitation any more. The purchase flow can sit in an automated suite through a test store, and the real store path still needs a human before release. Running both is the arrangement that works, and the mistake is treating either one as sufficient on its own.
Frequently asked questions
Can in-app purchases be automated in tests?
The flow can, through a test store that replaces the native purchase sheet with one automation can drive. The real Apple or Google sheet is rendered by the operating system and remains largely manual, which is why most teams run an automated test-store suite plus a manual sandbox pass before release.
What is the difference between StoreKit Testing and the Apple sandbox?
StoreKit Testing in Xcode is local and needs no App Store connection, using products defined in a configuration file, so it proves your code handles responses correctly. Sandbox runs on devices against real product information from App Store Connect and simulates transactions on App Store infrastructure, so it proves the store path works.
How do you test a failed or cancelled purchase?
Deliberately, through a tool that lets you select the outcome. RevenueCat Test Store exposes successful, failed and cancelled options that automation can choose. On Android, licence testers get test payment methods that can simulate a declined payment. Those paths are where revenue leaks, and they are rarely covered.
Does Autosana test real App Store purchases?
Not on a standard run. The documented default is RevenueCat Test Store on virtual devices, which replaces the native sheet with a test modal. Native StoreKit and Google Play Billing testing runs on private devices and the docs state it requires an enterprise contract and coordinated onboarding.
How much do in-app purchase tools cost?
The testing layers are free: StoreKit Testing comes with Xcode, Apple sandbox with a developer account, and Play licence testers with a Console account. The monetisation layers charge on revenue, with RevenueCat free to $2,500 monthly tracked revenue and Adapty free under $5,000 a month, both at 1% above.