Your app's free features work perfectly. Testers love it. You apply for production access, launch — and the first real user who tries to buy something hits a broken paywall.
In-app purchases are the part of an app most developers test last, and the part most likely to fail in production. The purchase flow touches Play Billing, license checks, account states, and server-side verification all at once. If you only test it with your own account on your own phone, you are testing the one setup most likely to work.
Closed testing is the time to break your payment flow safely, while the people hitting the errors are testers — not paying customers.
Why purchases deserve their own test plan
A free feature either works or it doesn't, and a tester can see the result immediately. A purchase can fail in ways that look like success: the payment goes through but the item never unlocks, the subscription renews but the app still shows the free tier, or the purchase works once and then disappears after a reinstall.
These are the bugs that cost real money and real reviews. And they are almost impossible to catch by tapping through the app yourself, because your own account is usually a license tester account, on a device you control, with a payment method you set up years ago.
Real testers bring the variety your payment flow needs: different devices, different Android versions, different Google accounts, and different levels of patience with a checkout screen.
Set up license testers before the test starts
Google Play lets you add license testers in Play Console. These are Google accounts that can make test purchases without being charged. Every closed tester who will touch the purchase flow needs to be on that list before day one.
- Add the testers' real Google accounts, not a shared test account. A shared account hides the account-specific bugs — the ones where a purchase works for one person and fails for another.
- Use the "License testers" list in Play Console, not just the closed track list. Being on the closed track lets someone install the app. Being a license tester lets them buy things for free. You need both.
- Decide what each tester can buy. License testers can be set to always approve purchases, always decline them, or behave like a real buyer. For a realistic test, most testers should behave like real buyers — and one or two should be set to decline, so you can test what happens when a payment fails.
This setup takes ten minutes. Skipping it costs you the entire purchase test, because testers either cannot buy anything or get charged real money trying.
What to ask testers to actually buy
"Try the premium upgrade" is too vague. Give testers a short list of specific purchase scenarios, one per phase of the test:
- Days 1–3: the happy path. Buy the cheapest one-time item. Does it unlock immediately? Does it survive closing and reopening the app? Does it survive a reinstall? If the purchase vanishes after a reinstall, your restore logic is broken — and that is the single most common in-app purchase bug.
- Days 4–7: subscriptions. Start a free trial or a monthly subscription. Cancel it, then check whether the app still grants premium access until the trial ends — and revokes it after. A subscription that never expires after cancellation is a bug your finance team will discover the expensive way.
- Days 8–10: the failure cases. Ask a tester to decline a payment, to lose network mid-checkout, and to try buying the same item twice. A good purchase flow handles all three gracefully. A bad one charges twice, crashes, or leaves the user stuck on a loading spinner.
- Days 11–14: the restore check. Ask every tester to uninstall and reinstall the app, then restore purchases. If anything is missing, fix it before production — because this is exactly what a real user does after switching phones.
Each scenario takes a tester a few minutes. Together they cover the purchase bugs that sink launches.
The bugs testers find that you won't
Your own testing catches the obvious failures. Real testers catch the ones tied to real-world conditions:
- A purchase that works on Wi-Fi and fails on mobile data. Slow or interrupted connections during checkout are common, and your app's error handling for them is probably untested.
- A paywall that renders wrong on a small or old phone. A buy button hidden below the fold on a budget device means lost sales you will never hear about.
- A subscription price that displays in the wrong currency. Testers in different regions see different prices. If your price formatting assumes one currency, some of them will see something confusing — or wrong.
- A purchase that unlocks on one device but not another. A tester who buys on their phone and opens the app on their tablet expects the purchase to follow them. If your app ties purchases to a device instead of an account, they will think they were scammed.
None of these show up in an emulator. All of them show up in a 14-day test with real people — if you ask testers to look for them.
Keep a purchase test log
Purchases are the one area where "it worked for me" is not evidence. Keep a simple log for every test purchase:
- Tester, date, what they bought, what happened, and what device and account they used.
- Whether the item unlocked, survived a restart, survived a reinstall, and restored correctly.
- Any error message, exactly as shown — screenshots help, because payment error messages are often the only clue to what went wrong.
When the production access review asks what you tested, this log is your answer for the part of the app that handles money. It also protects you after launch: if a real user reports a payment problem, you can check whether a tester already hit it and what you did about it.
Test the money before real money is involved
A broken free feature is an annoyance. A broken purchase is a refund, a one-star review, and a user who will never trust your paywall again. The first purchase a real user makes is the moment your app has to work perfectly — there is no second chance for a payment that fails.
That is why closed testing should include a real purchase test, with real testers, real accounts, and real failure cases. It is the cheapest insurance your launch will ever have.
The part no tool does for you
Play Console gives you the track, the license tester list, and the billing reports. What it does not do is find you 12 real people with Android phones and different Google accounts, keep them installed and engaged for 14 continuous days, have them test your purchase flow, and replace the ones who go quiet.
That is exactly what VerifiedTesters handles: 12 real testers on their own Android phones, opted in on your Play Console closed track and engaged for 14 continuous days, with free dropout replacement and a final report built for the production access form.
Test the purchases. Fix the paywall. Launch with confidence.
