Google Play's New Fee Structure and Billing Choice: What Actually Changes for Android Developers

Google announced expanded billing choice and restructured service fees for Google Play, effective June 30, 2026 for the United States, United Kingdom, and European Economic Area. If you ship paid apps, sell in-app purchases, or run subscriptions through Play, these changes affect what you keep from every transaction.

I'll be honest — Play's fee policy has historically been one of those things I'd glance at once during initial monetization setup and then never revisit. That was a mistake. The new structure is meaningfully different from the old one in a few places, and the billing choice expansion in particular creates options that didn't exist before. Worth understanding properly before June 30 arrives.

Breaking Down the New Service Fee Structure

The service fee — the base percentage Google charges on revenue processed through Play — now varies by product type and by whether the user is a new or existing install:

Transaction Type	New Installs	Existing Installs
First $1M USD annual earnings	10%	10%
Auto-renewing subscriptions	10%	10%
Digital goods & services	15%	10%
Physical goods	10%	5%

"New installs" means the first install or update on or after the regional rollout date. "Existing installs" means the app was already installed before the rollout. The distinction matters most for digital goods: a new user pays the 15% rate, but your existing user base gets the lower 10% rate applied to their purchases.

The 10% cap on the first $1M of annual earnings applies regardless of product type — which was already in place but is worth re-confirming. If you're building a side project or an early-stage app that hasn't cleared $1M in a year, the first-million bracket is effectively your entire revenue and the 10% rate applies to all of it.

The additional billing fee — this is where it gets interesting

On top of the service fee, Google charges a separate billing fee in the US, UK, and EEA that depends on how you collect payment:

• Google Play's own billing system: 5% billing fee
• Alternative billing system (user's choice): 0% billing fee
• External web link (send users to your site): 0% billing fee

This 5% is a processing fee, not the service fee — it covers Google's payment infrastructure. The practical implication: if you use Google Play Billing, your actual take rate is the service fee plus 5%. For a subscription, that's 10% + 5% = 15% effective rate. For digital goods sold to a new user, it's 15% + 5% = 20% effective rate. Using your own billing or an external link removes the 5% entirely.

The Billing Choice Program — and What Each Option Actually Means

The Billing Choice Program expands in this update and now covers 195+ markets with 300+ local payment methods. In the US, UK, and EEA, you now have three distinct paths:

Option 1: Keep Google Play Billing

Nothing changes on your end — users see the familiar Play payment sheet, Google handles fraud, refunds, and payment processing. You pay the service fee plus the 5% billing fee. For most apps this is still the lowest-friction choice, especially if your users trust the Play payment experience and you don't have a web presence to send them to.

Option 2: Offer an alternative billing system alongside Play

You integrate a third-party payment provider (Stripe, RevenueCat, a local PSP) and present both options to the user. Google specifies a UX guideline for how the choice screen must look — you can't just hide Play Billing and offer only your own. The service fee stays the same; the 5% billing fee goes away because you're handling payment processing yourself.

This makes most sense for apps that already have significant web revenue and an existing payment relationship with users. Syncing subscription state across two billing systems is non-trivial. I'd think hard about implementation complexity before going this route just to save 5%.

Option 3: Link users to your external website

You add a link inside the app that directs users to your website to complete the purchase. No alternative billing UI inside the app, no payment sheet shown in-app at all. Same 0% billing fee as Option 2. You handle everything on your side — payments, receipts, provisioning entitlements back into the app.

This is the option that's gotten the most attention, and for good reason. You keep 100% minus just the service fee. But provisioning entitlements reliably — making sure a user who paid on your website gets their subscription state reflected in the app immediately, across devices, without a forced sync — is genuinely hard to do well. It's not a reason to avoid it, but it's engineering work you need to plan for, not just a checkbox in Play Console.

Games Level Up and Apps Experience Programs

A second tranche of changes lands September 30, 2026: two programs that offer further reduced service fees for apps and games that meet a specific set of quality and engagement requirements.

Games Level Up targets, predictably, games. Apps Experience covers non-game apps. Both programs require apps to meet all eligibility criteria — engagement metrics, crash rates, store listing completeness, policy compliance — to qualify for reduced rates. The specifics of each program's requirements are in the Play Console documentation.

For context: Nodat is the kind of productivity/utility app that could potentially qualify for the Apps Experience program if crash rate and engagement benchmarks are met. The reduced rates apply on top of the base fee structure — so qualifying on both the first-million bracket and an experience program stacks in your favor. Worth checking eligibility now rather than waiting.

What This Looks Like in Practice for a Real App

Let me make this concrete with numbers from the kind of app I actually build. Say you have a subscription app like Nodat with a ₹199/month premium tier (~$2.40 USD). You're somewhere between 1,000 and 5,000 paying subscribers — under the $1M first-year threshold for most of the user base.

// Effective rates for a $2.40/month subscription (US/UK/EEA)

// Using Google Play Billing:
service_fee = 10%   // subscriptions
billing_fee = 5%    // GPB processing
effective_rate = 15%
you_keep = $2.04

// Using alternative billing or external link:
service_fee = 10%   // same
billing_fee = 0%    // you handle processing
effective_rate = 10%
you_keep = $2.16

// Difference per renewal: $0.12
// At 2,000 active subscribers: ~$240/month, ~$2,880/year

$2,880/year isn't life-changing at that scale, but it's not nothing either — and the number scales with subscribers. The question is whether the complexity of running a second billing path (or an external purchase flow) is worth it at your current size. At 500 subscribers, probably not. At 10,000, the math gets more compelling.

What about apps outside the US/UK/EEA?

The June 30 changes apply specifically to those three regions. Additional markets will receive a phased rollout on a schedule Google hasn't fully published yet. For apps with most of their revenue in, say, India or Southeast Asia, the immediate impact is limited — but the billing choice framework is clearly the direction Google is moving globally, so planning for it now makes sense.

What You Should Actually Do Before June 30

Most apps don't need dramatic action before the deadline, but a few things are worth doing:

• Pull your current revenue breakdown by region. If US/UK/EEA is a small fraction of your revenue, June 30 is a low-urgency event. If it's your primary market, read the new fee tables carefully against your current pricing.
• Check your subscription billing code. If you're using the Play Billing Library and nothing else, you're on Option 1 by default — no code changes needed.
• Look at the Games Level Up / Apps Experience eligibility criteria if you have an established app. September 30 gives you three months to improve metrics that might push you over the threshold.
• Don't rush into alternative billing to save 5% without accounting for the implementation cost. Dual billing paths or external purchase flows require proper entitlement sync, which means server-side state and reliable webhooks from your payment provider back to your backend. Budget that work properly.

My honest read: the fee restructuring and billing choice expansion are genuinely developer-friendly moves, even if the motivation is partly regulatory (EU DMA compliance, US antitrust pressure). The 10% subscription rate for the first $1M is reasonable for what Play provides — global distribution, fraud protection, device-level payment auth. Whether to opt into alternative billing is a business call, not a technical one. Run the numbers for your specific user base and transaction volume, and don't make the decision based on the percentage alone without factoring in the engineering cost of doing it right.