Most "best refund tool" lists are written by people who haven't wired one up. Here's the version I'd have wanted, based on what each platform actually sends to Google and what it quietly misses.
Quick framing, because it trips people up. A google play refund subscription event and a chargeback follow two different rulebooks, and most platforms handle one properly and the other partially. You can only contest the chargeback. Everything else, you can only detect.
If you'd rather skip the comparison, Google Play chargeback defense is our own product page and the short version of this post.
Key Takeaways
Google only lets you contest chargebacks, through the Review Refund API, in about 24 hours. Every platform here is working inside that constraint.
Google accepts three preferences: APPROVE, DECLINE, NEUTRAL. No partial refunds via the API, on any platform.
The real differentiator is evidence. Some tools send usage data. Some send a preference and a single boolean.
Google never tells you the outcome. Platforms poll for it, so win-rate reporting lags everywhere.
Detection is the bigger gap. Refund without revoke, partial refunds and unacknowledged purchases stay invisible to most stacks.
What to Actually Compare
Four things. Everything else is pricing page noise.
Does it send consumption evidence, or just a preference? This is the whole point of the Review Refund API. Google asked for delivery state and item consumption so it could argue your case with the bank. A tool that only files APPROVE or DECLINE is using maybe a third of the channel.
Does it need an SDK? If yes, you're coupling refund defense to your subscription infrastructure. A real decision, and not always a bad one.
What does it detect? Contesting is half of Google Play refund management. Knowing a refund happened, and cutting access, is the other half.
Does it cover Apple too? Most teams run both stores. Two vendors for one job is how things get dropped.
RevenueCat Refund Control
The strongest option if your subscriptions already run through RevenueCat, which for a lot of apps they do.
Refund Control uses project-level policies evaluated top to bottom. First matching policy wins. You pick Prefer full refund, Prefer no refund, Send consumption data only, or Do not respond. It hits Google's orders.reviewrefund endpoint for you.
Here's the part worth reading twice. Per RevenueCat's own documentation, the body they send Google contains three fields: pendingRefundToken, sampleContentProvided set to true, and your refundPreference. They state plainly that they don't send consumption percentages or usage events yet. So you get the preference channel, not the evidence channel.
They're also honest about detection limits. A Play Console refund issued without the revoke box ticked won't be detected. Partial refunds don't come through, and refunds from unacknowledged purchases aren't picked up. Anything granted by Google rather than by you can take up to 24 hours to show.
Where RevenueCat genuinely wins is something nobody else here does: you can issue a Google Play subscription refund yourself, from the dashboard or a REST endpoint, and it revokes access in the same call. If support handles refunds directly, that matters.
Adapty Refund Saver
Refund Saver now covers Google Play, not just Apple, and it's on by default if you were already using it on iOS.
It does send usage evidence on chargeback reviews, which puts it ahead of RevenueCat on the thing that actually influences the outcome. Google Play support arrived after the August 3 change made chargebacks expensive.
Two honest limits, both from Adapty's own docs. Google accepts only decline, approve or no preference, so Grant prorated on the Apple side has no Google equivalent and Adapty sends No preference instead. And Google notifies nobody when a review resolves, so Adapty polls the order status until it settles. Play outcomes show up later than Apple ones.
The real gate is the SDK. Refund Saver is a platform feature, not a standalone product. If you're not on Adapty for subscriptions, you're re-platforming to get it. For some teams that's a fine trade. For most it isn't.
Refund Sensor
Us, so weigh accordingly.
No SDK. Sign in with Google, grant two Play Console permissions (view financial data, manage orders and subscriptions) and it provisions the Pub/Sub topic and push subscription in your own Google Cloud project. Nothing to paste into Play Console, no app release.
It files a decline recommendation with delivery and engagement evidence through orders.reviewrefund inside the 24 hours, and separately tracks the refunds you can't contest, which is the part most teams have no visibility into. Both stores sit in one dashboard.
Honest gaps: it's newer than RevenueCat or Adapty, and there are no paywalls, A/B tests or subscription analytics, because that isn't the product. Need subscription infrastructure? You'll want one of the others too.
RefundHalt
Worth a look if you want per-case rules rather than a blanket preference. No SDK, both stores, and it pulls usage evidence from an endpoint on your server, so the evidence is yours rather than inferred.
One caveat. Some of their published comparisons predate Refund Saver supporting Google Play, so check the current docs rather than the comparison pages.
Building It Yourself Instead
Reasonable, and cheaper than it looks if you already run a backend.
You need RTDN enabled under Monetize, then Monetization setup. A Pub/Sub topic. A consumer that decodes the base64 data field and branches on which of five notification objects arrived. On pendingRefundReviewNotification you store the pendingRefundToken and race a 24-hour clock. Then one call to orders.reviewrefund.
The part that isn't a weekend: having real consumption data for a subscription purchased seven weeks ago, plus idempotency, because Google retries, plus a nightly Voided Purchases sweep to catch what the notifications missed. Voided Purchases API versus real-time developer notifications covers which feed does what.
That's also the honest answer to how developers automate Google Play refunds when they don't want a vendor. It's a webhook consumer, a timer, and a data problem.
Which One, Then
Already on RevenueCat and mostly need detection plus a preference? Refund Control. Turn it on today.
Already on Adapty and want evidence sent without extra work? Refund Saver. It's probably already enabled.
Not on either, and you don't want to re-platform to defend refunds? Refund Sensor or RefundHalt.
Your disputes skew towards fraud and you want per-case logic? RefundHalt, or build it.
None of them, and refunds are trivial? Do nothing yet, but wire up RTDN anyway. It's free, and you'll want the history when the volume shows up.
The Bit Every Platform Page Skips
How to automate Google Play subscription refunds is the wrong first question for most apps. Google Play refunds for developers split into what you can influence and what you can only react to, and the second list is longer.
You can contest a chargeback review. That's it. Support refunds, 48-hour Play refunds and unacknowledged trial conversions are all decided without you. The only automation available there is detecting them fast and cutting access.
Which means Google Play refund automation is really two products in a trench coat: a response engine for chargebacks, a detection engine for everything else. Most vendors are strong at one. Check which you're buying. Google's own refund protection and chargeback cost announcement is worth reading before you pick, because it explains why the response side suddenly matters.
Sources
Frequently asked questions
Only the chargeback subset. Google opens a review when a customer disputes with their bank, and you get about 24 hours to respond via the Review Refund API. Every other refund type is decided without you, and can only be detected.
Depends what you already run. RevenueCat if your subscriptions are there. Adapty if you're on their SDK and want usage evidence sent automatically. Refund Sensor or RefundHalt if you want refund defense without re-platforming.
No. Google accepts APPROVE, DECLINE or NEUTRAL through the API. Prorated refunds exist on Apple's side but have no Google equivalent, so platforms that offer them send No preference on Play instead.
Either build it against RTDN and orders.reviewrefund yourself, or use a service that connects through Play Console permissions and a Google Cloud project. Both avoid touching the app binary.
Slowly. Google notifies nobody when a review resolves, so platforms poll the order status. Expect outcome data to lag, and judge a tool on whether it filed inside the window rather than same-day win rate.
Since August 3, 2026, a lost chargeback costs the purchase price minus Google's service fee plus a bank fee. On a cheap product that fee alone can exceed the sale. Run the math on your own order values before deciding.
