Google Play External Links: Ship for Jan 28 (U.S.)

January 28, 2026 is the date to circle if you intend to use Google Play external links in the United States. If your app will send users to a web checkout or to download a separate app, you must enroll in Google’s new programs, implement a specific information screen, and report transactions and installs. The fees and mechanics differ depending on whether you use external links or alternative billing inside your app—and that’s where teams are stumbling. Let’s make this simple, shippable, and financially sane.

What changed—and why January 28 matters

Following a U.S. court order and subsequent policy changes, Google created two formal U.S. programs for apps distributed through Play:

• External content links: You can link users from your Play‑distributed app to a web page to buy digital content or even to a destination where they can download another app. You must show Google’s required information screen before linking out, register external apps and URLs, and report installs and purchases that result from those links.

• Alternative billing (within the app): You can present a non‑Google payment option alongside Google Play Billing. You must integrate the alternative billing APIs, show Google’s mandated information dialog, and report transactions.

Google’s policy announcement set January 28, 2026 as the U.S. compliance date for anyone who wants to continue linking out or using alternative billing. There’s also an evidentiary hearing scheduled for January 22, 2026 that could influence fee details later this month. Translation: your engineering work has to land now, with toggles ready to adapt to fee finalization after the hearing.

The fee picture in plain English

Here’s the thing: you’re making product calls that impact margin. Some numbers are locked; others are publicly proposed and may firm up after the court hearing. Build your finance model with scenario toggles.

Alternative billing (inside your app): the official rates

For U.S. users, if you offer an alternative payment option in addition to Google Play Billing, Google’s published service fee is 25% for most in‑app digital purchases and 10% for auto‑renewing subscriptions, with a 10% rate on the first $1M in annual developer earnings for eligible developers. The required Alternative Billing APIs handle the one‑time information screen, parental controls, and transaction reporting. This is live policy—you should treat it as a given when modeling.

External links (to web purchases or external app downloads): what’s announced vs. proposed

For external links, you must enroll, show the information screen, register destinations, and report installs and transactions. Google has publicly outlined intent to charge service fees on off‑Play purchases (commonly discussed as 20% for most non‑subscription items and 10% for auto‑renewing subscriptions) and to apply a fixed per‑install fee when a user downloads an external app within a short window after clicking your in‑app link. Reporting in December indicated U.S. fixed fees of roughly $2.85 per app install and $3.65 per game install in that window. As of mid‑January, those per‑install fees and the external‑link purchase rates are framed as Google’s plan; enforcement timing could be clarified after the January 22 hearing. Practically: implement the APIs and reporting now and model a conservative scenario so your CAC/LTV math still works if the proposed fees hold.

Ship the UX: exactly what to build

Compliance isn’t just a checkbox. There’s concrete UX and plumbing you need to ship—and QA hard—before you send even one user out of your app.

1) Enrollment and declarations: In Play Console, enroll in the External Content Links program if you’ll link out, and/or enroll in Alternative Billing if you’ll take payments inside the app with a non‑Google processor. Declare every external destination. For downloads, register each external app package and upload new versions for review before you link to them.

2) Information screen: Before any outbound link to a purchase page or an app download, show Google’s required information screen. It must clearly state that the destination isn’t Google Play, and that different terms and payment protections apply. Don’t hack around it; implement the official API.

3) Token handoff: Generate and pass tokens when you send the user out of the app, then receive and reconcile them server‑side so you can report installs and transactions tied to those clicks. Treat this like payments-grade telemetry—idempotent, signed, and retriable.

4) Reporting within 24 hours: Report qualifying off‑Play transactions (including $0 trials where required) and eligible installs that occur after the link click within the specified time window. Build resumable batch jobs so you never miss a report if your analytics vendor hiccups.

5) Parental controls and supervised users: Alternative Billing APIs interface with parental controls. Test your flows with supervised accounts; missing this is a classic last‑minute rejection cause.

6) A kill switch: If the hearing shifts fees or language, you don’t want to rush a hotfix. Ship a remote‑config kill switch to disable external links or switch pricing logic by market, SKU, and funnel.

Google Play external links: the LINKS rollout framework

I’ve used this with multiple teams to land changes on time without wrecking conversion. It’s pragmatic and audit‑ready.

L — Layout: Inventory every in‑app path that can reasonably lead to a purchase or download. Map the screens and microcopy where the information dialog will appear. Decide webview vs. browser for purchase destinations based on your PCI posture and SSO.

I — Interstitial: Implement Google’s mandated information dialog verbatim and instrument click‑through and abandonment. Keep your own explanatory copy minimal to avoid confusing users or implying Google backs the destination.

N — Network: Build the token handoff and server‑side verification. Hash PII out of URLs. Use HMAC signatures on payloads. Log every outbound link with a correlation ID to match the install or purchase later.

K — Keys & compliance: Register external apps, declare all destinations, and store proof of approval. Document your reporting job schedules and retention. Your compliance narrative should be easy to produce during review.

S — Switches: Add feature flags per region, SKU, and funnel. Be able to pause external downloads, keep web checkout, or vice versa, in minutes—not days.

Unit economics: model it before you ship it

Let’s get practical. Say you run a U.S. game with a starter pack at $9.99, and you’ll use both external links to a web shop and alternative billing inside the app.

Scenario A (Alternative Billing in‑app): A user buys the $9.99 pack via your processor through the alternative billing flow. Your Google fee is 25% for that purchase. If it’s a subscription renewal instead, model 10%. Also include your processor take (e.g., 2.9% + $0.30) and fraud/chargeback reserve if you keep one.

Scenario B (External link to web purchase): The same $9.99 pack, but the user clicks an in‑app link to your website and completes the purchase there. Model Google’s service fee at 20% if enforced for non‑subscription items, or 10% for auto‑renewing subscriptions. Add your payment processor fee.

Scenario C (External app download): Your Play‑listed app links the user to download an external companion app. If the install completes within the defined window after the click, model a fixed per‑install fee. December reporting pointed to roughly $2.85 per app install and $3.65 per game install in the U.S. Treat these as proposed rates subject to finalization; run sensitivity at 0.75×, 1.0×, and 1.25× of those figures.

Tip: maintain a simple sheet by funnel (Play IAP vs. Alternative Billing vs. External Link), by country, and by SKU. Add a slider for “fee enforcement date” on external links so you can forecast cash impact if enforcement kicks in mid‑Q1. You’ll thank yourself at board review.

People also ask

Do I have to enroll if I’m just linking to a help page?

If the destination has no purchase or download path, you’re typically outside the program. But many “support” pages embed shops or link onward. If a reasonable path to purchase or download exists, enroll and implement the required flow. Also, keep PII out of query strings.

Can I show only my own payment method and hide Google Play Billing?

For the U.S. alternative billing program, most apps must present Google’s option alongside your own. There are region‑specific exceptions elsewhere, but don’t assume they apply in the U.S.; check eligibility in Play Console before you refactor checkout.

How will Google know an external install came from my link?

Through the token handoff and your required reporting. You’ll pass tokens when users click the link; your server reports qualifying installs and transactions within the time window. Keep these calls idempotent and retriable.

What happens if I miss January 28?

Your app can remain on Play if you don’t use external links or alternative billing. But if you do either without enrollment and the required UX/reporting, expect policy rejections or takedowns. That’s why a kill switch is non‑negotiable.

Edge cases and gotchas (learned the hard way)

• Seven‑day review risk: Registering external apps for download links can take up to a week (longer in edge cases). Don’t cut it close—queue submissions now and track status daily.
• Supervised accounts: If you ignore parental controls interactions with alternative billing, you invite rejections. Test supervised user flows on multiple devices.
• Redirect chains: Your outbound link should land exactly where your dialog says it will. Avoid marketing redirect services that change the final URL based on user agent; you’ll get flagged.
• URL hygiene: Never stuff PII into the link (email, phone, name). Use server‑side retrieval keyed by signed tokens.
• Refunds: Your support team owns refunds for your off‑Play purchases. Create macros, SLAs, and a process to reconcile with your reporting to Google.

Cross‑store reality check

While you’re building for January 28 on Android, don’t ignore iOS. Apple’s updated age rating system is now live across iOS 26, iPadOS 26, macOS Tahoe 26, tvOS 26, watchOS 26, and visionOS 26, and Apple asked developers to complete the new questionnaire by January 31, 2026. If your product targets families or user‑generated content, finish that paperwork this week. Our App Store age rating checklist walks through the steps and edge cases.

What to do this week

1) Decide your posture: Will you link out, use alternative billing, both, or neither? If you plan to do either, enroll today.
2) Implement the information screen and token handoff: Use official APIs; don’t roll your own dialog.
3) Build server‑side reporting: Idempotent endpoints, retries, and reconciliation dashboards. Treat this like revenue reporting—not marketing analytics.
4) Register external apps and URLs: Submit early to absorb the review window.
5) Model the fees: Add scenarios for enforcement timing and proposed U.S. per‑install rates. Share a simple sheet with Product and Finance.
6) Ship flags and a kill switch: Be able to change course without a client update.
7) QA supervised, enterprise, and bad‑network flows: Don’t ship happy‑path only.

When external links make sense—and when they don’t

External links are worth it if you can drive a materially higher checkout conversion on the web, unlock bundles and merchandising you can’t do in‑app, or improve retention by letting users manage subscriptions outside Play. They make less sense if your price point is low, your payment mix is card‑heavy with high declines, or if the proposed per‑install fee would crush early funnel experiments. Games should be especially cautious; fixed per‑install fees for game downloads are higher than for non‑game apps and can swing your UA math.

A pragmatic rollout path

Here’s a sequence we’ve used successfully for consumer apps and games:

• Phase 1 (days 1–3): Enroll, implement the information screen, wire token issuance on click, and stand up a simple reporting API endpoint. Register your external app if you’ll link to downloads.
• Phase 2 (days 4–7): Finish server reconciliation and idempotency, add BI dashboards for link clicks → installs → purchases, and test supervised flows. Prepare support macros and refund tooling.
• Phase 3 (days 8–10): Stage rollout to 5%, then 25%, watching abandonment at the dialog and conversion on the web. Tune copy, keep promises tight, and make redirects boring.
• Phase 4 (days 11–14): Expand to 50–100% if metrics hold. Turn on A/B pricing tests behind flags. Lock reporting runbooks and ownership.

Need a deeper dive?

If you want fee modeling templates and flow diagrams you can drop into a spec, see our hands‑on explainer covering U.S. fees and integration details in Ship the flow and model the fees, plus our scenario planning guide in Fees and plan for external links. If you’d rather have a team build the plumbing, our services overview shows how we handle policy‑driven changes without derailing your roadmap.

Bottom line

January 28 isn’t a theoretical deadline. If you want to use Google Play external links or alternative billing in the U.S., you’ve got concrete code to ship and real economics to model. The compliance pieces—information screen, registration, reporting—are straightforward if you assign them today and test like you mean it. Keep pricing and fee logic behind flags so you can pivot after the late‑January hearing without a scramble. Do that, and you’ll be able to steer users where it makes sense, protect margin, and sleep at night.