Google Play's fee structure changed quietly but substantially in 2026, and the headline numbers — a 20% in-app purchase service fee for new installs and a separate 5% billing rate when you bring your own processor — are easy to read wrong if you skim the announcement. The rules are different in the EEA, the UK, and the US than in the rest of the world. The "20%" doesn't always apply. And the 5% billing rate isn't a discount you opt into — it's the residual platform fee you still owe when you handle billing yourself.
If you're an indie developer or a small studio shipping subscriptions or one-time IAPs on Android, the math is now genuinely worth running. This guide walks through what actually changed, what the numbers mean for your P&L, and the surprisingly small list of cases where switching billing providers pays off in 2026.
What actually changed in the Google Play fee structure#
For most of Google Play's history, Google charged a single bundled fee — historically 30%, dropping to 15% for the first $1M of annual developer revenue or for subscriptions after the first year — and that fee covered both the platform (distribution, fraud detection, hosting) and the billing (payment processing, refunds, tax compliance). You couldn't see the two pieces separately because they weren't sold separately.
In 2026, Google split them. The platform service fee and the billing service fee are now two distinct line items, and developers in the EEA, UK, and US can opt to use their own billing processor and pay only the platform fee. The headline numbers Google published:
- Platform service fee: 20% on new installs in eligible regions, replacing the old 15% / 30% bundled rate for those installs.
- Billing service fee: 5% when developers choose to use their own billing system instead of Google Play Billing.
- The combined Google-handled rate (platform + billing through Google) remains roughly equivalent to the old structure for installs that pre-date the change, but the new install rate effectively becomes 20% if you stay on Google's billing or 25% combined if Google bills and you're outside the special programs.
The two facts that trip people up: the 5% is additive, not a discount, and the 20% only applies to new installs in the eligible regions. Existing installs in those regions and all installs everywhere else continue under the legacy rates.
The honest math: when switching billing pays off#
This is the question every indie dev should be asking, and the answer is less obvious than the announcement suggests.
If you stay on Google Play Billing in an EEA/UK/US new install, you pay roughly 20% (platform) + the embedded billing processing inside that — net rate stays close to the old bundled 20-25% range depending on subscription tenure.
If you switch to your own billing, you pay Google 5% (the platform-only billing fee) on top of the 20% platform fee. So your Google bill is 25%. But now you pay your payment processor — Stripe, Adyen, whoever — which is roughly 2.9% + $0.30 for credit cards, plus chargeback fees, refund handling, and tax remittance.
Run the numbers on a $9.99 subscription:
- Google Play Billing: ~$2.00 to Google (20%), $0 to a processor. You net ~$8.00.
- Your billing + 5% platform fee: ~$0.50 to Google (5%) + $2.00 platform fee = $2.50 to Google. Then ~$0.59 to Stripe. You net ~$6.90.
So at face value, you make less money switching billing. The savings only materialize if your payment processing costs are dramatically lower than Stripe's published rates — which means you're either at a scale where you can negotiate sub-2% processing, or you're using an alternative method (direct bank debit in some EU markets, account-to-account rails, etc.) that comes in well under card-network fees.
For most indie devs grossing under a few million a year on Android, the math doesn't favor switching. The control and reporting benefits of running your own billing are real, but they're not free.
What "billing choice" really unlocks#
The interesting parts of the 2026 changes aren't the headline percentages — they're the second-order effects.
Subscription portability is the big one. Under the old bundled model, a subscriber's payment relationship lived inside Google Play. If they cancelled their device, churned to iOS, or stopped using the Play Store, you lost the billing relationship. With your own billing, the customer is yours in a clean way — you can offer them a web upgrade, a cross-platform plan, a yearly commit at a discount, all without Google's intermediation.
Refund and trial control gets better. Google Play's refund policy is generous, which is great for users and occasionally painful for developers running thin margins on annual subscriptions. With your own billing, you set your own refund window. (You should still be generous — but you control the policy.)
Tax compliance gets harder. This is the often-skipped downside. Google handles VAT, GST, and US sales tax remittance for you when you bill through them. Switch to your own billing and that's now your problem — every jurisdiction, every threshold, every quarterly filing. Stripe Tax and similar services can do most of it, but you're still on the hook if something falls through.
If subscription portability matters to you (it often does for cross-platform SaaS), the 5% billing route is worth it. If you're a single-platform game with one-time IAPs, almost certainly not.
The compliance and technical reality#
Switching billing isn't a flag flip. Google requires apps using their own billing in eligible regions to:
- Implement Google's user choice billing UI flow, which presents Google Play Billing alongside your option at purchase time.
- Handle subscription state synchronization back to Google Play so the user's account state stays consistent across the system.
- Support refunds and dispute handling within your billing system, with a process for escalating to Google when needed.
- Maintain tax compliance documentation Google can audit.
The dev work for a small team to implement user choice billing properly — including the UI, the refund flow, the tax stack, and the compliance reporting — is realistically three to six engineering weeks. That's not nothing for a solo dev or a two-person team.
This is the part the fee announcement glosses over. The 5% rate is real, but the cost of qualifying for it includes a meaningful chunk of engineering time you weren't planning to spend.
What this means for the listing and submission side#
One thing I rarely see discussed: switching billing changes your store listing obligations.
Google requires apps using alternative billing to be transparent about it. Your store listing language, your subscription disclosures, and your privacy policy all need updates. If you have a "subscription" link in the app that previously deep-linked to Google Play subscriptions, that flow may need to change. Localized listings in 20+ regions all need to be reviewed for consistency. Screenshots that show subscription pricing may need refreshes.
This is the part where most teams lose a week of unplanned work. The billing migration goes fine; the store listing rollout drags.
It's also why I think the "should I switch billing" question is harder than the published math implies. You're not just changing a payment processor. You're changing the contract you have with your customers, the reporting surface for your finance team, the compliance posture you need to maintain, and the listing copy users see at the moment of purchase. Each of those costs time.
A practical framework for deciding#
Here's the decision tree I'd actually use if I were running an indie Android app today:
- Do you cross more than $1M ARR on Google Play? If no, stay on Google Play Billing. The math doesn't favor switching.
- Is subscription portability strategic for you? If your primary value prop is cross-platform (web + iOS + Android) and you want unified subscriber identity, switching can be worth it even at higher net cost.
- Do you have engineering capacity for a 4-6 week billing rebuild? If no, defer.
- Are you in an eligible region (EEA, UK, US)? If no, you can't do user choice billing anyway.
- Is your tax compliance posture mature? If you don't already have Stripe Tax or equivalent running, add 2 weeks to the timeline.
For 90% of the indie devs I've talked to, the answer is "stay on Google Play Billing, eat the 20%, focus on the product." The new rate is real and it's worse than the old 15% / 30% bundled split for some segments, but the engineering and compliance cost of leaving is high enough that for small teams, the right answer is to absorb it.
How Stora helps the submission side#
Whether you switch billing or not, the listing and submission work that comes with any Android monetization change is real and tedious. Stora's compliance engine flags the listing inconsistencies that come up when you're updating subscription disclosures across markets, and the AI store listing generator handles the localized copy refreshes for the 20+ regions where you'll need updated language. The screenshot generator regenerates pricing-aware screens automatically when your IAP tiers change. None of this replaces the strategic billing decision — that's still on you — but it removes a week of fiddly listing work from the timeline.
The 2026 Google Play fee changes are the biggest billing shift since the original 30% / 15% split. Most indie devs will end up doing nothing differently and accepting a slightly worse net rate. A small number with genuine cross-platform leverage will switch and recoup the engineering cost over 12-18 months. Either decision can be the right one — but make it on the actual numbers, not the headline.