Re-cost your Android take-home before Oct 1: four decisions that decide your real margin

The fee cut is a re-cost, not a discount

The 2026 Google Play fee schedule turns a familiar cost into a re-costing exercise. If app revenue is already part of your model, the question is not whether the fee changed. It is what your net take-home becomes after the change.

From June 30, 2026, developers in the US, the European Economic Area, and the UK can pay a 10% service fee on the first $1 million of annual revenue. The same 10% rate applies to auto-renewing subscriptions. The same schedule sets non-recurring fees at 20% for new installs and 25% for existing installs.

In the US, UK, and EEA, the extra 5% billing surcharge follows Google's payment methods. Alternative methods and external links skip it, but their processors still take a cut. In that same revenue tier, Google Play alternative billing can cost 10% to Google plus roughly 4% to your processor, while staying on Google Play can run about 15% total.

The re-cost is a spreadsheet, not a guess

Start with the revenue you already know. Split it by install cohort, by purchase type, and by payment path. Do not average the fee across the whole app. A blended rate can make a bad segment look acceptable and a good segment look risky.

For each segment, write down the gross revenue, the service fee, the billing surcharge if any, and the processor fee if you use one. The number you care about is the amount left after all of those lines, not the fee alone.

Keep the old fee schedule next to the new one. The delta is the number to defend. If the gap is small, the operational cost of changing payment methods may outweigh it. If the gap is large, the operational cost may be the cheaper mistake.

A fee change only matters when it changes the decision. If your app is subscription-heavy, the lower recurring rate may do most of the work. If it is one-time purchases, the new-install and existing-install split can move the number more than the subscription segment. If it is a mix, you need the mix, not the average.

The decisions are the margin

Each item below is a quick test. The aim is to turn the schedule into a number you can defend.

1. Recompute net take-home by tier, not by blended average.
2. Compare the platform billing method with alternative billing for the tier where the gap is largest.
3. Validate lower-rate program enrollment: Google's revamped Apps Experience and Games Level Up programs, which are enrollment-based fee programs, require enrollment for 15% new-install and 20% existing-install non-recurring fees.
4. Kill or reprice link-outs: a purchase made within 24 hours of an in-app link-out carries a 20% service fee.

Where the margin actually hides

In the US, UK, EEA, and Australia, the lower-rate card lands on September 30, 2026. If your revenue is concentrated in a region that arrives later, do not build the model around a rate you cannot yet claim. Japan and South Korea get the lower-rate card on December 31, 2026, and the remaining regions on September 30, 2027.

Alternative billing changes the fee, but it also changes the work. You own more of the checkout, the refund path, and the processor relationship. That can be worth it when the gap is large enough. It can also cost more than it saves when volume is thin.

Processor fees are the part founders often leave blank. A lower platform fee can disappear if the alternative method is expensive, if chargebacks are high, or if the checkout conversion drops. Put the processor number in the model before you sign up for anything.

Program enrollment is the same. A lower rate is only real if the app qualifies and the region is live. If the app is close to the requirements, the enrollment work may be worth it. If it is far away, the rate is a future number, not a current one.

Link-outs are the easiest item to miss. If your flow pushes users to a web checkout, the fee may follow the click. If it does not, the link-out may be a margin problem you can close before the new schedule takes hold.