Google Play's US Billing Rules: Reporting Deadlines for Founders

If you take payments inside an Android app and you have started steering US users to your own checkout, Google Play alternative billing and external content links just stopped being a pure margin story. Google's Play Console help page for developer policy updates now carries two dated notices that matter to you.

• July 22, 2026: developers enrolled in the external content links and alternative billing programs in the US need to report transactions and pay the relevant service fees starting on October 1, 2026.
• September 17, 2026: developers enrolled in external content links now have until December 1, 2026 to report successful downloads and pay the relevant service fees.

Read those two lines twice, because they are not the same rule. Alternative billing keeps the October 1 start as far as I can tell from Google's page. External content links got a longer runway, to December 1. The page does not say the extension covers alternative billing, so do not assume it does.

One more thing I want to be upfront about. Google's page does not spell out the fee percentages in those notices, and it does not define what counts as a reportable transaction or a successful download. Those details live on the program pages the notices link to. Every fee figure you see quoted on social media should be checked against those pages before it goes into a spreadsheet. I am not going to quote percentages here, because I would be guessing, and a guess is a bad input to a pricing decision.

The names sound alike and they describe different things. Mixing them up is how teams end up building the wrong integration.

Alternative billing

Google describes this as available to eligible developers serving US users. Inside your app, you offer your own payment system as a choice next to Google Play's billing, or instead of it for some purchases. The user stays in your app. You process the payment with Stripe, Adyen, Braintree or whoever you already use. Because the sale happens in your app, Google can see that it happened and wants a report.

External content links

Google describes this as a program for developers who link US users to external content. You send people out of the app to your website, usually to buy something or sign up. The money moves on your site. Google's reporting notice for this program refers to successful downloads, which tells me the fee logic attaches to the app install that led to a purchase and not only to a card charge. The exact mechanics are on the program page, so read them before you design anything around that assumption.

Which one you probably need

If your product is a subscription with a clean web signup, such as a SaaS tool with a companion app, external content links is usually the simpler fit, because the checkout already exists. If you sell consumable digital goods inside a game or a creator app and the user never wants to leave, alternative billing is the closer match. If you use neither, nothing in these notices applies to you today, and you can skip to the last section.

For a wider look at how these store rules fit together, our guide to alternative app stores under the DMA covers the European side of the same fight. The US rules and the EU rules are separate programs with separate terms, and a plan for one does not carry over to the other.

Founders hear "report transactions" and file it under finance. Then October 1 arrives and nobody can produce the report, because the data was never captured in a form that matches what Google wants.

Think about what you need to answer. Which purchases happened through the alternative path and which went through Google Play billing? Which downloads led to an external purchase? Which of those were refunded, charged back or cancelled inside a grace period? Each answer has to come from your own systems, because Google cannot see a Stripe charge on your server and you cannot see theirs without wiring it up.

Here is what that typically means in practice for a mobile app with a backend:

• Every purchase record carries a source field: Google Play billing, alternative billing, or external link. If your orders table has no such column, add one now and backfill what you can.
• Every external purchase carries an attribution reference tying it to the app install or session that sent the user out. Without it, the "successful download" reporting in the external links program is guesswork.
• Refunds and chargebacks update the same record, so your reports net them out correctly.
• Subscription renewals are tracked as separate events from the first purchase. Whether a renewal counts as a reportable transaction is a question for the program terms, and your data model should let you answer it either way.
• You can export all of it for a date range without a developer running ad hoc SQL.

That last bullet is the one that saves you. A report you can only produce by pulling an engineer off the roadmap is a report that gets produced late.

This is a small project for most apps and an annoying one for apps with messy payment history. Here are my estimates from scoping similar work, not a quote and not a benchmark. Your numbers move with how many payment paths you already run.

Apps that already use only Google Play billing

If you are on Google Play billing alone and have not enrolled in either program, you do nothing. The notices do not apply. Do not build a web checkout because a competitor did. The case for leaving Play billing is a margin case, and it has to survive the extra support load, the fraud exposure and the fees you may still owe.

Apps already enrolled with a clean data model

A clean orders table, a source field and a refund webhook means a few days of engineering to build a reconciliation export and test it against a month of data. Budget roughly $3,000 to $8,000 if you are paying an agency or a contractor for it, or a week of an internal engineer.

Apps enrolled with a messy data model

If purchases from three payment paths land in one table with no source marker, you have a data cleanup before you have a report. That runs two to four weeks of work and $10,000 to $25,000 at agency rates. Most of it is reading old code and reconciling old records, not writing new features.

The cost nobody budgets

Someone has to check the report against what Google bills you each period and chase the differences. That is a recurring finance task, an hour or two a month once it works and a lot more the first three months. Name the person now. Our guide to mobile app monetization strategies covers where payment operations fit in the broader revenue picture.

The usual pitch for these programs is lower fees. Sometimes that holds and sometimes it does not, and the reporting deadline is a good moment to check, because the program now has a paper trail attached.

Build a simple comparison for your own app. Take last quarter's gross revenue from US Android users and run it through three columns:

1. Google Play billing: the commission you pay today at your current tier.
2. Alternative billing or external links: the service fee under the program terms you read on Google's page, plus your processor's cut, plus the cost of the engineering above.
3. The cost of friction: the share of users who drop off when they leave the app to pay or when they see an unfamiliar checkout.

The third column is the one people leave out, and it is usually the largest. A web checkout converts worse than a one-tap native purchase for impulse buys. It converts about as well for a considered purchase like an annual plan, where the user already trusts you. If most of your revenue is the second kind, the savings are real. If most is the first kind, a few points of conversion can erase the fee gap.

Card processors charge their own fees on the external path, commonly in the range of 2.9 percent plus a fixed amount per charge for US cards through the big processors, though your rate depends on your volume and contract. On the Google Play path you do not pay that separately. Compare all-in costs, not headline rates.

Smaller developers should be especially careful. If you already qualify for a reduced commission tier on Play, the gap you are chasing may be smaller than it looks, and the engineering and reporting work does not shrink with your revenue. A fixed cost of a few thousand dollars against a modest fee saving is a bad trade for an app earning $5,000 a month.

Here is the order I would work in, whether you are enrolled or only considering it.

1. Find out if you are enrolled. Open Play Console and check your program status. Teams sometimes forget a pilot someone started a year ago. If you are enrolled and did not know it, you already have an obligation.
2. Read the two program pages end to end. The fee rates, the definition of a reportable event, the reporting format and the payment schedule all live there. Put the key terms in a one-page internal note with links, so the next person does not repeat the research.
3. Audit your purchase data. Pull a month of US Android purchases and check whether you can label each one by path. If you cannot, fix the schema first.
4. Build the export. One query or one admin button that outputs every reportable event for a date range, with refunds netted out. Test it against your own payment processor's totals.
5. Set up a monthly reconciliation. Compare your report with Google's statement. Differences under a threshold you pick get noted, bigger ones get investigated the same week.
6. Tell finance. The fees are a new cost line. Your accountant needs to know what it is called and when it posts.

If you are enrolled in alternative billing, treat October 1 as already behind you and confirm you are reporting. If you are in external content links, December 1 is the date Google gave, and it is a short runway given holidays, code freezes and the usual end-of-year launch rush. Pick a build date in early November so a failed test does not land in December.

The dates are the visible part. Here are the quieter ways this goes wrong.

Policy drift

Store payment rules in the US have changed several times in recent years and the notices on this page show Google adjusting dates mid-stream, as the September extension proves. Build your reporting so the rules live in configuration and not in scattered code. When a fee rate or a definition changes, you want one place to edit.

Support and refund load

Once payment happens outside Google Play, refunds are yours. Google will not issue them. Users used to Play's refund flow will email you, and a slow reply turns into a chargeback. Plan for a refund policy, a support macro and someone who can act on it in a day.

Fraud and abuse

Play billing absorbs a lot of card fraud on your behalf. On your own checkout, you take it on. Use your processor's fraud tooling, such as Stripe Radar, and set sensible limits on new accounts. Our write-up on Stripe Billing versus Orb and Metronome shows how the billing layer you choose changes how much of this you can see.

App review friction

Store review can reject an app that mishandles the link flow, the disclosure text or the pricing display. A rejection on release week costs more than any fee difference. Our app store rejection guide walks through the common causes, and the habit it recommends is to test the exact flow on a fresh install before you submit.

Cross-store inconsistency

Apple has its own rules, which differ from Google's. If your iOS and Android apps show different prices or different payment options, support tickets and app reviews will point it out. Decide on one pricing story and apply each store's rules around it.

Let me sort founders into groups, because the right move differs.

You use only Google Play billing and have never enrolled. Do nothing. Nothing in Google's notices changes your obligations. Revisit the question when you have a reason, such as a large revenue share from US Android users and a team with spare capacity to run a web checkout well.

You are enrolled in alternative billing. You are the group on the clock. Confirm that reporting began on October 1, confirm that you can produce the data and find out what you owe for the period since. If you cannot produce it, an honest note to Google beats silence, and a quick engineering sprint beats both.

You are enrolled in external content links. You have until December 1 to report successful downloads and pay the relevant fees. Use the extra weeks to get attribution right, because the install-to-purchase link is the part most likely to be thin in your data.

You are considering enrolling. Run the margin comparison from above with real numbers before you write a line of code. Then price in the reporting work as part of the project from day one, not as a surprise in month three.

You build on a no-code or vibe-coded stack. Check whether your purchase records can carry a source field at all. Many quickly assembled payment setups store one row per charge with no link to the app session. That is fine until a deadline asks you to prove where a sale came from. If your data model cannot be fixed in place, that is a sign it is time to harden the backend, and the cost guide for subscription consumer apps gives realistic ranges for the billing work.

A last piece of advice. Store payment rules reward teams that keep their billing data tidy and punish teams that treat it as an afterthought. If you want a second pair of eyes on your payment architecture, your purchase schema or the margin math for your app, book a free strategy call.