Do Closed Testers Have to Pay for a Paid App?

The short answer: yes, and only the internal track is free

Short answer: in an open or closed test your testers pay for a paid app like any other customer. Google states it in one line: “Testers must purchase paid apps when participating in open or closed tests. For internal tests, testers can install paid apps for free.” There is no testers-only price, no track-level coupon, and no setting that makes twelve installs free while the listing stays paid.

That sentence has three consequences that people discover one at a time, usually after they have already recruited testers. The download is a normal Play purchase, charged to whichever Google account the tester used to install the app. The money is real unless you are on the internal track. And the 14-day requirement that gates production access does not look at any of it: Google’s rule is “a minimum of 12 testers who have been opted in continuously for at least 14 days”, with no condition about what they bought.

Read the levers in that order and most billing confusion during a closed test resolves itself. The download price is decided by the track. The in-app price is decided by the license testing list. They are separate mechanisms with separate pages in Play Console, and neither one substitutes for the other.

Why internal testers install free and closed testers do not

The internal test track exists to check that a build works before anyone is asked to pay for it. Google’s internal-test guidance says so directly: “For paid apps, testers can install your internal test version for free. Testers need to pay for in-app purchases unless you add them to a license testers list.”

Two limits make that free install a poor substitute for the closed test. The internal track holds up to 100 testers per app and, as its own name says, it does not sit on the production-access path. Testers who opted into internal testing “aren’t eligible for open and closed testing, even if included as testers on those tracks”, so a free internal install cannot be counted toward the twelve.

This is where a specific sentence gets repeated in support threads: a tester replies “I already have it installed”, because they do. They installed it during your internal test, for free. When you move to a closed track and they opt in there, the price applies to the new install, and the app will ask them to buy it. That is not a bug and it is not the tester losing access; it is the track changing.

If you are deciding where to spend your tester budget, remember that internal installs do not count toward the gate at all — internal app sharing and internal testing both fail that test. The internal track is where you debug the paywall. The closed track is where you pay for it.

You cannot set a price that only testers see

The instinct after reading the paid-app line is to look for a discount or a free period aimed at the test group. Google closes that door in the prerequisites on the same page: “Monetization changes: Changes to your app's pricing affect all versions across all tracks.”

Price is a property of the app, not of the track. There is no per-track price field, no promo code scoped to a tester list, and no way to charge the public while gifting the test group through Play Console. Whatever your app costs, it costs that on production, open testing, closed testing and pre-registration at the same moment.

For an app that is already live, that cuts both ways. Your closed testers pay the live price, which may be fine. But if you lower the price to be kind to testers, you have just lowered it for existing paying customers outside the test as well, and re-raising it after the window is a second visible price change to the same store listing.

For an app that has not reached production, the practical consequence is sequencing rather than permission: the price you set while testing is the price the listing carries, so decide it before you recruit, not after twelve people have installed.

The workaround people ask about next is publishing free for the test and pricing it at launch. That is a normal price change under Google’s rules, not a hidden tester-only mechanism, and it lands on every track at once. If the app is already live at a price, flipping to free for the window is a public price cut, not a test setting.

What license testing removes from the bill, and what it does not

License testing is the feature most developers reach for, and it is the one most often credited with more than it does. Google describes its scope precisely: “With application licensing, you can set up a list of Google Accounts (Gmail or Google Groups) to test your in-app billing and subscription integration.” The subject is in-app billing. The download is not part of it.

Once accounts are on that list, “authorized users can also purchase one-time products and subscriptions without charging their accounts.” The purchase dialog still runs, your app still receives a purchase object, and the tester’s payment method is untouched. On the Android side Google notes that test purchases “use the same app purchase flow used by actual purchases”, with a notice across the centre of the purchase dialog marking them.

The distinction to hold on to: license testing makes in-app purchases free. It does not make a paid app free to download. Nothing on the licensing page qualifies the paid-app rule for open and closed tests, so a license tester who has not bought your app still meets a buy button before they ever reach your first paywall.

Setup lives outside the app: Play Console, Manage account, Play apps settings, Monetization settings, License testing. You can use email lists of up to 2,000 addresses each, or a Google Group, in which case every member becomes a license tester. Two practical details belong in the same breath, because they are the two most common reasons a purchase sheet comes up empty: you “must publish your one-time products and subscriptions before they can be tested”, and a license tester’s purchase is refunded after three minutes if your app never acknowledges it.

The last line of the licensing page is the one that quietly invalidates a lot of self-testing: “your own publishing account is always considered a licensed tester.” You will never be charged, you will always see test payment instruments, and the purchase will always succeed if the code is roughly right. Your own checkout is therefore not evidence that a real buyer’s checkout works. To see that, watch a tester do it, on a recording, on a device you did not register.

What a 14-day test cannot tell you about billing

Test billing is compressed on purpose, and the compression is worth knowing before you write a launch decision on top of it. For a license tester, Google’s test table turns a one-week subscription into roughly five minutes, a one-month subscription into five minutes, three months into ten, six months into fifteen and a year into half an hour. Free trials run three minutes, grace periods five, account holds ten.

“Test subscriptions renew more quickly than actual subscriptions, and test subscriptions can renew a maximum of six times, not including free trials and introductory periods.” Six renewals is the ceiling. A fourteen-day window therefore exercises more subscription states than a real year would, and it cannot exercise the ones that depend on real elapsed time: annual renewal reminders, dunning emails timed in days, thirty-day retention prompts, anything that fires on a calendar boundary you compressed away.

Two further differences to keep out of your launch notes. Taxes “are not computed for test purchases”, so price display and tax behaviour during the test are not what production will show. And test purchases do not tell you anything about revenue: twelve paying testers is a signal that the paywall is reachable, not that the price is right — the install and audience numbers in Console need reading in that light, which is the same trap as installed audience versus DAU during a closed test.

One device-level detail explains a whole class of “I’m a tester but it is asking me to pay” reports. Google states that if a device has more than one account, “the purchase is made with the account that downloaded the app”, and if none of the accounts downloaded it, “the purchase is made with the first account”. A tester with a work profile and a personal account can be charged on the account that never joined your test, and no amount of re-inviting fixes that. Ask which account the Play Store was signed into at install time before you change anything.

If your app is paid, do it in this order

Based on our analysis of 1,500+ closed-testing campaigns, the price question usually surfaces late, in the first reply from a recruited tester: the app is asking me to pay. By then the list is built and the window is running, so the ordering below is worth settling before any of that happens.

The following is our recommended sequence, not a Google requirement. It exists because the price is app-wide and the counted window is not refundable — you cannot get fourteen days back because your testers spent them staring at a buy button.

1. Set the price before you recruit, and write it into the message you send testers. Twelve installs at $4.99 is about $60 in real money across your test group; nobody should discover that at the opt-in link.
2. Smoke-test the purchase flow on the internal track first. The install is free there, the track holds up to 100 testers, and a broken paywall costs you nothing but time — Google’s internal-test notes also point paid apps at a license testers list for in-app purchases.
3. Only then open the counted closed test, with testers who know what they are buying and why. Say plainly that Google’s pages do not describe a refund path for a closed tester, so treat the charge as real.
4. If the app is free with in-app purchases, add the same twelve accounts to license testing before you send the opt-in link. That converts their in-app purchases into test purchases without touching the download price.
5. Do not change the price mid-window. A price change applies to every track, including a live production listing, and a tester who installed before the change and one who installed after are now testing different propositions.
6. Publish your one-time products and subscriptions before the test starts. Unpublished products cannot be purchased, and the tester will report an empty billing sheet rather than an error you can search for.

If a tester declines to pay and opts out instead, the twelve-tester count is what matters, not the reason: dropping below twelve has its own clock consequences, and the safest reading is that any gap in continuity costs days. That is worth five minutes of honesty in the recruitment message.

The order also changes what the window is for. On a paid app, the closed test is mostly validating that the listing, the price and the install path work for people who are not you. It is a weak instrument for validating whether the price is right, and a very expensive one for finding a broken checkout.

Edge cases that catch people out

A few documented details decide whether a billing test is credible, and none of them are on the licensing page.

• Purchases on the internal track and in draft stage are subject to spend limits. Google links the billing test documentation from that line, so a tester banging through repeated upgrades on internal may hit a ceiling that will never exist in production.
• Testers have no public outlet. “Feedback from your test users won't affect your app's public rating”, and testers cannot leave public reviews for test versions. A tester who has just paid for an app and hit a bug has nowhere to say so on the listing — give them a channel in the opt-in message.
• The first test link is not instant. After the first publish of an open, closed or internal test, “the test link can take several hours to become available to testers”. A tester who cannot see the app has not necessarily been sent the wrong link.
• Play Billing Lab exists for the parts you cannot afford to test for real. It can change Play country inside a test, repeat trial offers on the same account, and test subscription price changes “without affecting other active subscribers” — useful when you want a regional price check without touching the live catalogue.

None of these decide whether you qualify for production access. They decide whether the evidence you collected during the window means anything when you sit down to write the application.

Frequently asked questions

Do testers have to pay for a paid app in closed testing? Yes. Google’s rule is that “testers must purchase paid apps when participating in open or closed tests”, and only internal tests let them install a paid app free.

Can I make the app free only for my testers? No. Pricing “affect[s] all versions across all tracks”, so there is no testers-only price or track-level discount. A price change reaches production and pre-registration at the same time as the closed track.

Does license testing make the download free? No. License testing covers in-app billing and subscriptions, not the price of the app itself. A license tester who has not bought the app still pays for it.

Do testers get refunded for buying my app during the test? Google’s testing and licensing pages describe the purchase requirement and the three-minute refund for unacknowledged license-test purchases, and do not describe a refund path for a closed tester’s app purchase. Assume the money is spent.

Do testers who never buy anything still count toward the twelve? Yes. The requirement counts testers “opted in continuously for at least 14 days” and says nothing about purchases. Payment status is not part of the gate.

My own purchase worked, so is my checkout fine? Not necessarily. Your publishing account “is always considered a licensed tester”, so you never see the real charge or the real payment instruments. Verify on a tester’s device.

Will twelve paying testers tell me if my price is right? No. Twelve installs validate that the paywall is reachable on a real device; they say nothing about willingness to pay at scale. Treat them as a functional check.

Sources

All pages read on 12 November 2026. Quotations are exact; where this article goes beyond them, it says so.

• Set up an open, closed, or internal test — the paid-app rule, the internal-test payment note, the cross-track monetization prerequisite, spend limits, test-link delay and the no-public-reviews note.
• Test in-app billing with application licensing — license tester lists, the unpublished-products rule, and the line that your own account is always a licensed tester.
• Test your Google Play Billing Library integration — test purchase flow, the three-minute acknowledgement refund, the compressed renewal and grace-period timings, the six-renewal cap, no tax on test purchases, and Play Billing Lab.
• App testing requirements for new personal developer accounts — the twelve-tester, fourteen-day wording used throughout.