On this page · 11 sections
- The three changes, in one table
- What Google actually did to the fee
- The deadline that stops your release
- Apple: the commission lever most teams never pull
- The new price shape nobody is using yet
- What a subscription billing stack actually needs
- India-specific considerations
- How we scope subscription billing work
- FAQ
- How eCorpIT can help
- References
Summary. Subscription economics on mobile changed three times in 2026, and most product teams have absorbed none of them. On 30 June 2026 Google separated its Play service fee from a new 5% billing fee in the United States, the United Kingdom and the European Economic Area, with the service fee starting at 10% on the first $1M in annual earnings and applying to all auto-renewing subscriptions regardless of who processes the payment. On 31 August 2026, 27 days from now, Google stops accepting new apps and updates built on Play Billing Library 7 or lower, with an extension available to 1 November 2026. And on 27 April 2026 Apple shipped monthly subscriptions with a 12-month commitment, a genuinely new price shape available worldwide except the United States and Singapore. Apple's Small Business Program still cuts commission to 15% for developers under $1 million in annual proceeds, and drops to 10% for subscriptions after the first year on the EU alternative terms. Google's billing system covers 195+ markets and 300+ local payment methods, which is the reason most teams stay on it despite the fee. The gap between a subscription stack that survives these changes and one that quietly leaks revenue is not the payment sheet. It is the entitlement layer behind it.
We build that layer. This article is the honest version of what it takes.
The three changes, in one table
| Change | Date | Who it affects | What breaks if you ignore it |
|---|---|---|---|
| Play service fee separated from a 5% billing fee | 30 June 2026 | Apps earning in the US, UK and EEA | Your revenue model still assumes one combined rate |
| Play Billing Library 7 stops accepting new apps and updates | 31 August 2026 | Every Android app selling digital goods | You cannot publish an update at all |
| Apple monthly subscriptions with a 12-month commitment | 27 April 2026 | Apps selling auto-renewable subscriptions outside the US and Singapore | You leave a lower-friction price point unused |
Two of the three are deadlines. The third is an opportunity, and it is the one worth a product conversation.
What Google actually did to the fee
Paul Feng, Vice President, Google Play Eng, Product, UX, described the mechanism plainly on 24 June 2026: "To enable this new level of flexibility, we're separating our service fee from the billing fee."
The practical shape, from Google's own post:
- The service fee starts at 10% on your first $1M in annual earnings, and that 10% also applies to all auto-renewing subscriptions.
- The service fee applies whether you use Google Play's billing system, an alternative billing system, or external web links.
- A billing fee applies only when Google Play processes the transaction. In the US, UK and EEA it is 5%. Google says billing fee details for other markets will be announced later.
- For transactions other than subscriptions and first-$1M earnings, the rate depends on whether the transacting user's first install or first update of your app happened before or after the new structure launched in their region.
- The revamped Games Level Up and the new Apps Experience programmes carry reduced rate cards that become available on 30 September 2026.
The new-install versus existing-install distinction is the part that catches finance teams. Two users paying the same price for the same subscription in the same market can carry different fees based on when they first installed. If your revenue model treats the fee as a constant, it is wrong from 30 June onwards.
We worked the full arithmetic through in our analysis of the Google Play service fee split and what your app actually pays, including the alternative-billing case. The short version for planning: subscriptions are now the best-treated transaction type on Play, which is a reversal of the historical position.
The deadline that stops your release
Fee structure is a spreadsheet problem. Play Billing Library 7 is a release-blocking one.
Google's Play Billing Library deprecation FAQ states that by 31 August 2026 all new apps and updates to existing apps must use Billing Library version 8 or later, with an extension available on request until 1 November 2026. Every Play Billing Library version runs a two-year deprecation cycle, announced at Google I/O 2019.
Two points teams get wrong.
First, this is a publishing gate, not a kill switch. Apps already installed on a device keep transacting on the old library. What stops is your ability to ship anything, which in practice means you cannot fix a bug, respond to a security advisory or hit a seasonal release once the date passes.
Second, the migration is not a version bump. Google's migration guide removes a set of APIs that a lot of subscription logic quietly depends on, and free-trial eligibility checks are the usual casualty. If your app decides whether to show a trial by walking a user's historical purchases, that logic has to be rebuilt against current subscription offer details rather than purchase history. That is a product decision about who gets a free trial, not a refactor, and it needs a product owner in the room.
Google also ships an agent skill for the migration, which is a reasonable accelerator for a well-tested codebase and a bad idea for one without billing tests. Our write-up of the Play Billing Library 8 migration deadline covers the removed APIs individually.
Apple: the commission lever most teams never pull
Apple's App Store Small Business Program reduces commission to 15% on paid apps and In-App Purchases. The eligibility rules are more generous than most founders assume.
- Developers who made up to $1 million USD in proceeds in the prior calendar year across all their apps qualify, and so do developers new to the App Store.
- Proceeds means sales net of Apple's commission and certain taxes and adjustments, not gross revenue, which puts the effective revenue ceiling higher than $1 million.
- If you cross the threshold during the year, the standard rate applies to future sales. If you fall back below it in a later calendar year, you re-qualify the year after.
- You must declare Associated Developer Accounts: accounts you own or control, or that own or control you, defined by majority ownership or ultimate decision-making authority.
- Proceeds are adjusted 15 days after the end of the fiscal month in which enrolment is approved, so enrolling in the middle of a month costs you the rest of it.
Two clauses are worth reading twice. For developers on the alternative terms in the EU who are in the Small Business Program, Apple applies a further reduced commission of 10% for subscriptions after their first year. And developers enrolled in the programme with fewer than two million first-time App Store downloads can use Apple Foundation Models on Private Cloud Compute with no cloud API cost, which changes the build-versus-buy maths on any AI feature you were about to put behind a paid API.
Enrolment requires being the Account Holder in the Apple Developer Program, accepting the latest Paid Apps agreement in App Store Connect, and listing Associated Developer Accounts. It is an afternoon of work for a percentage point swing that dwarfs most growth experiments.
The new price shape nobody is using yet
On 27 April 2026 Apple introduced monthly subscriptions with a 12-month commitment. The subscriber pays monthly but commits to twelve payments, which lets you offer a lower monthly price than an uncommitted plan while capturing annual-plan retention.
The details that matter for a product decision:
- People can cancel at any time, which prevents renewal after they have completed the payments they agreed to. It is a commitment, not a lock-in.
- Subscribers can see completed and remaining payments in their Apple Account, and Apple sends email and optional push reminders before each renewal date.
- You configure the plan in App Store Connect and test it in Xcode today.
- It is available worldwide with the exception of the United States and Singapore, to people on iOS 26.4, iPadOS 26.4, macOS Tahoe 26.4, tvOS 26.4 and visionOS 26.4 or later, shipping with the 26.5 releases in May 2026.
For an Indian consumer app this is the most interesting instrument on the list. The monthly-versus-annual trade-off in India is rarely about discount size; it is about whether a user will part with twelve months of money in one transaction. A committed monthly plan removes that objection while giving you annual-plan revenue recognition and churn behaviour.
The catch is that your entitlement logic has to understand a subscription that is monthly in cash flow and annual in commitment. If your backend treats "paid this month" as the only signal, a mid-commitment payment failure will be handled as a churn event when it should be handled as dunning.
What a subscription billing stack actually needs
Most subscription bugs we get called in for are not payment-sheet bugs. They are state bugs. Here is the architecture we build to, and the failure it prevents.
Server-side entitlement as the single source of truth
The client asks your backend what the user is entitled to. It never decides for itself based on a local receipt. Every platform receipt is validated server-side and reduced to one entitlement record per user, with a plan, a state and an expiry. When a user has an iPhone and an Android tablet, this is the only design that does not produce two contradictory answers.
Both notification streams, consumed and reconciled
App Store Server Notifications and Play's real-time developer notifications both have to land in your system, be idempotent, and be reconciled nightly against the platform's own status APIs. Webhooks get dropped. A nightly reconciliation job is the difference between a support queue and a silent revenue leak.
Explicit handling for the states nobody demos
Grace period, billing retry, refund, revoke, upgrade, downgrade, proration, family sharing, and a paused subscription. Each is a distinct state with distinct access rules. The common production failure is that a refunded user keeps their access because the refund path was never wired.
Trial eligibility computed from current offer data
This is the one the Play Billing 8 migration forces. Compute eligibility from current subscription offer details plus your own record of what a user has already consumed, not from a historical purchase walk that the library no longer exposes.
Price changes treated as a release
Price and tax updates are a recurring platform activity rather than a one-off, and Apple publishes tax and price updates for apps, In-App Purchases and subscriptions on its own schedule. Existing subscribers, new subscribers and users mid-offer have to be handled differently on every change. Put it in the release runbook.
Analytics that measure the right cohort
Report on entitlement-days, not on transaction counts. A committed monthly plan, an annual plan and a monthly plan generate wildly different transaction counts for the same revenue, and any dashboard counting transactions will mislead you about which one is working.
India-specific considerations
Three points for Indian teams and for offshore teams building for overseas publishers.
The Play fee separation started in the United States, the United Kingdom and the European Economic Area on 30 June 2026, and Google says billing fee details for other markets will be announced later on a staggered schedule. Indian developers earning primarily in India are therefore still planning against the earlier structure, and should treat the new one as a scheduled change to model rather than a rumour. If you earn across both India and the US or EU, you are already running two fee regimes at once.
Second, payment method coverage is the reason platform billing keeps winning here. Google's own framing is that its billing system handles taxes, compliance and subscriptions across 195+ markets with 300+ local payment methods. Any plan to move Indian subscription volume to an external payment flow has to reproduce UPI autopay, card mandates and their failure handling, and the recurring-mandate rules are where do-it-yourself billing projects in India usually stall.
Third, App Store Connect now supports localised metadata in 11 additional languages, including Bangla, Gujarati, Kannada, Malayalam, Marathi, Odia, Punjabi, Tamil, Telugu and Urdu, bringing the total to 50. Pricing pages convert on comprehension. If your paywall is English-only in a market where your store listing is not, that is a conversion problem you can fix without engineering.
Where personal data is involved, we design applications aligned with Digital Personal Data Protection Act 2023 requirements, and we keep subscription state and identity data separated so a consent withdrawal does not corrupt a billing record.
How we scope subscription billing work
We are a senior-led engineering organisation in Gurugram, founded in 2021, certified for CMMI Level 5, MSME and ISO 27001:2022, and a partner of AWS, Microsoft and Google. Subscription billing sits across our mobile, backend and data practices, and we scope it in three stages.
Stage 1: the revenue audit
We map every entitlement path in the current app, reconcile a month of platform payouts against your own records, and list the states that are unhandled. This stage usually pays for itself, because the gap between what the stores paid and what the product thinks it sold is where the leak lives.
Stage 2: the platform work
Play Billing Library migration where the 31 August 2026 date is live, StoreKit work on the Apple side, server-side receipt validation, both notification streams, and the reconciliation job. This is the part with a hard deadline attached, so we sequence it first when the date is close.
Stage 3: the pricing surface
Paywall variants, offer configuration including committed monthly plans where they are available, localisation of the pricing page, and the analytics that let you read the result. Pricing experiments without a clean entitlement layer produce numbers you cannot act on, which is why this comes third rather than first.
Who this is for: D2C and consumer apps with an existing subscriber base, SaaS products with a mobile tier, and teams whose Android release is about to be blocked. Who it is not for: a pre-launch app with no users, where a simpler single-plan integration is the right call and a full entitlement service is premature.
Related work sits in our ecommerce app development and fintech and payments app development practices, and the architectural context is in our enterprise mobile app development guide. Teams distributing in the EU should also read our guide to external purchase links with StoreKit on iOS.
FAQ
How eCorpIT can help
eCorpIT builds and repairs subscription billing for mobile products from Gurugram, with senior engineers across iOS, Android and backend working as one team rather than three handovers. We start with the revenue audit, take the Play Billing deadline off your critical path, and leave you with a server-side entitlement layer your growth team can run pricing experiments against. If your Android release is blocked by 31 August or your payouts have stopped matching your dashboard, talk to us and we will scope it in a week.
References
Last updated: 4 August 2026.
