What tools integrate with Google Play real-time notifications for refund defense?

Short answer: fewer than you'd think, and most only listen.

Google Play RTDN is the pipe. It carries renewals, cancellations, voided purchases, and, since mid-2026, a message that says a chargeback is under review and you have 24 hours to weigh in. That last one is the only place Google Play refund defense actually happens. Everything else in the feed is Google telling you what it already decided.

So when someone asks which tools integrate with Google Play real-time developer notifications for refund defense, they're really asking two questions. Which can hear the feed, and which can answer it. For the Apple side, our CONSUMPTION_REQUEST explainer covers the same problem on iOS.

Key takeaways

• Google Play RTDN is a Pub/Sub topic. Google publishes, you subscribe.

• Only one RTDN type lets you push back: PendingRefundReviewNotification. It fires on chargebacks and gives you 24 hours.

• Since August 3, 2026, you eat the chargeback. Purchase price minus Google's fee, plus a $15 to $25 bank fee on top.

• Most subscription platforms receive Google Play refund notifications. Very few send anything back.

• RevenueCat answers chargeback reviews but, by its own docs, sends no consumption data. Just a preference and one flag.

• Miss the 24 hours and Google argues the dispute with nothing from you.

What Google Play RTDN actually sends

Real-time developer notifications land in a Google Cloud Pub/Sub topic you own. Each message is a base64 blob holding one of five payloads. Subscription events, one-time product events, a test ping, and the two that matter here.

VoidedPurchaseNotification is the classic Google Play refund notification. A purchase was refunded, charged back, or otherwise killed. Four fields: purchaseToken, orderId, productType, refundType. Good for revoking access. Useless for arguing, because the money's already gone.

PendingRefundReviewNotification is the new one. Google's RTDN reference says it's sent "when a user requests a chargeback for a purchase, and the request requires developer review." You get a pendingRefundToken, the orderId, and a refundReason that's currently always 7, meaning CHARGEBACK. Then a 24-hour clock starts.

Google Play RTDN refund notifications come in two flavours, then. One is a receipt. The other is a question.

Why the 24-hour window suddenly matters

For years, chargebacks on Android were Google's problem. A user disputed a charge with their bank, Google ate it, you got a voided purchase notification and moved on.

That ended for orders placed after August 3, 2026. You now pay the purchase price minus Play's service fee, plus whatever chargeback fee the bank charges. Google covers its own service fee and nothing else.

Card network fees run $15 to $25 per dispute. Sometimes more. So a $4.99 coin pack that gets charged back costs you about $3.50 in lost proceeds plus $20 in fees. Twenty-three dollars gone on a four-dollar sale.

In exchange, Google opened the ReviewRefund API. When a PendingRefundReviewNotification lands, you POST to orders.reviewrefund with the token, a refundPreference (DECLINE, APPROVE, or NEUTRAL), whether you offered a sample, a consumption percentage in milliunits, and up to 1,000 usage events. Google takes that to the bank for you.

Miss the window and Google goes in empty-handed. Industry numbers put unassisted chargeback win rates around 20 to 30 percent. With evidence, some vendors claim 80. Salt with both, but the direction is obvious.

The tools, sorted by what they actually do

Plenty of products say they "support Google Play RTDN." Almost all mean they subscribe to the topic. Very few mean they respond.

Refund Sensor. Built for this job. It provisions the Pub/Sub topic in your Cloud project, registers it with Play Console, and when a PendingRefundReviewNotification arrives it submits a DECLINE recommendation with delivery and consumption evidence through the Review Refund API. Setup is a Google sign-in and two Play Console permissions, no SDK. As of writing, it's one of the only tools that files evidence rather than just a preference. Details on the Google Play defense page.

RevenueCat. Receives RTDN, polls the Voided Purchases API, revokes entitlements on refund. In July 2026 they added Google to Refund Control, so they now answer chargeback reviews. But read their own documentation. On Google they send the token, sampleContentProvided set to true, and your preference. Their words: "RevenueCat doesn't currently collect or send consumption percentages or usage events." A vote, but no argument. Fine if you already use them. Not a full defense.

Adapty. Solid RTDN receiver. Their docs walk you through pasting a topic name into Play Console and hitting the test button. Refunds show in the event feed and fire webhooks. No ReviewRefund integration that I can find. Listening only.

Qonversion, Glassfy, and the rest. Same story. They consume Google Play real-time developer notifications to keep subscription state fresh. None touch the chargeback review, per their public docs.

Your own backend. Always an option. A Pub/Sub subscription, a decoder, an order lookup, a usage query, one authenticated POST. The hard part isn't the code. It's that the notification arrives at 2 a.m. on a Sunday and the clock doesn't care.

If you're shopping for Google Play chargeback management software, ask every vendor one thing: when a review notification comes in, what exactly do you send back? "Your preference" is a start. Consumption data is a defense.

How to integrate Google Play RTDN for refund defense yourself

If you'd rather build than buy, this is the sequence.

Enable the Cloud Pub/Sub API in a Google Cloud project. Create a topic. Grant [email protected] the Pub/Sub Publisher role on it. Miss that role and nothing ever arrives. It's the most common complaint on the RevenueCat forums.

In Play Console, go to Monetize, then Monetization setup. Tick "Enable real-time notifications," paste the full topic name (projects/your-project/topics/your-topic), and hit Send test notification. If it lands, the pipe works.

Create a Pub/Sub subscription, push or pull. Decode the data field. Branch on the payload.

For PendingRefundReviewNotification: look up the order, pull real usage, decide a preference, POST to reviewrefund with the pendingRefundToken. Within 24 hours or don't bother. For VoidedPurchaseNotification: revoke access. Our post on access after a refund covers why that step is easy to get wrong on Google specifically.

Log everything. Response rate and win rate are separate numbers.

One thing Google doesn't give you: a test PendingRefundReviewNotification. You wire it up and wait for a real chargeback. That's why hosted tools show "awaiting first refund event" instead of a green tick.

The best tools for Google Play RTDN integration, if I had to rank them

For Google Play refund defense specifically, meaning answering the chargeback review with evidence, it's a short list. Refund Sensor does it with consumption data and no code. RevenueCat does it with a preference only, which beats silence but not by much. Everyone else is watching the feed.

For general RTDN plumbing and entitlement sync, RevenueCat and Adapty are both mature and well documented.

For not dealing with any of it, a merchant of record like Tebex or Xsolla on a web shop moves the liability off your books. It also moves the purchase off Play, and does nothing for the ones that stay.

Pick based on which problem you have.

Conclusion

Google Play RTDN was built to tell you things. Only recently did it start asking. The PendingRefundReviewNotification is the first time Google has wanted your side of a refund story on Android, and it arrived the same season Google started making you pay for the ones you lose.

That changes the math. A tool that just listens to Google Play refund notifications was fine when a lost refund cost you the sale. Now it's the sale plus a bank fee, and the only thing between you and that bill is a POST request inside 24 hours.

Get the topic set up. Check what your platform actually sends back. If the answer is nothing, or just a preference, close the gap before the next chargeback finds it.