You test a purchase long before anyone approves it, and each store blocks you somewhere else.

Can you test a purchase before Apple approves the product?

Yes, and Apple documents it as the normal order of work rather than a loophole. The page on testing purchases with sandbox lists five things to have ready before you start. Your Apple Developer Program account is active. Your membership Account Holder has signed the paid applications agreement. The product information is set up in App Store Connect, which Apple reduces to a minimum of a product reference name, a product ID, a localized name and a price. You have created Sandbox Apple Accounts. And you have enabled Developer Mode on the device if you are running a development-signed build. A review status appears nowhere on that list.

I went looking for the gate anyway, because a lot of writing on this subject implies one. App Store Connect Help has a reference page listing the In-App Purchase statuses, from Prepare for Submission through Ready for Review, Waiting for Review, In Review, Accepted and Approved. It explains what you can still edit in each state, and it says nothing about the sandbox. The configuring overview puts the steps in a numbered workflow, and testing your purchases is step five while submitting them for review is step seven. So the documentation agrees with the thing developers say to each other: you test first, you submit after. Read on 21 October 2026.

One requirement does bite, and it is the agreement rather than the review. App Store Connect Help states that the paid apps agreement must be Active to test In-App Purchases in the sandbox environment, and that means the Account Holder has to have accepted it and supplied banking and tax information. That is paperwork with a human on the other end, so it is the thing to start days before you need it, not the afternoon you planned to test.

There is also a rung below the sandbox. App Store Connect Help describes StoreKit Testing in Xcode as a local test environment that does not require a connection to App Store servers, and says to use it to test purchases before you configure them in App Store Connect, or when there is no network. That is worth knowing on day one: you can write and exercise the whole purchase path with a local configuration file and no store account at all, then move to the sandbox when the real product IDs exist.

Apple, testing Apple In-App Purchases with sandbox, read 21 October 2026

Does Google Play make you publish to a track first?

Google's two own pages give two different answers, and knowing which one applies to you saves a wasted release. Play Console Help, on testing in-app billing with application licensing, lists it as a requirement: your app has been published to the open, closed, internal test or production track, and it recommends the internal test track. The Android Developers page on testing your Billing Library integration says something narrower. The Billing Library is ordinarily blocked for apps that are not signed and uploaded to Google Play, license testers bypass that check, and so a license tester can sideload an app for testing, including a debug build with a debug signature. Two conditions come with it. The package name must match the app configured for Google Play, and the Google Account must be a license tester for the Play Console account.

Put together, the answer is: the app record and its products have to exist on Google Play, but the specific build in your hand does not have to be the one sitting on a track. Both pages agree that the products must be published before they can be tested, which is the part people skip. Creating a subscription in Play Console is not the same as publishing it. Read on 21 October 2026, on a page that prints its own last updated date of 20 October 2026.

Becoming a license tester takes a minute. In Play Console, open Settings and then License testing, and add people as email lists or as Google Groups. Play Console Help says an email list holds up to 2,000 addresses and that Google Groups have no user limit, and that your own publishing account is always considered a licensed tester. That last line explains a common confusion: your own first test purchase often works before you configure anything, and then a colleague's does not. Google also advises testing with non-license-tester accounts from time to time, so that your app does not come to depend on testing-specific behaviour like five minute renewals.

Tracks still earn their place, just for a different job. Google describes test tracks as pre-distribution validation, the way a QA team qualifies a release, and warns that after you publish to a testing track it can take a few hours before the app is available to testers. Plan that lag into the day. When your testers are outside your own company, the track you want next is a closed one, and google play closed testing covers the tester lists and opt-in links that go with it.

Google, test your Google Play Billing Library integration, last updated 20 October 2026, read 21 October 2026

What does a test purchase do that a real one does not?

It runs through the same flow and then lies about time. Apple describes the sandbox as using the infrastructure of the App Store and returning transactions as if payments were successfully processed, instead of processing actual payments. Google says test purchases use the same app purchase flow as actual purchases, that taxes are not computed, and that Play shows a notice across the centre of the purchase dialog so you can tell. Neither store is running a mock. They are running the real thing with the money part swapped out, which is why these environments are worth using and also why they surprise people.

The compression is the useful part. Apple sets a per account subscription renewal rate, defaulting to a speed equalisation of one month to five minutes, and that rate also sets the length of billing retry and the billing grace period for that tester. Subscriptions renew up to 12 times before auto-renewal turns off on the thirteenth attempt. Google's equivalent table is fixed: one week and one month both become five minutes, three months becomes ten, six months fifteen, a year thirty. A free trial becomes three minutes, a grace period five, an account hold ten, and a test subscription renews a maximum of six times, not counting free trials and introductory periods. If your renewal logic needs more cycles than that, you will need a fresh account rather than more patience. All read on 21 October 2026.

Both stores give you failure on demand, and this is where most of the value sits. Apple has an interrupted purchases switch per sandbox account, which simulates a customer who has to act outside your app first, such as agreeing to new terms or replacing an expired card. Google hands license testers a set of test instruments: always approves, always declines, a slow test card that approves after a few minutes, a slow one that declines, and one that approves and then charges back. Google adds a rule with teeth attached: for purchases from license testers, a purchase is refunded after 3 minutes if your app does not acknowledge it, and you get an email about the cancellation. That is a three minute test for a bug that would otherwise reach production as a wave of chargebacks.

Your server can join in. Apple makes the App Store Server API and App Store Server Notifications available in the sandbox on their own sandbox URLs, with the environment named in the notification payload, so the webhook you will depend on in production is testable now. Both sandboxes also run on builds your testers can hold, which matters for sequencing. Apple states that apps downloaded from TestFlight always run in the sandbox environment, so a beta tester cannot be charged by accident. Getting a build in front of people outside your team is its own queue, and testflight external testing review is the step that governs it.

Which mistakes here cost a whole day?

The expensive one is on Google Play, and it is about money. Google states that users incur actual charges for their test track purchases unless the user is a license tester, and that draft apps and internal test track releases are subject to spend limits. It names no figure for those limits. So an internal testing build is not a safe sandbox by itself. Somebody who installed from your opt-in link and never made it onto the license testing list will be charged for the subscription they bought to help you. Add the list before you share the link, not after.

The second one is on iOS, and it bites you rather than a tester. To reach the sandbox controls from a TestFlight build, Apple has you sign out of your production Apple Account in Media and Purchases and sign in with a Sandbox Apple Account under Settings, then Developer. Apple attaches a warning to that step: signing out of Media and Purchases can remove your access to purchased content in production apps on your device, and it suggests a dedicated testing device. Sign back in later and your TestFlight purchases go back to being attributed to your real account. If you only have one phone, do this knowing what it costs.

Then a run of small ones that each look like a code bug. A sandbox account only works for apps belonging to the same Apple Developer Program account that created it, so a borrowed tester from another team fails silently. A product you just edited can take up to an hour to show up in the sandbox. A sandbox account email that is already a real Apple Account causes errors, which is why Apple documents using plus sign subaddresses off one mailbox instead. On Google Play, the resubscribe and pause features are always on for license tester accounts even when they are switched off in Play Console, so testing the disabled behaviour needs an ordinary account. And Play Billing Lab, the separate Android app that holds the country, trial offer and price change controls, expires several of those configurations after two hours.

One deadline is live as this is written. The reminder banner Google runs across its Play Billing documentation, read on 21 October 2026, says that by 31 August 2026 all new apps and updates to existing apps must use Billing Library version 8 or later, and that you can request an extension until 1 November 2026. The first date has already passed. If your project is on an older Billing Library, the version is now the thing to fix, because no amount of test instruments helps an update that will not be accepted.

Last, a boundary worth keeping. Testing the money is not testing the listing. A sandbox purchase tells you whether your code grants the right thing when the right event arrives, and it tells you nothing about whether anyone wants to buy it. That second question belongs to play store listing experiments and to real traffic. Keep the two apart and both get easier.