Quick answer: On Google Play, most refunds happen without your input, Google issues them, revokes the entitlement, and notifies you after the fact through a voided purchase. The one refund you can actually contest is a chargeback under review, where Google gives you roughly 24 hours to submit a recommendation. Everything else you track, not fight. Knowing which is which is the difference between recovering revenue and watching it leave silently.
Why Google Play is different from Apple
If you came here from the Apple side of refunds, reset your expectations the two stores work almost nothing alike.
On Apple, nearly every refund request generates a CONSUMPTION_REQUEST, and you get a consistent 12-hour window to respond with consumption data. (We cover that fully in How to Automate Apple Refund Requests.) The model is: Apple asks, you answer, Apple decides.
Google Play doesn't ask most of the time. Google decides the majority of refunds on its own user-requested refunds, policy refunds, and Google-initiated reversals and simply tells you afterward. There's no consumption-data submission, no evidence window, no "prefer decline" for those. The purchase is voided, the entitlement is revoked, and you find out once the money and the access are already gone.
The exception is the chargeback. And that exception is where your attention belongs.
The three things that happen on Play
It helps to separate what actually occurs on Google Play into three distinct events, because developers routinely lump them together and then wonder why they "can't fight refunds."
Event | Who decides | Can you contest it? | How you find out |
|---|---|---|---|
User/Google refund | No | Voided purchase notification, after the fact | |
Voided purchase | No | Real-time developer notification | |
Chargeback under review | Card network, informed by Google | Yes, roughly 24h to respond | Real-time developer notification |
The first two you record so your entitlements and analytics stay accurate. The third is the only one with a decision window you can influence.
Chargeback reviews: the one you can contest
A chargeback happens when a customer disputes the charge with their bank or card network rather than asking Google directly. When one enters review, Google opens a short window, about 24 hours, for you to submit a recommendation on how it should be resolved.
This is your Google Play equivalent of Apple's consumption response. It's narrow, it's time-boxed, and it's easy to miss because, like Apple's window, it can open at any hour. Miss it and the dispute resolves without your input, which usually means in the customer's favor.
The move here is the same as on Apple: catch every chargeback review in real time and submit a decline recommendation inside the window, automatically, so timing never costs you a contestable dispute.
Voided purchases: track, don't fight
Everything that isn't a chargeback review, ordinary refunds, revocations, Google-initiated reversals, shows up as a voided purchase. You can't contest these, but you absolutely need to see them, for three reasons:
Entitlement accuracy. If Google revoked access, your app should reflect that. A user who was refunded shouldn't keep premium features.
Clean analytics. Refunds distort revenue, LTV, and churn if you're not accounting for them.
Pattern detection. A cluster of voided purchases from one region, one SKU, or one acquisition source is a signal worth acting on, even if you can't reverse the individual refunds.
So the right posture is: record every voided purchase, keep entitlements and reporting honest, and watch for patterns, while spending your actual contest effort on the chargeback reviews you can influence.
What real-time visibility actually takes
None of this works without real-time visibility. Google Play delivers refund and voided-purchase events through Real-time Developer Notifications (RTDN), which run over Google Cloud Pub/Sub and that dependency is exactly where Google Play gets more involved than Apple.
Where Apple is a single webhook URL, RTDN means standing up a Google Cloud Pub/Sub topic, granting Google Play the right permissions to publish to it, wiring it into Play Console, subscribing your backend, and then reconciling against the Voided Purchases API so a missed notification doesn't become a silently missed refund. The Pub/Sub provisioning specifically is where most developers stall the permissions and topic setup are fiddlier than they look, and it's a standing piece of infrastructure to keep working, not a one-time task. (We compare the two mechanisms in Voided Purchases API vs Real-Time Developer Notifications.)
A managed service removes that friction entirely by auto-provisioning the Pub/Sub topic for you, so you only paste one topic name into Play Console rather than building and maintaining the pipeline yourself.
How the contestable part gets handled
Once notifications flow, two jobs need doing, continuously and at any hour:
On chargeback reviews: submit a decline recommendation through the Google Play Developer API inside the ~24-hour window, every time, without a human watching the clock.
On everything else: log the refund or voided purchase, update entitlements, and feed your analytics so the events you can't contest still leave you with accurate data and visible patterns.
RefundSensor does both from one dashboard, alongside your Apple refunds, so you're not running or maintaining separate systems for each store.
What this can and can't do
It can't contest ordinary Google Play refunds or Google-initiated reversals Google decides those alone.
It can't guarantee any specific chargeback resolves in your favor the card network makes that call.
It can make sure every chargeback review is answered inside the window, and that every other refund is tracked so your entitlements and analytics stay correct.
Being realistic about the first two is what makes the third valuable: you stop losing the contestable disputes to timing, and you stop flying blind on the rest.
Official sources
Google's policies and APIs change, so treat Google's own documentation as the final authority:
One dashboard for both stores. RefundSensor catches Google Play chargeback reviews in real time and submits a decline recommendation inside the window, tracks every other refund and voided purchase, and does the same for Apple, all in one place. Auto-provisioned notifications, no code changes. Start free
Frequently asked questions
Only one kind: a chargeback under review, where Google gives you about 24 hours to submit a recommendation. Ordinary refunds and Google-initiated reversals are decided by Google without developer input, you can track them but not contest them.
It's when a customer disputes a charge with their bank or card network and the dispute enters a review window. Google lets you submit a recommendation on how to resolve it, typically within ~24 hours.
A refund is the money being returned. A voided purchase is Google's notification that a purchase is no longer valid, often the result of a refund or revocation. You use voided-purchase events to keep entitlements and analytics accurate.
Create a Google Cloud Pub/Sub topic, grant Google Play publish access, configure it in Play Console, and subscribe your backend. Reconcile against the Voided Purchases API so a missed notification doesn't create a gap. RefundSensor auto-provisions the Pub/Sub topic so you only paste one topic name.
No. Refund and chargeback handling happens server-side through Real-time Developer Notifications and the Google Play Developer API, no SDK or app resubmission required.
