Android’s Big Payments Shift: What Changes After Google vs. Epic

Monetization is set to widen for app developers — but with more choice comes more trade-offs.

Android just entered a new era for monetization. Thanks to the recent settlement in Epic Games vs. Google (pending court approval), developers can use alternative in-app payments, send users to external checkout experiences, 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

Epic and Google have reached a settlement that reshapes how developers can accept payments and reach users on Android. Three shifts stand out: 

• Alternative billing is now allowed inside apps and via link‑outs, so developers can process payments with their own stack or a third‑party provider, not just Play Billing.
  
  
• Effective service fees are reduced for transactions that use alternative billing (about 20% or 9% instead of up to 30%, depending on the path).
  
  
• Third‑party app stores are easier to install, subject to Google’s safety requirements, broadening distribution beyond Play.

Why it’s a big deal: together, billing choice and distribution flexibility create room for app teams to earn more per transaction, run pricing experiments, and reach users through new store channels. More than just a minor policy tweak, it rewrites the playbook for payments and distribution.  

Context matters: Apple was forced to change its policy after extended litigation pressure; Google proactively settled. The result is likely more developer‑friendly terms on Android — both for billing and for alternative store access. 

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/links to external web checkouts and, further, cannot take a commission 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: The Epic vs. Google settlement opens both how you bill and where users can get your app. Both alternative in-app payments and external web checkouts are supported with service fees capped at 9% or 20% when you don’t use Play Billing, and compliant third-party stores become easier to install under safety criteria (e.g., Samsung Galaxy Store, Amazon Appstore). 
 
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’s settlement sets two service-fee caps for external payments: 9% and 20%. Which cap applies depends on the transaction type and on where/how the app was installed. (Public developer guidance is still being finalized.)  
 
Here’s a breakdown of the three available options, pending the settlement ruling:  

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 a 20% service-fee cap  
Benefits: useful when you want to keep in‑app convenience and minimize UX changes. If your current effective rate is ~30%, you’re gaining ~10 points of margin before payment processing and fraud costs. 

External billing with a 9% service-fee cap 
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; plan on 20% for most Play-distributed apps that externalize payments; explore 9% in qualifying non-Play installation contexts and confirm against Google’s final developer guidance. 

Mobile experience — how to design an app-to-web-to-app flow

Most teams will start with app→mobile web 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 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, app-to-web 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 (9% and 20%).

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. 

Ship 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 app-to-web 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.