What Google Play Actually Takes, and Alternative Billing in India

Almost always because nobody enrolled — the 15% tier is an opt-in that requires creating an Account Group and accepting a separate set of terms in Play Console, not a rate Google applies to you automatically. This is the single most expensive piece of misinformation in Indian app monetisation, and it costs teams fifteen points of revenue on every transaction until someone notices.

Google's service fees documentation sets out the global schedule plainly. Outside the restructured EEA, UK and US markets it is 15% for the first $1M (USD) revenue earned by the developer each year and 30% for earnings in excess of $1M (USD), with 15% for automatically renewing subscription products purchased by subscribers.

What that page does not do is describe the tier as something that switches itself on. Google's separate note on the 2021 service fee change is where the mechanism lives: developers officially enrol for the 15% service fee tier by creating an Account Group and accepting the terms of service in Play Console. No Account Group, no reduced rate.

Across the 300+ apps we have managed since 2013, this is the most common single reason a monetisation model and a payout statement disagree. The model was built from a blog post quoting the headline rate; the statement reflects an account that never enrolled. Nothing about the product is wrong. The paperwork is.

On a calendar year, pooled across every associated developer account in your Account Group, and once the pool crosses $1M the 30% rate applies to every account in the group for the rest of that year. Each of those three properties surprises somebody, and the pooling one surprises almost everybody.

Google's documentation on the change describes earnings as determined on a calendar year basis, running 1 January to 31 December. That is not your financial year, which for an Indian company almost certainly ends in March. If your monetisation planning runs on an April-to-March cycle, your fee tier does not, and the two calendars will cross in the middle of a quarter.

The pooling rule is the one that changes structural decisions. Where a developer maintains multiple associated developer accounts inside a group, the 15% tier applies as long as the total earnings of all accounts in the group is under $1M, and every account receives the benefit. Once total earnings exceed $1M, the service fee is 30% for all accounts for the rest of the year.

If you are building the unit economics that sit on top of this, our guide to ROAS and CAC for apps and the LTV to CAC calculator both assume you have a defensible net-revenue figure to feed in. This is where that figure comes from, and getting the tier wrong distorts every payback number downstream.

Yes — Google's schedule lists 15% for automatically renewing subscription products purchased by subscribers, stated without a revenue threshold attached to it. That makes subscriptions the only major transaction type on Play where crossing $1M does not change what you pay.

Note the precision of the wording. It covers automatically renewing subscription products purchased by subscribers. A one-time unlock, a consumable, or a non-renewing pass is not that, whatever your marketing calls it. If you are re-architecting a catalogue around this line, the product configuration has to genuinely be an auto-renewing subscription, and the migration work involved is covered in our note on the Play Billing Library 8 migration.

The strategic reading is not that everything should become a subscription. It is that on Play the fee schedule stops penalising subscription revenue for growing, which is a real input into a catalogue decision alongside retention and willingness to pay. We work through the rest of that decision in the app subscription monetisation strategy guide.

Yes, for a narrow set of media apps accepted into a named programme — Google lists 15% or lower for eligible developers who qualify under programmes such as the Play Media Experience Program. It is not a rate you negotiate; it is a programme you apply to and are admitted to, and most apps are not eligible.

The Play Media Experience Program page describes a service fee of 15% for all applicable earnings or lower based on industry, across three media verticals: video, audio and books. Entry is by expressing interest through a submission form rather than by ticking a setting, which is the tell that acceptance is discretionary.

We are deliberately not printing a below-15% figure here. Google's own wording is or lower based on industry, and it publishes no table of what lower resolves to for which vertical. Any specific number you see quoted for this programme has been inferred rather than sourced, and it is not a figure we will put in a model on a client's behalf.

It reduces the service fee by four percentage points on transactions the user chooses to make through your billing system — and it does not remove Google Play's billing system from your app, because you must still offer it alongside. The four points are real. The word alongside is the part that dictates the engineering.

Google's page on billing requirements for developers serving users in India is explicit on both halves. It describes offering all developers the ability to offer an alternative billing system alongside Google Play's, and states that if a user pays through an alternative billing system, the Google Play service fee will be reduced by 4%. Eligibility is framed as an app or game offering alternative billing to mobile and tablet users in India.

Carry those conditions with the number every time you quote it, because each one narrows it:

• The reduction is 4 percentage points off the fee that would otherwise apply, not a flat rate. An enrolled developer under the threshold moves from 15% to 11%; the same developer above $1M moves from 30% to 26%; an auto-renewing subscription moves from 15% to 11%.
• It applies only to transactions the user actually routes through your system. Anything paid through Play's billing system is charged at the ordinary rate. You are not converting your whole revenue line, you are converting the share of users who pick the other option.
• It applies to mobile and tablet users in India under this programme. It is not a global fee reduction, and a separate programme with its own terms exists for South Korea, where Google uses the same language: the service fee will be reduced by 4%.
• Google Play's billing system stays. Google's position on the India page is that users should have the choice to use Play's billing system when they make a digital goods purchase from apps installed from Google Play. Removing it is not one of the options.

An enrolment, a certification, a payment integration, a fraud-reporting path and a transaction-reporting obligation measured in hours — the four points are payment for compliance work, not a discount for asking. Reading the requirement list is the fastest way to work out whether the programme is worth it for your volume.

Google's India page describes the onboarding sequence, and it is longer than teams expect:

There is also a cost you now carry that Google was previously carrying. Running your own billing means you pay a payment gateway, absorb failed-payment and refund handling, take on chargeback exposure, and support users through a checkout Google no longer operates. We are not going to print a percentage for Indian gateway pricing here — the rates vary by instrument, by negotiated contract and by whether the payment is a card, a UPI collect or an autopay mandate, and there is no primary source that would make a single published figure honest. Get quotes for your own mix.

That is not a hedge; it is the whole decision. If your own processing and operational cost lands close to four points, the programme is administrative overhead with no margin attached. If it lands well under four points and your volume is meaningful, it pays. Our work on UPI AutoPay for app subscriptions covers the recurring-payment mechanics you would be taking ownership of in India.

Only if your fully loaded cost of running payments yourself is comfortably below four percentage points of gross transaction value, on the share of transactions users actually route away from Play. Both halves of that sentence have to be true, and teams usually test only the first.

Work the arithmetic on the published rates. An enrolled developer under the $1M threshold pays 15% through Play's billing system and 11% through an alternative system, so the gross improvement is four points. Against that, set every cost Play's fee previously covered on your behalf, and the share of users who will actually choose the alternative.

The adoption share is the variable nobody can hand you. Google requires that Play's billing system remains available and that the choice is presented legibly, so you cannot design a flow that steers users. Whatever proportion of users selects your option is an empirical result of your specific checkout, and we will not publish a benchmark for it, because any number we have seen is a single client's mix rather than a market rate. Measure it yourself, on your own users, before you extrapolate a saving.

There is a second-order effect worth pricing in as risk rather than as a number. Any additional payment step is a place where conversion can fall, and a four-point fee saving is wiped out by a checkout that converts materially worse than Play's. Run it as a controlled experiment, with your testing tooling instrumented on completion rate and not just on the fee line.

Those three markets have moved to a separate schedule that splits the charge into a service fee plus a distinct 5% billing fee, and treats transactions differently depending on whether the install predates 30 June 2026. India is not part of it, and a model built on the new structure will misprice Indian revenue.

The structural features Google documents on the service fees page are worth understanding even if you do not sell in those markets, because they signal where the pricing architecture is heading:

• The charge is unbundled. Instead of one blended percentage, the schedule presents a service fee alongside a separate 5% billing fee for transactions processed through Play's billing system.
• Installs are classified by date. The schedule distinguishes New Installs, where the first install or update happened on or after 30 June 2026, from Existing Installs that predate it, and charges them differently.
• Routing to an external web link carries a lower rate than the equivalent in-app transaction on the same install class.
• Programme enrolment still moves the rate, with distinct rows for developers in Google's games and apps experience programmes.

For an Indian developer the practical guidance is narrower and clearer. If your revenue comes from Indian users, the 15%/30% schedule and the 4% alternative billing reduction are your numbers. If you also sell into the EEA, UK or US, you now maintain two fee models rather than one, and your blended take rate depends on your geographic mix. Teams running purchasing-power-based price localisation across regions should recheck their margin assumptions market by market rather than applying one global figure.

Purchases of physical goods and physical services, utility and telecommunications bill payments, peer-to-peer transfers, online auctions and tax-exempt donations are not required to use Google Play's billing system — and what does not go through it is not charged a service fee on it. For a large share of Indian apps this is the most consequential paragraph in the whole payments policy.

Google's payments policy requires Play's billing system for paid app downloads and for in-app purchases of digital goods: virtual items such as currencies and extra lives, subscription services covering categories like fitness, gaming, dating, education, music and video, app functionality such as ad-free versions and new features, and cloud services such as data storage and productivity software.

It then sets out categories where Play's billing system is not required, including physical goods such as groceries, clothing and electronics; physical services such as transportation, cleaning, airfare, gym memberships, food delivery and event tickets; payment of utility bills including cable and telecommunications; peer-to-peer transactions and online auctions; and tax-exempt donations.

The genuinely useful application of this section is a categorisation exercise. Take every SKU you sell and place it on the correct side of the line, using the policy's own categories rather than your product taxonomy. In our portfolio, commerce, travel and services apps frequently find that most of their transaction volume was never subject to a Play service fee at all, and that the fee anxiety driving the conversation applies only to a small digital-goods tail. That changes what the monetisation work should be, and our monetisation playbook starts from that split.

Establish your enrolment status, classify your SKUs, forecast the calendar-year threshold at group level, and only then evaluate alternative billing as an incremental decision on the transactions that remain. Run in that order and most teams discover the biggest win is administrative rather than architectural.

The pattern we see repeatedly is a team spending a quarter scoping an alternative billing integration while sitting on an unenrolled account paying 30% on revenue that should have been charged at 15%. The integration might eventually be right for them. The enrolment was right for them on day one and cost nothing.

Everything above comes from Google's own published pages, and those pages change — the EEA, UK and US restructure is proof that they change materially. Re-read the service fees page before any planning cycle in which the fee is a load-bearing assumption, and treat any percentage you find in a secondary source, including this one, as something to verify rather than to model on. If you want help building the net-revenue model that sits underneath all of this, our monetisation practice does exactly that work.