On September 29, 2026, Google published a Play Store monetization update that's been making the rounds on 9to5Google, Daily.dev, and Android Weekly ever since: three new subscription tools — Multi-Quantity Subscription Purchase, Usage-Based Billing, and Cross-Developer Bundling — now rolling out through Google's Early Access Program. This isn't a developer-console cosmetic change. Google's own post frames it plainly: the subscription landscape is evolving rapidly because of generative AI and increasingly sophisticated app experiences, and these are the billing primitives built to match. For any team building an Android app with per-seat pricing, metered AI usage, or a catalog of complementary products, this is the most consequential Play Store monetization news since expanded billing choice landed earlier this year — worth understanding before your next pricing conversation, not after a competitor ships it first.
What Google actually shipped on September 29
Multi-Quantity Subscription Purchase lets a user buy multiple subscription seats in a single Play Store transaction and assign them to team members or students, instead of routing every seat through its own separate purchase flow. Google named productivity, EdTech, and GenAI developers directly as the intended audience.
Usage-Based Billing sets up prepaid metered billing: a user's balance tops up automatically once it drops below a set threshold, aimed at apps with variable computing costs — an AI image generator, a video-rendering tool, anything billed per token or per inference call rather than a flat monthly fee.
Cross-Developer Bundling lets a developer package two or more subscriptions — across their own app portfolio, or with a partner's catalog — into a single purchasable SKU. Google's own example: a language-learning app bundling its monthly membership with a partner's premium travel-guide subscription at a discounted combined rate.
Why usage-based billing matters most for AI-powered apps
Every Play subscription tier until now has meant flat monthly or yearly pricing — a bet that average usage stays comfortably under whatever a plan costs to serve. That bet breaks down fast once an app is calling a third-party LLM per request: a single power user generating thousands of completions on a $9.99/month plan can flip that user's unit economics negative, and there's been no native way inside Play Billing to price around it.
Usage-based billing brings a pay-as-you-go wallet model — the same pattern API providers like Anthropic and OpenAI already bill on — natively into Play, rather than leaving each developer to build their own metering, balance tracking, and reconciliation against Play's payment infrastructure by hand. It's still rolling out through the Early Access Program rather than sitting in general availability, so the right move for now is applying and piloting it on the specific feature that's actually metered, not assuming it's a drop-in replacement for your whole billing model.
Multi-quantity purchases: the EdTech and team-licensing angle
This is the feature we'd point institutional and B2B clients to first. Today, selling a classroom set of seats through Play typically means either routing the sale through a web-based licensing portal outside the app, or asking an administrator to click through the same purchase flow N separate times for N seats. Multi-Quantity Subscription Purchase does natively what most LMS platforms — including what we build under D.TEN — have historically had to fake with custom seat-management logic bolted on top of single-user billing.
Buying 30 seats in one Play Store transaction and assigning them to specific students or staff keeps the whole purchase inside Play's billing system, where refunds and proration already work as expected, instead of maintaining a parallel invoicing path just to handle group buyers.
The bundling and regional rollout timing that matters right now
Cross-Developer Bundling opens a genuinely new monetization lever — partnering with a complementary app to sell a combined subscription — but it ships alongside a rollout timeline worth flagging precisely because of when this post is being written. Google's expanded-billing-choice and lower-service-fee changes follow a staggered regional schedule: the EEA, UK, and US from June 30, 2026; Australia and Japan from September 30, 2026; South Korea from December 31, 2026; and the rest of the world a year later, on September 30, 2027. If any meaningful share of your install base is in Australia or Japan, today is the actual day those users' billing options and lower fee tiers activate — not a future date to bookmark. Google's New Apps Experience and Games Level Up lower-rate programs for qualifying apps also open the same day.
A way to decide which of the three fits your app
The three tools solve different problems, so it helps to match each to a concrete situation in your own product before you apply to anything.
| Tool | Fits when | First question to ask |
|---|---|---|
| Multi-quantity subscription purchase | You sell to schools, teams or families who need several seats | Who assigns seats, and how do refunds work for a group? |
| Usage-based billing | Your cost per user varies with usage, for example per AI request or render | Which single feature carries the variable cost? |
| Cross-developer bundling | A partner's product complements yours for the same customer | Who handles support and what is the revenue split? |
Questions to settle before you apply
- Where does the variable cost come from? If you cannot point to a metered cost, flat pricing is probably still right.
- What does a customer see when their balance runs low? Automatic top-ups need clear wording and an easy way to stop.
- How will you explain seats to a school administrator? A confusing purchase flow will push buyers back to a web checkout.
- Which regions matter to you? The rollout schedule varies by region, so check what applies to your largest markets.
- Do your policies and the Play listing describe the billing accurately? Subscription terms must be clear before purchase.
These are product questions as much as technical ones. The billing primitive only works well when the customer-facing story is simple.
What we'd actually recommend
Treat these as three separate opt-ins evaluated on their own merits, not a single billing overhaul to roll out at once. Apply to the Early Access Program for whichever fits your app rather than waiting for general availability to even start testing.
Usage-based billing is worth adopting only where you're carrying a real, variable per-request cost — LLM inference, rendering, compute-heavy processing. Retrofit it onto that specific feature first rather than converting an entire flat-rate product to metered pricing on day one.
If any client sells to schools, teams, or districts, pilot multi-quantity subscription purchase quickly — it directly closes the seat-licensing friction that currently pushes B2B EdTech buyers toward a web checkout instead of completing the purchase inside the app.
Before shipping a bundled SKU under Cross-Developer Bundling, get the revenue-share split and support responsibilities with any bundling partner in writing — Play handles the transaction, not the partnership agreement behind it. And if Australia or Japan make up a meaningful part of your install base, check your current service-fee tier now that today's rollout milestone has actually landed.
Frequently asked questions
Sources

Written by
Wazir Ahmed
CTO, DEESU and CEO, D.TEN
Dr. Wazir Ahmed is the CTO of DEESU and leads D.TEN, its training and education division. A training manager, educational psychologist and researcher with a Ph.D. in educational psychology, he oversees learning systems, technology architecture, and training design.
More from WazirFree tools for this topic
Need help with this?

