Monetization is set to widen through app2web flows — but with more choice comes more trade-offs.
This article was originally published on November 11, 2025. Since then, Google has announced broader Play Store changes tied to its Epic dispute, including lower service fees, support for alternative billing, and a new Registered App Stores program. Some U.S. remedies are still subject to court approval, so this article has been updated to reflect what is live now versus what remains pending.
Android just entered a new era for monetization. Thanks to the recent settlement in Epic Games vs. Google, developers can use alternative in-app payments, send users to external checkout experiences (app2web flows), and — when safety standards are met — offer easier installation of third-party app stores.
More freedom, however, also means more moving parts. App teams now have real control over checkout, pricing, and where transactions happen. Additionally, they’ll need to design smooth mobile flows, cover taxes and invoicing, manage payments and fraud, and keep policies consistent, on top of other responsibilities.
Below, we unpack what changed, how the new Android landscape compares to iOS (Epic received a favorable ruling against Apple in April), and practical next steps.
What just changed on Android — and why it matters
Google’s dispute with Epic has moved Android further toward payment and distribution flexibility, and some of the most important changes are now becoming clearer. Three shifts stand out:
- Alternative billing is expanding. Developers can use billing options beyond Google Play Billing, including in-app alternatives and app2web flows, depending on market and program rules.
- Service fees are coming down. Google has said that, by June 30, 2026, most app store service fees in the US, UK, and EEA will be 20% or less, with different economics depending on whether developers use Google’s billing services or their own.
- Third‑party distribution is opening up. Google is introducing a Registered App Stores program intended to reduce friction for alternative app store installs later in 2026, while broader U.S. remedies tied to the Epic case are still being worked through in court.
Why it’s a big deal: billing choice and broader distribution give app teams more room to improve transaction economics, test pricing more freely, and build direct customer relationships outside the traditional Play-only path. This is bigger than a narrow policy update. It changes how Android teams can think about monetization and go-to-market.
Android vs. iOS: what's actually different?
So, what are the major legal nuances between Android and iOS, based on the recent landscape changes? The broad direction is similar — more freedom for developers — but the details and scope differ.
On iOS: Apple updated its App Store rules to allow in-app buttons/app2web flows and, further, may not take a commission (pending district court framework) on those off-app purchases. The court also barred Apple’s “scare screen” and restrictive link language, as not to deter external payments. However, distribution is unchanged: iOS apps can be installed only via the Apple App Store; alternative app stores are prohibited.
On Android: Recent Epic-related changes have expanded both how you bill and how users may access apps outside Google Play. Alternative billing options now extend beyond standard Play Billing, including in-app alternatives and app2web flows, and Google has also outlined a Registered App Stores program to reduce friction for third-party store installs later in 2026. Fee structures are improving, but the exact economics vary by program, market, and implementation path.
For a refresher on the iOS picture, read our May explainer: Apple vs. Epic: A Legal Turning Point for In-App Commerce — and What Happens Next
What fees look like (Play Billing vs. external payments)
Google has outlined lower-fee paths for some external or alternative billing scenarios, but the exact economics depend on the transaction type, geography, distribution path, and program rules. Public guidance continues to evolve.
At a high level, developers are now weighing three main paths :
Play Billing (status quo) = up to 30% service fee
Benefits: simplest UX, fully in-app; Google Play handles many payment-adjacent functions (e.g., tax calculation/collection, invoicing, refunds/chargebacks), and developers gain from App Store discovery and trust.
External billing with reduced service fees
Benefits: useful when you want to keep in‑app convenience and minimize UX changes. If your current effective rate is ~30%, you’re gaining margin points before payment processing and fraud costs.
Lower-fee external billing paths
Benefits: typically tied to deeper externalization (e.g., more activity outside Play’s ecosystem). This is where the economics get compelling, but it also involves more UX design and operational work (mobile checkout, return to app, support flows).
Rule of thumb: use Play Billing when simplicity and conversion trump margin; evaluate reduced-fee external billing where it fits your market and distribution model; and confirm the latest developer guidance before committing to a path.
Mobile experience — how to design an app2web flow
Most teams will start with app2web checkout because it’s fast to ship and compatible with wallet options like Google Pay (where supported). Aim for a flow that feels native, even when it isn’t:
- Intent‑preserving deep links. Tapping “Buy” in the app should open a mobile web checkout for the exact product/plan (prepopulated when possible).
- Fast mobile checkout. Short forms, large tap targets, autofill, localization, and wallet buttons (Google Pay, PayPal, Amazon Pay where relevant).
- Hand‑back to the app. On success, return the user to an unlocked app state with a clear confirmation.
- Receipts and auto-renewals. Instant on‑screen confirmation + email with price, taxes, renewal date/cancel path, and support.
When evaluating solutions, confirm which wallets are available and whether the flow reliably returns the user to the app in an unlocked state
How to choose your path — Play Billing, app2web checkout, or a third‑party store
Use this simple lens to choose the right path for your app:
ARPPU & margin sensitivity. Higher average revenue per paying user (ARPPU) or paid plans with meaningful add‑ons benefit most from lower fees; micro‑transactions may favor simplicity.
Conversion risk tolerance. If your audience is conversion‑sensitive or low‑trust, keep friction minimal (e.g., wallets, one‑tap). Test before you move everything.
Operational capacity. External billing adds work (tax, fraud, refunds, reporting). If you don’t have the capacity, consider a partner to carry that load while your team ships product.
Acquisition channels. If Play drives discovery, but your brand has strong web demand, a hybrid (Play for install, web for pay) can work well.
Next step: pilot on a small cohort, then let contribution margin and retention decide what you scale.
Compliance you can't ignore
Under Play Billing, Google Play acts as the merchant of record (MoR): it calculates and collects taxes, issues invoices, handles refunds & chargebacks, and carries a chunk of the compliance burden. When you move any payments outside Play Billing, that work shifts to your team.
What that means in practice:
- Taxes and invoicing across markets (rates, receipts, remittance)
- Payment processing and routing, plus fraud/chargebacks
- Refund policy alignment across app and web
- Privacy and data obligations (e.g., consent, storage, SCA/PSD2 where relevant)
- Support workflows that match the new flow
If you want to keep these operations outsourced while overtaking the economics, one path is to partner with a third-party MoR provider. You still offload tax, invoicing, fraud, refunds, and compliance, but you gain control over pricing and checkout, benefitting from the reduced external payment fees where eligible.
Your 30-day action plan
Confirm scope. Document which GEOs/SKUs you’ll pilot.
Do the math. Model Play vs. external billing at your real ARPPU, with conservative conversion assumptions.
Prototype the mobile flow. Intent‑preserving deep link → mobile‑web checkout with wallets → hand‑back to app.
Prep the ops. Taxes, fraud, refunds, invoicing, and reporting.
Launch a limited pilot. Use holdouts; compare contribution margin, not just top‑line.
Explore third‑party store distribution (optional). Validate Google’s safety standards and the install UX before committing.
Bottom line
Android is moving from a fixed model to real choice, in how you bill and where you distribute. The winners won’t just chase lower fees; they’ll ship a smooth mobile flow, button up tax/fraud/refunds, and measure the whole journey end‑to‑end.
If you’re ready to act, start with a targeted app2web pilot backed by mobile wallets and clean hand‑backs. Want to move faster without hiring a back office overnight? Talk with your finance and legal teams about whether a merchant of record model makes sense for your roadmap — and then make the math work.
