In-app purchase testing with StoreKit and Play Billing sandboxes

In-app purchases are the flow you can least afford to ship broken and the one teams test least, because nobody wants to pay real money on every build. This guide covers how the Apple and Google sandboxes work, which subscription states to test, and a task your AI beta tester can run against your paywall without ever completing a real purchase.

Who it’s for

  • iOS and Android developers adding subscriptions or one-time purchases
  • Teams using RevenueCat or another purchase SDK across both platforms
  • Founders preparing the first paid version of an app for store review
  • QA engineers building a regression pass for billing flows

Updated 2026-10-25.

What in-app purchase testing covers

In-app purchase (IAP) testing verifies that every path through your paywall works: buying, failing, cancelling, restoring, renewing, upgrading and refunding, on both stores, without real money changing hands. It also checks that your app unlocks exactly what was bought and locks it again when the purchase ends.

Billing bugs are expensive in both directions. A purchase that does not unlock content produces refunds and one-star reviews. A check that unlocks content too generously costs you revenue quietly. Both stores also review paywalls closely, so a sloppy purchase flow can block your release.

The iOS sandbox: StoreKit testing and sandbox accounts

Apple gives you two layers:

  • StoreKit Testing in Xcode uses a local .storekit configuration file. No network, no App Store Connect products needed, and you can trigger failures, interrupted purchases, refunds and renewals from the Xcode transaction manager. Use it during development.
  • Sandbox Apple Accounts are created in App Store Connect under Users and Access > Sandbox. On a device, sign in with the sandbox account in Settings > App Store > Sandbox Account, then make purchases in a development or TestFlight build. TestFlight builds use the sandbox environment automatically.

Sandbox subscriptions renew on an accelerated schedule: a one-month subscription renews after a few minutes, and renews a limited number of times before it expires. Apple publishes the exact table, so check it when planning a renewal test. Sandbox accounts also let you test Ask to Buy approvals, billing retry and grace period states, and clearing purchase history.

The Android sandbox: license testers and test cards

On Google Play, the test setup lives in the Play Console:

  • Add tester Gmail addresses under Setup > License testing. License testers see test payment methods at checkout, such as "Test card, always approves" and "Test card, always declines", plus options for slow or delayed payment.
  • The app must be uploaded to a testing track and the tester must be opted in, and the build's package name and signing key must match what the Play Billing Library expects.
  • Products and subscriptions must be active in the console before they appear in the app.
  • Test subscriptions renew on shortened cycles so you can watch renewal, grace period and expiry within a session.

Google requires apps to use a supported Play Billing Library version and retires old versions on a schedule, so check the current requirement before you ship.

RevenueCat and other purchase SDKs

Wrappers like RevenueCat sit on top of both stores, map products to entitlements, and detect sandbox purchases on their own. That simplifies the app logic, but it adds a third system to test: confirm the entitlement flips on in the dashboard after a sandbox purchase, that the app reads the entitlement rather than a cached flag, and that a restore on a second device maps to the same app user ID.

Subscription states to test

Most billing bugs hide in the states between "active" and "expired". Walk each one:

  1. Free trial starts, shows the correct end date, and converts or expires.
  2. Active unlocks exactly the entitled features, nothing more.
  3. Cancelled but still active keeps access until the period ends, then locks.
  4. Billing retry and grace period (payment failed): decide whether access continues, and make sure the app says what is happening.
  5. Expired locks content and offers resubscribe, without crashing on old cached data.
  6. Upgrade and downgrade between tiers apply the right proration behavior and unlock the new tier immediately where the store says they should.
  7. Refunded or revoked purchases lock content on next launch.
  8. Family Sharing or shared purchases, if enabled.

Paywall and store rules to check

Both stores check paywall copy. Confirm that:

  • Price, billing period and trial length are shown before the purchase sheet appears, and match the store's price.
  • Auto-renewal is explained and links to terms and privacy policy work.
  • There is a visible Restore Purchases action (Apple requires it for non-consumables and subscriptions).
  • Digital content and features are sold through the store's billing, not an external payment page, unless your app qualifies for an exception. Check the current App Store and Play policy text for your category and region.
  • Subscription management opens the store's management screen.

In-app purchase testing checklist

  • Purchase a consumable, non-consumable and subscription with a sandbox account or test card.
  • Cancel at the payment sheet and confirm nothing unlocks and no error is left on screen.
  • Use a declining test card and check the error message.
  • Kill the app mid-purchase and reopen: the pending transaction completes or is clearly recoverable.
  • Restore purchases on a fresh install and on a second device.
  • Let a test subscription renew, then let it expire, and check access at each step.
  • Go offline after a purchase and reopen the app: entitlements are cached sensibly.
  • Switch store accounts on the device and check the app does not show another user's purchases.

Example IAP bug report

Title: Restore Purchases does nothing after reinstall (iOS, sandbox)
Environment: iPhone 14, iOS 18.1, build 2.3.0 (310), sandbox Apple Account
Severity: Critical (paying users lose access after reinstalling)

Steps to reproduce:
1. Buy the yearly plan with the sandbox account; Pro features unlock.
2. Delete the app and reinstall the same build.
3. Open Settings > Restore Purchases.

Expected: Pro features unlock and a confirmation is shown.
Actual: A spinner shows for about one second, then nothing changes. No
message. Pro features stay locked. Repeating the tap has the same result.

Evidence: screen recording of steps 2-3.
Notes: Buying again shows "You're already subscribed" from the App Store
sheet, so the purchase exists; the app only fails to restore it.

Common in-app purchase bugs

  1. Restore Purchases missing or silently failing.
  2. Content unlocked on purchase start rather than on a verified transaction.
  3. Prices hardcoded in the paywall instead of read from the store, so they mismatch in other currencies.
  4. The app crashing on launch when a cached receipt is stale.
  5. Trials offered again to users who already used one.
  6. Entitlement not refreshed after returning from the payment sheet, so the user has to restart.

Testing in-app purchases with an AI beta tester

An AI beta tester like betatest.ing runs your uploaded build on a real iPhone, an iOS simulator or an Android emulator, opens the paywall and works through the purchase, cancel, decline and restore paths using the sandbox or license-tester setup you configure. It never completes a real purchase. For every problem it files a finding with steps to reproduce, severity, an annotated screenshot and a recording, and it scores store readiness in the final report. Renewal and expiry states that depend on waiting are best checked by your team with the sandbox clocks, and the AI pass covers the paywall and purchase paths on each new build.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test the in-app purchases in my app [UPLOADED BUILD OR PUBLIC STORE LINK]. It sells [WHAT IS SOLD, E.G. MONTHLY AND YEARLY PRO SUBSCRIPTION]. The build is set up for [SANDBOX SETUP, E.G. STOREKIT TESTING / SANDBOX APPLE ACCOUNT / PLAY LICENSE TESTER]; never attempt a real purchase. Sign in with the saved test login. Open the paywall from every entry point and check prices, billing period, trial terms, auto-renewal text and links to terms and privacy policy. Start a purchase and cancel at the payment sheet; nothing should unlock. Complete a sandbox purchase and confirm the right features unlock immediately without restarting. Check that Restore Purchases exists and works. Background the app during a purchase and come back. Go offline and reopen the app to check the entitlement is still honored. Log each issue as a finding with steps to reproduce and an annotated screenshot, record the purchase flow, and end with a report that scores paywall clarity, purchase flow, restore and store readiness with the top fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [UPLOADED BUILD OR PUBLIC STORE LINK] "the uploaded .ipa/.apk/.aab" or a public store link
  • [WHAT IS SOLD, E.G. MONTHLY AND YEARLY PRO SUBSCRIPTION] The products or subscription tiers in the app
  • [SANDBOX SETUP, E.G. STOREKIT TESTING / SANDBOX APPLE ACCOUNT / PLAY LICENSE TESTER] Which test billing setup the build uses

What the AI beta tester checks

  • Paywall copy: price, period, trial and auto-renewal terms
  • Links to terms of use and privacy policy from the paywall
  • Cancel at the payment sheet leaves nothing unlocked
  • Sandbox purchase unlocks the right features immediately
  • Restore Purchases is present and works
  • Backgrounding or interrupting a purchase in progress
  • Entitlement honored offline and after relaunch
  • Declined test payment shows a clear error
  • Subscription management opens the store screen

What you get

  • Findings for each billing bug with steps to reproduce and severity
  • Annotated screenshots of paywall and error states
  • Recordings of the purchase, cancel and restore flows
  • A report scoring paywall clarity, purchase flow, restore and store readiness

How to run it with betatest.ing

  1. Set up sandbox billing: StoreKit testing or a sandbox Apple Account on iOS, license testers on Google Play.
  2. Add your app as a project in betatest.ing, upload the build and add the test login.
  3. Send the in-app purchase test task and name the sandbox setup the build uses.
  4. Fix the findings, upload a new build and re-run before store submission.

Tips

  • Read prices from the store at runtime; never hardcode them in the paywall.
  • Unlock content only after the transaction is verified, and refresh entitlements when the payment sheet closes.
  • Test restore on a clean install and on a second device, not only in the same session.
  • Use the sandbox clocks to watch a renewal and an expiry before you ship.

In-app purchase testing: FAQ

How do I test in-app purchases without paying?

On iOS use StoreKit Testing in Xcode or a sandbox Apple Account created in App Store Connect; TestFlight builds use the sandbox automatically. On Android add license testers in the Play Console so they see test payment methods at checkout. Neither charges real money.

Why does my sandbox subscription expire so quickly?

Sandbox subscriptions renew on an accelerated schedule and renew a limited number of times before expiring, so you can test the whole lifecycle in minutes. Apple publishes the exact durations; Google test subscriptions also use shortened cycles.

Do I need a Restore Purchases button?

Yes for iOS: Apple requires a restore mechanism for non-consumables and subscriptions. On Android, Play Billing can query purchases on launch, but a visible restore action still helps users who switched devices or reinstalled.

Will the AI beta tester make a real purchase?

No. It only goes through purchase flows with the sandbox or license-tester setup you configure, and it never completes a real transaction.

Can it test subscription renewal and expiry?

It tests the paywall, purchase, cancel, decline and restore paths on each build. States that depend on waiting for the sandbox clock, such as renewal, grace period and expiry, are best checked by your team using the store's accelerated sandbox durations.

How do I test RevenueCat purchases?

Use the same store sandboxes; RevenueCat detects sandbox transactions on its own. Check that the entitlement appears in the RevenueCat dashboard after a test purchase, that your app reads the entitlement rather than a local flag, and that restore maps to the same app user ID.

Why are my products not showing up in the app?

Common causes: the product is not active in the store console, the build is not uploaded to a testing track or the tester is not opted in (Android), the bundle ID or signing key does not match, or paid agreements are not signed in App Store Connect.

Can I sell digital content outside the store's billing?

Both stores generally require their own billing for digital goods and features, with exceptions by category and region that have changed over time. Check the current App Store Review Guidelines and Google Play Payments policy for your case before you ship.

Related beta testing guides

  • Payment flow testing — A broken payment flow costs revenue every hour it stays broken. This page explains how to test checkout, upgrades and subscriptions safely in test mode, which cases to cover, and a ready task for your AI beta tester.
  • App Store rejection reasons — Most App Store rejections are not about taste. They cite a small set of guidelines: the app crashed, a login had no demo account, a purchase bypassed in-app purchase, a social login lacked Sign in with Apple, or there was no way to delete an account. This guide lists the common rejection reasons by guideline number, what reviewers actually check, and a review-readiness task your AI beta tester can run on the build before you press Submit.
  • Google Play rejection reasons — Google Play rejections tend to be about declarations more than design: a Data safety form that does not match what the app collects, a missing account deletion link, an undeclared sensitive permission or an outdated target API level. This guide lists the common rejection and removal reasons, what to fix for each, and a Play policy check your AI beta tester can run on the build before you submit it for review.
  • iOS app beta testing — TestFlight is how almost every iOS app gets into beta testers' hands before the App Store. This guide explains how TestFlight testing works, what to check on iPhone that differs from Android, and how to run an AI beta test on a real iPhone from an uploaded .ipa build.
  • Android app beta testing — Android beta testing means getting a test build onto many different phones and finding what breaks before the public release. Here is how Google Play testing tracks work, what to test that is specific to Android, and a task your AI beta tester can run from your uploaded build or Play link.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in by test type