Testing In-App Purchases and Ads During a Google Play Closed Test

If your app sells something or shows ads, your closed test needs a plan for both. Without one, testers either skip the monetization flows (so bugs go unnoticed) or hit them in ways that cost real money or cause policy trouble. This post covers how to set up purchase testing and ad testing so your 14 days teach you something.

Rules and menus in Play Console and AdMob change. Treat the steps below as a general outline and check Play Console Help and your ad network's policies for the current details.

Why monetization needs its own test plan

Purchase and ad code is the part of an app most likely to behave differently outside your own phone. It depends on the Play Store app, the tester's account, their country, their network, and a third-party SDK. A crash in a paywall or a stuck loading spinner after a purchase is the kind of problem testers find, but only if they can reach it safely.

There are two risks to manage:

• Purchases: testers being charged real money, or being unable to complete a purchase at all.
• Ads: testers tapping live ads, which ad networks can treat as invalid activity on your account.

Testing in-app purchases

1. Get the basics in place first

Before anyone can test a purchase, a few things usually need to be true. Check each against current Play Console Help:

• The build you uploaded to the closed track includes the Google Play Billing Library and the billing permission.
• Your in-app products or subscriptions are created in Play Console and set to active.
• Your app is on a testing track, and the testing account installed it through the opt-in link, not as a sideloaded APK.

If a tester sees an empty product list, one of these is the first thing to check. The next most common cause is that the tester installed a different build than the one your products were configured against.

2. Use license testers for yourself

Play Console has a license testing setting where you list email addresses of accounts that can make test purchases. Purchases by those accounts go through the normal purchase flow but are not charged. The setting also lets you pick test responses, such as a test card that always approves or one that always declines, so you can check both success and failure paths.

Note that license testing is an account-level setting, not per app. Only add accounts you actually want to behave that way.

3. Decide what to do about outside testers

This is the part most guides skip. People you recruit for your closed test are not license testers unless you add them. If you do not, a purchase attempt may charge their real payment method.

You have three reasonable options:

1. Add willing testers to license testing. This works if you know their Google account emails and they agree. Remember it applies account-wide, so it is best for a small group.
2. Hide or disable purchase buttons in the closed test build. Testers cover everything else, and you test billing yourself with your own license-tester accounts.
3. Tell testers clearly not to complete any purchase. They can open the paywall, read it, and report layout or wording problems, then close it.

Whichever you choose, write it in your tester instructions. Never leave testers guessing whether a button will charge them. When you use TesterMob, the testers use their own Android phones and give written feedback, so a sentence like "Open the paywall and tell us if anything looks broken. Do not buy anything" is the kind of instruction they can follow cleanly.

4. Test the awkward purchase paths

Your own license-tester accounts should cover more than the happy path:

• A purchase that is declined.
• Cancelling halfway through the dialog.
• Killing the app right after paying, then reopening it. Does the purchase still unlock?
• Restoring purchases on a second device or after reinstall.
• Going offline or switching networks mid-purchase.

For subscriptions, test subscriptions renew on an accelerated schedule, so you can watch renewal and cancellation behavior without waiting weeks. Check the Play Console documentation for how that works currently.

Testing ads

Never tap your own live ads

Ad networks generally prohibit publishers from clicking their own live ads, and that extends to asking friends or testers to do it. Invalid clicks can lead to limited or disabled ad serving. So the rule for your closed test is simple: nobody taps live ads on purpose.

Two sensible approaches

• Use test ads in the closed test build. Most ad SDKs provide test ad units or let you register test devices. Testers see realistic placeholder ads, and tapping them is harmless. The downside is that you are not seeing real ad fill or real creative.
• Use live ad units, but tell testers not to tap ads. You see real placement and load behavior, but you rely on testers following the instruction. This carries more risk, so many developers prefer the first approach for the closed test.

Check your ad network's current policy before choosing. If you are unsure, the test ad route is the safer one.

What testers can still check

Even without tapping, testers can report useful things about ads:

• Does an ad cover a button or navigation element?
• Does a full-screen ad appear at an annoying moment, such as right after launch?
• Does the app freeze or lag while an ad loads?
• Can they close the ad, and does the app resume where they left off?
• Does the app behave when there is no connection and no ad to show?

Write monetization into your tester instructions

A short block in your testing notes goes a long way. Here is a template you can adapt:

Purchases: please open the upgrade screen and check the text and layout. Do not complete a purchase. Ads: you may see test ads. Please do not tap them. Tell us if an ad blocks a button, appears at a bad time, or slows the app down.

Keep it separate from the rest of your instructions so it does not get lost. If you are weighing how to collect and structure the rest of the feedback, the FAQ covers how the testing process works on TesterMob.

Do not let monetization hide a broken app

One caution: closed testing is mostly about showing that real people used a working app over 14 days. If an aggressive ad or a confusing paywall blocks testers from reaching the rest of the app, you lose most of the value of the test. Consider a gentler setup for the test build, such as fewer interstitials and no paywall before the core features. You can bring the full monetization back once you are in production.

A quick checklist

1. Billing library and products set up, products active.
2. Your own accounts added to license testing; you test failure and restore paths yourself.
3. A decision made for outside testers: license testing, hidden purchases, or "look but do not buy".
4. Test ads, or a clear "do not tap" rule if using live ads.
5. Monetization notes written into tester instructions.
6. Core features reachable without hitting a paywall or ad wall.

Where to go from here

Monetization testing is one part of a bigger preparation process. If you are still setting up your test, the developer page explains how TesterMob works, and the pricing page has the current one-time per-app cost. As always, TesterMob cannot guarantee production approval, and Google's requirements can change, so check Play Console Help for the latest rules before you submit.