Google Play Billing Changes: What to Do Now

Google Play Billing changes are live in the United States. As of October 29, 2025, apps distributed via the US Play Store can link to off‑store downloads and use alternative billing inside the app. That’s a real‑world lever on acquisition and take rate—and it sits alongside new Play policy updates and a November 1 requirement to support 16 KB page sizes for Android 15 (API 35) targets. Here’s what changed, what’s coming through November 1, 2027, and the exact steps we’re taking with product and engineering teams right now.

The short version: what changed on October 29—and how long it lasts

Starting October 29, 2025, when your app serves users in the US, Google is:

• No longer requiring Google Play Billing inside apps distributed on the Play Store.
• Allowing developers to link to external payment options and to download sources outside Play.
• Allowing developers to communicate pricing and availability outside Play within the app experience.

Two important constraints: these changes currently apply to the US market, and they are tied to a court order scheduled to run until November 1, 2027. After that date, the landscape could change again. Google has also said it will publish additional program requirements and business model updates to “preserve trust and safety,” so expect further implementation rules and potential fees to clarify over the next quarters.

Why this matters to your roadmap and P&L

For years, in‑app billing on the Play Store meant a platform‑defined take on every transaction and tight restrictions on how you could inform users about alternatives. Removing those two frictions—payment method flexibility and the ability to link—directly affects:

• Effective take rate: If you process via your own PSP, your stack might look like 2.5%–3.5% + a fixed fee. With large basket sizes (education, productivity suites, B2B), even a 5–10 point delta on fees materially changes gross margin and CAC payback windows.
• Conversion: In many funnels, users prefer web checkout they already trust (saved cards, PayPal, or regional wallets). The ability to deep‑link to a tailored, prefilled checkout can lift paid conversion without re‑architecting the entire Android client.
• Pricing strategy: You can run US‑only offers on web or alternative stores without worrying about past Play restrictions on in‑app communication. Expect more A/B testing of list price vs. “web price,” with geo and channel targeting.

Here’s the thing: flexibility doesn’t remove operational complexity. Taxes (including sales tax and VAT where relevant), refunds, chargebacks, fraud tooling, and support experience become your job when you step outside Play Billing. That’s fine—just treat it like a product.

Where "Google Play Billing changes" land in your architecture

If you maintain a multi‑platform monetization stack (iOS, Android, web), the practical question isn’t “Should we?” It’s “Which option gives us lift with the least risk in the US while keeping global parity?” Four realistic patterns:

Option A: Stay on Play Billing for now

Best for teams with thin payments expertise, high chargeback risk, or a large base of Play subscriptions. You keep entitlement management simple and avoid refund/chargeback support build‑out.

Engineering: minimal changes. Product: monitor competitive pricing and user messaging, prepare contingency plan.

Option B: Add in‑app alternative billing

Best for paid utility apps, pro upgrades, and subscriptions where you already operate a web stack. You’ll embed your PSP SDK or a hosted checkout inside the Android app. Consider a treatment where web checkout is primary and Play Billing remains as a fallback.

Engineering: integrate PSP SDK or a secure webview flow, server‑side receipt/entitlement issuance, robust error handling. Compliance: clear disclosure of who bills the user, how to manage/cancel, and how refunds work.

Option C: Link out to web checkout

Best for teams that want to minimize app changes and preserve a single payment surface. Use deep links with signed parameters (user ID, offer, currency) to a responsive web checkout. The linking permission means you don’t have to hide it anymore.

Engineering: link generation, state hand‑off, anti‑tamper signing, post‑purchase callback to grant entitlements. Marketing: instrument UTMs and server events to measure uplift cleanly.

Option D: Hybrid and price steering

Best for subscription apps navigating carrier billing or gift cards. Offer both, but steer users toward web (e.g., extra months on annual plans, loyalty perks) without dark patterns. Maintain compliance with US consumer disclosure rules and Google’s policy language.

US‑only, through 2027: set expectations with your team

Two realities to socialize across product, legal, and finance:

• Scope: The new flexibility currently applies to US users. Don’t roll out a single global paywall assuming the same leeway applies everywhere. Keep country routing logic explicit.
• Timeline: The current permission is tied to a court order scheduled to run until November 1, 2027. Build your stack to support both “open” and “Play‑only” modes so you can adapt quickly if rules shift later.

Messaging matters. If you offer lower prices on web for US users, disclose why (e.g., “lower processing costs on our website”) and make cancellation paths obvious. Don’t risk a short‑term lift that invites policy or regulator attention.

Policy changes that can block your next release

Beyond monetization, Google posted several Play policy updates on October 30, 2025, with at least 30 days to comply. Two that teams are missing in stand‑ups:

• Financial features declaration: Every app on your account must complete the declaration—even if it doesn’t contain financial features. As of October 30, you can be blocked from pushing any update until this is done. Treat it as a release gate and get it off the critical path.
• Age‑Restricted Content and Functionality: If your app includes matchmaking, dating, or real‑money gambling/games/contests, you must use Play Console features to block minors. Pull compliance into your onboarding and analytics, not just the checkout screen.

You’ll also see clearer subscription disclosure guidance and a new 180‑day appeal window for account terminations. And developers now get Play Policy Insights surfaced directly in Android Studio—use it proactively to catch policy issues during implementation instead of in review week.

Engineering alert: 16 KB page size is now a hard requirement

Starting November 1, 2025, all new apps and updates submitted to Google Play that target Android 15 (API 35) and higher must support 16 KB memory page sizes. If your app includes native code—directly or via SDKs—you likely need to rebuild. We’ve seen teams with older React Native or Unity plugins crash immediately on 16 KB devices or fail review because their AAB doesn’t indicate compliance.

How to ship 16 KB support this week

1) Identify native code. Inventory all ABIs and SDKs with .so libraries (your code and third‑party). If you can’t list them in 10 minutes, export your AAB and inspect in App Bundle Explorer.
2) Rebuild with updated toolchains. Use NDK versions that align segment alignment to 16 KB where required. For Unity/Unreal/Flutter/React Native, confirm the exact plugin versions that added 16 KB support.
3) Test on a 16 KB environment. Spin up an Android 15 emulator configured for 16 KB pages and at least one physical device if available. Watch for segfaults and linker errors on start.
4) Confirm in Play Console. In App Bundle Explorer, verify the 16 KB readiness check passes before you hit “Start rollout.”
5) Avoid back‑compat band‑aids. The platform offers back‑compat toggles to limp along, but your goal is to actually rebuild compatible binaries—temporary toggles don’t pass Play’s requirement for targeted devices.

Tip: Document precisely which SDKs and versions you upgraded for 16 KB support. This becomes your audit trail when a future plugin update re‑introduces misaligned segments.

Designing the entitlement system you won’t regret

If you add web checkout to the mix, entitlement issuance and reconciliation are where things break first. A durable pattern looks like this:

• Server‑owned entitlements: Your backend is the source of truth for who owns what across Android, iOS, and web.
• Deterministic hand‑off: Your app generates a signed payload (user ID, product, price, currency, expiry). Your web checkout returns a signed receipt that your server validates with the PSP and converts to an entitlement.
• Unified cancellations and refunds: Build a “cancel anywhere, reflect everywhere” model. For web purchases, expose cancellation and refund requests in‑app as well as on the web. For Play Billing purchases, keep your existing listener flow.

Map this to your CRM. If you’re going to experiment with web‑only promotions, ensure event tracking captures channel and cohort correctly so finance can see margin impact, not just gross bookings.

Pricing and communication without drama

Can you offer a lower price on web than inside Play? In the US right now, yes. Should you? Often yes—for annual plans in particular—but do it with disclosure and good taste. A simple badge like “Best price on our website due to lower processing costs” keeps you honest and reduces support tickets. Don’t bury cancellation info. Add a plainly labeled “Manage on web” entry in your app’s Subscription screen that deep‑links users to their account page.

Security and fraud: the catch nobody wants to own

When you leave Play Billing, you own fraud. Expect card testing, friendly fraud, and a surge in support contacts the first 60 days. Bring a basic toolkit: AVS and CVV checks where applicable, device fingerprinting, velocity limits by user and BIN, and a human review queue for anomalous purchase patterns. For subs, require SCA or 3DS where it’s standard in your regions, and bake in dunning flows for expired cards. Plan now, not during your first chargeback wave.

People also ask

Can we migrate existing Play subscriptions to web?

You can’t force‑migrate an on‑Play subscription to a different billing system. What you can do is let customers cancel on their next renewal and re‑subscribe on web—ideally with a proration credit or loyalty perk that feels fair. Build messaging and in‑app nudges that trigger only for US users.

Do we need separate SKUs for web vs. Play?

It’s cleaner, yes. Separate SKU namespaces avoid reconciliation headaches and let you run pricing tests without touching live Play products. Keep a mapping table in your backend that translates app events to the right SKU and entitlement across channels.

How should we handle taxes and receipts off‑Play?

Your PSP will calculate sales tax in many US jurisdictions, but you still need to configure product tax codes correctly and store receipts in a searchable format. For B2B, add invoice support and company details capture at checkout, and make receipts accessible in‑app under Settings → Billing.

The 30/60/90‑day runbook

30 days:
• Finish the Play financial features declaration for every app in your account so releases aren’t blocked.
• Decide your US monetization path (A/B: Play Billing vs. web checkout).
• Ship 16 KB support for Android 15 targets; verify in App Bundle Explorer.
• Draft US‑only pricing and messaging, including clear cancellation locations.

60 days:
• Roll out web checkout to a US cohort with signed deep links and server‑side entitlements.
• Add fraud controls and refund flows; train support on new edge cases.
• Tune paywall copy and incentives based on cohort performance.

90 days:
• Expand US rollout if KPIs hold (conversion, refund rate, chargebacks).
• Evaluate additional channels (carrier billing, gift cards) where they net positive.
• Run a compliance audit against the newest Play policy language and any fresh program requirements Google publishes.

What this means for product leaders and founders

Zooming out, we’re in a two‑year window where Android monetization strategy is legitimately variable by market. That’s rare. Use it. Build an intentional US channel split, measure take‑rate impact at contribution margin (not just top‑line), and harden entitlement and support workflows so the flexibility doesn’t become tech debt in 2026. Keep your build green by meeting platform requirements quickly—especially the 16 KB page size rule, which is a gate on updates.

If you want an overview of the earlier policy arc and options, read our field guide, a 2025 Play Billing playbook for decision‑makers. If you’re planning a deeper monetization redesign, our product and engineering team can help model the economics and ship the platform work. You can also browse our latest posts on the Bybowu blog or reach out via contact to schedule a working session.

What to do next (today)

• Decide your US billing approach for Q4—Play, web, or hybrid—and write down the criteria to switch if data says so.
• Complete the Play financial features declaration across your app portfolio.
• Rebuild and verify 16 KB page size support for Android 15 targets; don’t wait for a failed rollout to discover a native SDK is out of date.
• Draft compliant in‑app messaging for US users about web pricing and management; add cancellation deep links.
• Stand up a fraud toolkit and a refunds SOP before you take your first off‑Play dollar.

If you execute on those five, you’ll avoid landmines, capture near‑term margin, and keep optionality for whatever Google formalizes between now and November 1, 2027. The window is open—make it count.