Google Play's Involuntary Churn Rate Is Double the App Store's — And Most Android Apps Still Run the Defaults
Nearly a third of Google Play cancellations are billing errors, not decisions. Google doubled the recovery window in Dec 2025 — most apps never touched it.
A subscription that disappears on Android usually didn't get cancelled at all. Somebody's card expired, or a bank flagged an unfamiliar renewal, and nobody — not the subscriber, not your product — ever made a decision about it. That failure mode happens on Google Play at roughly double the rate it happens on Apple's App Store, and the gap isn't about Android users being flakier with their cards. It's mostly about a handful of Play Console settings that most teams configure once, at launch, and never look at again.
We've written before about how involuntary churn hides inside numbers that look like voluntary loss, and how Apple's App Store has historically kept developers away from their own cancel button entirely. Google Play sits in a strange middle ground: it hands developers far more control over the recovery process than Apple ever has, and most of that control goes unused. The result is a platform where the fix is sitting in a settings panel, not locked behind a court case.
Why Android loses more subscribers to billing errors than iOS
RevenueCat's State of Subscription Apps 2026 report, drawn from more than 115,000 apps and $16 billion in tracked subscription revenue, breaks cancellations into two buckets on each platform: voluntary unsubscribes and billing errors. On the App Store, roughly 83% of cancellations are voluntary and about 15% are billing errors — an expired card, a decline, a failed retry. On Google Play, voluntary cancellations run closer to 66%, and billing errors account for around 32% — more than double Apple's rate, on a platform that, on paper, gives developers more tools to prevent exactly this outcome.
The gap isn't really about payment method mix or card quality. It's about what each platform does automatically versus what it leaves for the developer to configure. Apple's dunning behavior on IAP is largely fixed and opaque from the developer's side. Google Play's is genuinely configurable — grace periods, account hold duration, and real-time notifications you can act on — which means the businesses using the defaults and the businesses actively tuning the system end up with meaningfully different churn numbers, even selling the exact same product.
There's also a structural reason billing failures skew higher on Android specifically: a larger share of Google Play's global user base pays with prepaid cards, carrier billing, and debit rails that fail more often on a recurring charge than a Visa or Mastercard credit line does — insufficient funds and expired cards both bite harder on a payment method with no revolving credit behind it. That's a demand-side factor Play Console settings can't touch directly, which is exactly why the recovery window matters more on Android than it would on a platform where most renewals clear on the first attempt anyway. A longer retry window doesn't fix why a payment failed. It just gives more of those payments time to succeed on a second or third try, which for insufficient-funds failures often just means waiting for the subscriber's next payday to arrive.
Three states that are not "cancelled," and one that is
The most common integration mistake on Android isn't a missing feature — it's a data modeling error. Teams wire up a webhook handler, see a status change on a subscription, and write it to their database as cancelled without checking which of four very different states actually fired.
| State | What the subscriber experiences | What Google Play is doing | Is it churn? |
|---|---|---|---|
| Grace period | Keeps full access, sees a payment-issue prompt in the Play Store app | Retrying the failed payment in the background on its own schedule | No — fully recoverable |
| Account hold | Access suspended, subscription still listed as active in Play | Still retrying payment; nothing has been cancelled yet | No — recoverable until account hold expires |
| Paused | Access suspended by the subscriber's own choice, not a billing issue | Not billing at all; resumes automatically on the date the subscriber set | No — a deliberate, temporary opt-out |
| Cancelled / expired | No access, subscriber must resubscribe from scratch | Billing has stopped entirely; the subscription record is closed | Yes — this is the only true churn event |
Collapsing these into one bucket costs you twice. Treat grace period or account hold as churn, and your involuntary churn number is inflated and your recovery efforts look weaker than they are. Treat a real cancellation as still active, and you keep granting access — or worse, keep reporting revenue — on a subscription that's actually gone. Both mistakes are common because Google Play's default webhook payloads require you to branch on the specific notification type rather than handing you a single clean "still paying / not still paying" flag.
The recovery window Google doubled, and most apps never touched
Grace period and account hold aren't cosmetic labels — they're a configurable retry budget, and until recently most developers were running on a default that Google itself has since decided was too short. Effective December 1, 2025, Google Play changed how it calculates the default account hold duration: instead of a flat 30 days, it's now 60 days minus whatever grace period you've set, with a combined floor of 30 days across both states. Apps that had account hold sitting at the old default were migrated automatically — no action required, but also no guarantee anyone on the team noticed the change or checked whether their own grace-period setting was eating into the new, longer window.
Google's own reporting on the rollout, covered alongside the Play Billing Library 9.0 announcements at I/O 2026, put real numbers on what the longer window did for developers who had it: involuntary churn fell by up to 18% among top developers, and total churn dropped 9%. That's not a marginal tuning gain — that's roughly a fifth of involuntary churn recovered by extending a retry window that most teams never customized in the first place.
Source: Google Play internal data on grace period / account hold configuration, and Google's published Truecaller case study, both as reported alongside I/O 2026 Play Billing coverage.
That first bar is the one worth sitting with. Correctly configuring two settings that already exist in every Play Console account — no new SDK, no new API integration — roughly triples the share of billing declines you recover, from about 10% to about 33%. Layering in your own recovery messaging, timed off Google's real-time notifications instead of waiting on Play's generic in-store prompt, pushed one developer to 40%. None of this requires the kind of engineering lift that moving off a platform's native billing entirely does — it's closer to un-ignoring a setting.
What "correctly configured" actually means in Play Console
- Set a grace period that matches your billing cycle, not a default. A weekly subscription doesn't need the same grace period as an annual one — Google's own guidance scales the recommended window with billing frequency, and a grace period that's too short for a monthly or annual plan just shifts more of your recovery budget into account hold, where access is already suspended.
- Confirm account hold is actually enabled and check its current duration. The December 2025 formula change was automatic, but "automatic" doesn't mean "verified" — pull up the current setting in Play Console rather than assuming the migration landed the way you expect.
- Wire your backend to Real-Time Developer Notifications, not just purchase state polling. RTDN fires distinct notification types for a subscription entering grace period, entering account hold, recovering, or actually cancelling. If your integration only checks whether an entitlement is currently active, you can't tell a subscriber in a recoverable hold from one who is genuinely gone.
- Send your own recovery messaging during grace period, don't rely on Play's default prompt alone. The subscriber is still inside your app's entitlement window at that point — an in-app banner or push notification pointing directly at updating payment details reaches people who never open the Play Store app to see its generic message.
- Tag developer-initiated cancellations separately from user-initiated ones. The Play Developer API's subscription cancellation endpoint distinguishes a cancellation the subscriber requested from one your own systems triggered — refund policy enforcement, fraud, a plan being sunset. Mixing these into one cancellation count in your churn reporting misattributes cancellations you caused to customers who never asked to leave.
None of this needs to happen at once, and it's worth doing in that order. Grace period and account hold are dashboard settings — change them today and every renewal that fails tomorrow gets the new window automatically, no release required. RTDN wiring and custom recovery messaging are engineering work, and they're worth prioritizing only after you've confirmed the settings underneath them are actually tuned, since a perfectly timed recovery email sent during a grace period that's too short to matter won't move your numbers much.
Where this leaves the Android-vs-iOS comparison
It's worth being precise about what Android's higher involuntary churn rate actually means, because the instinct is to read it as Android being the worse platform for subscriptions. The opposite is closer to true on the control side: Apple gives developers a handful of fixed outcome codes and no ability to tune retry timing at all, while Google Play exposes grace period length, account hold duration, and granular real-time state as things you can actually configure. Android's higher billing-error rate is less a platform limitation and more a measure of how much of that configurability the average team leaves untouched. That's also why the fix here looks nothing like the fix in our piece on Stripe's iOS BillingSDK — there, the problem was Apple's platform blocking developer control entirely, and the fix required new infrastructure. Here, the control already exists; it's just off by default in most integrations.
The mechanism is also different from the card-level dunning we cover in our Stripe dunning guide. Stripe's Smart Retries and email dunning operate on a payment processor's own decline and retry cycle for web billing. Google Play's grace period and account hold are a parallel system, running entirely inside Play's subscription infrastructure, with its own retry schedule and its own escalation states — the two systems don't talk to each other, and a mobile app selling through Play needs both configured independently of whatever dunning setup exists for a web-billed version of the same product.
If your app sells subscriptions through Google Play and you've never opened the grace period or account hold settings since launch, that's the highest-leverage 20 minutes available to you this week — it's the rare churn fix that requires no new code, no A/B test, and no vendor integration, just checking a console setting against numbers Google has already published. Once that's tuned, our churn calculator is a fast way to see what even a partial recovery-rate improvement on your Android billing errors is worth in retained MRR. And for the subscribers who really do want out — not a lapsed card, an actual decision — that's exactly the moment a cancellation flow like CancelFlow is built to catch, on whatever platform they signed up through.
Frequently asked questions
What is the difference between Google Play's grace period and account hold?+
Grace period runs first: when a renewal payment fails, the subscriber keeps full access while Google Play retries the charge in the background, for a duration you set in Play Console (commonly a few days up to 30). If the grace period ends with no successful payment, the subscription moves into account hold — access is suspended, but the subscription itself is not canceled, and Play keeps retrying. Only if account hold also expires without a successful payment does the subscription actually cancel. Neither grace period nor account hold is a canceled state, and treating them as one is one of the more common and more expensive mistakes in Android billing integrations.
When did Google change the account hold duration, and what changed?+
Effective December 1, 2025, Google Play moved from a flat 30-day default account hold to a formula: 60 days minus whatever grace period duration you've configured. Apps that had account hold set to the old 30-day default were migrated automatically. The combined total of grace period plus account hold must still add up to at least 30 days, but the ceiling on total recovery time roughly doubled for most developers who hadn't customized the setting.
Does a subscriber in grace period or account hold count as churned?+
Not yet, and your reporting should reflect that. Both states are recoverable — Play is actively retrying the payment the entire time, and a subscriber who updates their card or has funds clear on a later attempt resumes normally with no re-signup required. A subscription only becomes a genuine cancellation once account hold expires with no successful payment, or the subscriber explicitly cancels through the Play subscription center. Counting grace period or account hold entries as churn in your dashboards will overstate involuntary churn and make your recovery efforts look less effective than they are.
How can I tell if a Google Play cancellation was voluntary or a billing failure?+
Real-time developer notifications distinguish the two. A subscription entering grace period or account hold fires its own notification type, separate from the notification fired when a subscriber actively cancels through Play. The Play Developer API's subscription cancellation endpoint also lets you tag cancellations you initiate yourself as developer-requested, separate from user-requested ones. If your backend collapses all of these into a single generic "canceled" webhook handler, you've thrown away the exact distinction that tells you whether a customer left on purpose or a card just failed.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →