Android is one of the most important storefronts for any digital subscription service – and one of the easiest to underinvest in. A Google Play billing setup does more than process purchases: it protects revenue, keeps entitlement accurate, and stays reliable as volumes grow. Here's what that setup should actually look like, and where you most often leave money and subscribers on the table.
1. Identify every subscription by both its product ID and its base plan ID. Google uses both to tell monthly, annual, and other plans apart.
2. Treat a notification from Google as a signal that something changed, then confirm the subscription's current state before you act on it.
4. Make sure every new purchase is acknowledged within three days. Otherwise, Google automatically refunds and revokes the purchase.
5. Report the amount Google actually charged, including regional pricing, tax, and promotions. Be clear whether your revenue figures include Google's service fee.
6. Compare your subscription records with Google's on a regular schedule. This catches missing events before they turn into access or revenue problems.
For most subscription brands, Google Play sits quietly in the background. Purchases go through, renewals fire, cancellations eventually show up in a report somewhere. On the surface, nothing looks broken. Underneath, the platform has moved on – and a lot of integrations shipped a few years ago are quietly out of step with what Google Play billing can do today.
The good news: a small set of practices separates a Google Play setup that just works from one that's actually protecting revenue. This piece walks through them from a publisher's perspective, then looks at where an operational layer like Cleeng makes the whole thing easier to run.
Google's current subscription model separates the product from its pricing. A subscription represents a level of access (Standard, Premium, and so on). Base plans represent the billing cadence (monthly, annual, quarterly) and each one either renews automatically or is paid up front as a prepaid plan. Offers sit on top for intros, promotions, and win-backs, and they come with their own rules about who qualifies: new subscribers, upgraders, or people you're trying to win back.
When your internal catalog mirrors this shape, price tests and promotions stay cheap to run, reporting stays honest, and the same subscription doesn't need to be duplicated every time you want to try a different price. When it doesn't, every experiment turns into a small migration – new SKUs, new mappings, new reconciliation logic, all for what should have been a one-line price change. One detail decides which of those two worlds you live in: a subscription's real identity downstream is the product and the base plan together, not the product on its own. Teams that store only the product are the ones whose reporting breaks the day a second billing cadence goes live.
One-off purchases have their own version of the same hierarchy, so day passes, single events and rentals deserve the same discipline. If you sell a match, a film or a weekend of access on Android, model it properly rather than bending a subscription into the shape of a pass.
Google uses real-time developer notifications (RTDNs) to signal that something changed. The current grace period, an account hold, a pause, a recovation. They tell you something happened. The current subscription state, read back from Google, tells you what is true right now – and that is the one to trust.
Google notifications can arrive twice, out of order, or occasionally not at all, so reading current state on every event is the simplest defence against acting on stale information. It also keeps your steady as Google adds new notification types – there are already more than eighteen on the subscription side. In practice that means a listener, a queue that survives an outagem and someone who notices when it goes quiet: infrastructure work, not product work, which is why most teams would rather it sat with their billing platform than on their own roadmap.
One part of this has a date attached, and it sits inside the app rather than on the server: from 31 August 2026, new apps and updates need version 8 of the Play Billing Library, with an extension available until 1 November 2026.
Grace period, account hold and pause are three distinct, recoverable subscription states – and revocation is a fourth that ends things immediately. None of them mean “cancelled.” Collapsing any of them into a generic cancelled status is one of the most common and most expensive mistakes on Android.
When a card fails, Google doesn't cancel the subscription right away. It first enters a grace period – the viewer keeps access while Google retries the payment – and then, if that fails, account hold – access is paused, but the subscription is still recoverable if the viewer updates their payment method. Pause is different: the viewer chooses it and it resumes on a set date. Revocation ends access immediately, so it should never be treated like an ordinary expiry. Each transition is signalled differently, and each one deserves its own status in your system, because the message you send a viewer in grace is not the message you send someone on hold.
| Grace period | Account hold | Paused | Revoked | |
| Viewer keeps access? | Yes | No | No | No, immediately |
| Recoverable? | Yes | Yes | Yes, when it resumes | No |
| What's happening | Google is retrying the payment | Payment retries exhausted; waiting on subscriber to update payment method | The viewer chose to take a break | Access was withdrawn |
| How long (2026) | Publisher-configured | Auto-calculated: up to 60 days minus grace period length (Google Play Console Help) | A window the viewer picks | Not applicable |
The stakes here are real: one third of all subscription cancellations on Google Play are billing errors – expired, failed, or declined cards, not dissatisfaction. Subscription brands that configure both grace period and account hold correctly see recovery rates jump roughly 3x– from 10% to 33% – on those declines, according to Google's own internal data. Google is unusually direct about this in Play Console: account hold is on by default, its length is calculated as 60 days minus whatever grace period you set, and shortening it “may reduce the number of subscriptions recovered from payment declines” (Play Console Help, “Create and manage subscriptions”, checked August 2026). Model each state distinctly in your own system, and use them to drive the right in-app messaging – a “your payment is being retried” banner is a very different experience from “your subscription was cancelled.”
Google automatically refunds any purchase that isn't acknowledged within three days of the purchase itself – a strict, silent deadline most publishers only discover after it costs them revenue. It applies to one-off purchases as much as subscriptions, and for subscriptions it's only the first payment that needs acknowledging. Renewals look after themselves.
Acknowledgement belongs on a server, as soon as the purchase is verified – not in the app, where a closed screen or lost connection can swallow it. Google is forgiving about being told twice, so the thing to protect is your own record of the purchase, not the call itself. It's a small detail, and one of the most common silent revenue leaks on Android: no error, no alert, just a purchase that quietly reverses itself three days later.
One more trap in the markets where cash and carrier billing matter: those purchases arrive pending. You can't acknowledge them until the money clears, and you shouldn't hand over access while they're still in the air.
The revenue number that matches Google's own reports is the one Google returns on the transaction – not the price you configured. Regional pricing, taxes, and promotional offers all change what the viewer actually paid. There's a second layer people forget: Google's service fee sits between what the viewer paid and what lands in your account. So decide early which number you mean by “revenue” – what was charged, what's left after Google's cut, or what actually gets paid out. Most arguments about Android numbers not adding up are two teams comparing two different ones.
Refunds belong in the same picture – that's what the Voided Purchases API is for. Two things to know about it: it only shows you a recent window, so it has to be checked regularly rather than queried after the fact, and it covers chargebacks as well as refunds. Pulling both into the same revenue view as your purchases is what makes your Android numbers agree with Google's own reports at month-end, instead of requiring a manual adjustment every time finance asks why the totals don't match.
A scheduled reconciliation job is what catches the subscriptions that notifications miss entirely.
Even with notifications wired up correctly, some events arrive late, out of order, or not at all. A background job that periodically checks in with Google and fixes anything that's drifted is one of the cheapest forms of insurance available. In practice that means a daily pass over the subscriptions that are active or recently expired, a sweep for refunds and chargebacks on the same schedule, and someone being told when the two sides disagree – a silent correction hides the breakage that caused it. At month-end, Google's own financial reports are the tiebreaker.
Calling Google every time a viewer opens a video is slow, fragile, and unnecessary – and at volume it's a non-starter, because the store's APIs are there for purchase and restore, not for every play. Ask the store at those two moments. For everything in between, check the subscription record in your own system, kept up to date as Google reports changes. It's faster for the viewer and it means a Google Play outage doesn't take your playback down with it. The platform gives you the events. What happens between the event and the access is where the integration lives or dies.
The rules around who may take the payment have changed. Google Play now runs alternative billing and external-offer programmes in a growing list of markets, and in the US – following the Epic ruling upheld in September 2025 – apps can enrol to use their own billing system or link subscribers to external content. From 1 October 2026, developers in those US programmes have to report their transactions and downloads and pay the relevant Play service fee, so the fee no longer arrives as a single familiar percentage. That makes this a pricing decision as much as a technical one.
It's worth being honest about the trade. Take it on and you're running two revenue streams for the same subscriber – one billed by the store, one billed by you – with different fees, different tax exposure and different refund mechanics, while the answer to “does this person have access?” still has to be a single one. That's the split Cleeng is built around: one place for the subscriber and their entitlement, and a merchant layer for the payments, tax and compliance on the side you bill yourself. And because the terms are still moving, check what's current in Play Console before you commit to a price.
None of the practices above are Google-specific in spirit – they're what disciplined subscriber infrastructure looks like on any store. What makes them hard isn't any single one of them; it's that Google Play is rarely the only store in the picture. Subscribers, especially when it comes to streaming, also sign up through Apple, Roku, Amazon Fire TV, Samsung, Vizio, direct web, and telco or ISP bundles – often several at once for the same title. Every one of those channels raises the same paywall and entitlement questions, and answers them slightly differently.
Cleeng's SRM® (Subscriber Retention Management) is the operating model built to answer them once. It isn't a billing tool with reporting bolted on – it's an integrated stack:
Core for subscriber and entitlement management,
Merchant for payments, tax, and compliance,
ChurnIQ for retention and churn analytics, and
Hi5 for AI-assisted subscriber care,
All combined on one platform instead of stitched together from separate vendors.
| Inside Google Play and Apple's own in-app billing, the store itself remains Merchant of Record for the transaction – that doesn't change. For web, direct, and telco channels, Cleeng's Merchant module can act as Merchant of Record, taking on payment liability, tax, and compliance, or integrate with a publisher's existing processor, depending on what the publisher needs. |
Inside Cleeng, the Google Play Billing Connector manages the subscription lifecycle after your app registers the purchase. Cleeng verifies the purchase with Google, processes and normalizes more than eighteen notification types, keeps entitlement synchronized and carries renewals, grace periods, account holds, pauses and revocations into one consistent subscriber record. Your app does not have to consume or interpret those notifications, and no further app action is required for renewals or lifecycle events.
For a publisher or subscription brand, that combination compounds. One consistent idea of what active, in grace, on hold, paused or finished means, on every platform. One place to ask whether a viewer has access, wherever they signed up. One dashboard where the numbers agree. And connections into the CRM, marketing tools and video platforms you already run – so Cleeng coordinates those systems instead of sitting next to them.
Ready to get started with Cleeng? Create a free account to see how you can easily see consolidated data from all the platforms your content is available on.