Google Play’s biggest billing change in years starts rolling out on June 30, giving Android developers in the United States, United Kingdom, and European Economic Area broader permission to offer alternative billing systems or send users to their own websites for digital purchases.
The change is not a simple end to Google Play fees. Google is separating its service fee from its billing fee, lowering some rates, and making the applicable fee depend on the user’s install timing, product type, billing method, region, and developer program status. For paid apps, subscriptions, in-app purchases, and digital services, that makes June 30 less of a switch-flip moment and more of a monetization audit deadline.
In a June 24 Android Developers Blog post, Paul Feng, Google Play’s vice president of engineering, product, and UX, outlined the first phase of the rollout. Developers can use Google Play Billing, offer an alternative in-app billing system, or direct users to an external website for purchases, subject to Google Play’s program rules and user-experience guidelines.
What Changes On June 30
The first rollout covers the US, UK, and EEA. Australia follows on September 30, 2026. Japan and South Korea are scheduled for December 31, 2026, and the rest of the world is listed for September 30, 2027, according to Google’s lower service fees help page.
The new model splits fees into two pieces. Google Play still charges a service fee on digital transactions whether the developer uses Google Play Billing, alternative billing, or external web links. If the transaction uses Google Play Billing, an additional billing fee applies. In the US, UK, and EEA, that billing fee is 5%. Transactions handled through alternative billing or external web links do not carry that separate Play Billing fee.
The baseline service fee starts at 10% on the first $1 million in annual earnings. Auto-renewing subscriptions are also listed at 10%. For other transactions, Google’s new rate cards distinguish between “new installs” and “existing installs,” using the regional rollout date as the dividing line.
For users whose first install or first Play Store update occurs on or after the regional launch date, standard non-recurring transactions are listed at 20%, or 15% for developers participating in the new Apps Experience or revamped Games Level Up programs. For existing installs, standard non-recurring transactions are listed at 25%, or 20% through those programs. Google Play Billing transactions can add the 5% billing fee on top in the first rollout markets.
Why The Install-Date Rule Matters
The install-date rule is one of the details most likely to trip up teams that only look at headline fee cuts. Google defines a new install by when the app was first installed from Play, or first updated from Play if it did not originally come from Play. That means the same product, price, and payment flow can produce different service-fee outcomes for different users.
Developers should model revenue separately for new and existing install cohorts before changing checkout behavior. A subscription-heavy app may see a different outcome from a game with one-time consumables. A mature app with a large installed base may carry more existing-install exposure than a newly launched app. A company using Play Billing in one market and external checkout in another will also need reporting and finance systems that can reconcile those differences without turning month-end accounting into guesswork.
Alternative Billing Still Comes With Operational Work
Offering another payment option is not just a front-end checkout project. Google’s US alternative billing requirements say participating developers must comply with payment-card security requirements if they handle card data, follow applicable laws including rules protecting minors and children, support disputes for unauthorized transactions, and provide links for order history, subscription management, customer service, and refund requests.
Google also says developers must manage Play Console alternative billing settings, enroll eligible apps, integrate the alternative billing APIs, and, once required, report authorized US transactions within 24 hours using those APIs. Teams that already have a web checkout may still need product, legal, support, analytics, and finance changes before they can safely expose it inside Android apps.
The customer-support burden is easy to underestimate. If a user pays through a developer’s billing system, that user will expect the developer, not Google, to resolve refunds, failed payments, subscription changes, chargebacks, tax invoices, entitlement mismatches, and account-recovery problems. For smaller app makers, the fee savings can be real, but so can the operational load.
What Developers Should Check First
- Fee exposure by market: Separate US, UK, EEA, Australia, Japan, South Korea, and rest-of-world revenue because the rollout schedule changes when a user becomes a new install for fee purposes.
- Install cohorts: Estimate how much revenue comes from users who installed before the rollout date versus users who install or update after it.
- Billing method mix: Compare Google Play Billing, alternative in-app billing, and external web checkout after including payment processing, fraud tools, taxes, support, refunds, and failed-payment recovery.
- Subscription management: Make sure users can find order history, cancel or change subscriptions, request refunds, and recover entitlements across payment systems.
- Compliance ownership: Assign clear owners for PCI-DSS, tax handling, minors and children protections, user disclosures, data retention, and regional consumer-protection requirements.
- Reporting pipelines: Prepare transaction reporting, reconciliation, and audit logs before routing production users through a new payment path.
The Epic Case Still Shapes The Background
The billing rollout follows years of litigation between Google and Epic Games over Android app distribution and Play Store payments. Google also notes in its US policy update that, as of October 29, 2025, it changed policies for US mobile and tablet apps so developers could communicate about outside pricing and payment methods, link to transactions, and use in-app payment methods other than Google Play Billing.
Another date is coming quickly. Google says that unless developers opt out by July 22, 2026, Play app listings in the US will begin being made available to third-party Android app stores. That is a separate distribution issue from June 30 billing choice, but the two changes point in the same direction: Android app commerce is becoming more flexible, and also more operationally complex.
The Practical Takeaway
For users, the visible change may be modest at first: more checkout options in some apps, occasional links to web payments, and different ways to manage purchases. For developers, the change is more immediate. The old question was whether Google Play Billing was required. The new question is whether each payment path is worth its total cost after fees, payment processing, reporting, user support, compliance, and retention are included.
The safest move before June 30 is not to rush a new checkout screen into production. It is to map the app’s revenue by region, product type, install cohort, and billing method, then decide where alternative billing actually improves the business. For some Android developers, Google’s new rules will open a cheaper direct-payment path. For others, the 5% billing fee may be less expensive than rebuilding the machinery around payments, support, and compliance.
