Quick answer: Google Play gives you two ways to learn that a purchase was refunded or revoked. Real-time Developer Notifications (RTDN) push events to your server the moment they happen, over Google Cloud Pub/Sub. The Voided Purchases API lets you pull a list of voided purchases on demand. They're not alternatives, RTDN gives you speed, the Voided Purchases API gives you a safety net, and a reliable setup uses both so nothing slips through.
Why Google gives you two mechanisms
On Google Play, most refunds happen without asking you, Google issues them, revokes the entitlement, and your job is to find out so your app and analytics stay accurate. (For what you can and can't contest, see Google Play Refunds & Chargebacks.)
Google offers two different tools for finding out, and they solve the problem from opposite directions. One pushes events to you as they happen. The other lets you ask for a list whenever you want. Used together they cover each other's weaknesses; used alone, each has a gap.
Real-time Developer Notifications (push)
RTDN is the push mechanism. When something happens to a subscription or purchase, including refunds and voided purchases, Google publishes an event to a Google Cloud Pub/Sub topic that your backend subscribes to. The point is immediacy: you hear about the event close to when it occurs, rather than discovering it hours later.
For anything time-sensitive, like a chargeback review, where you have roughly 24 hours to respond, this immediacy is the whole game. If you're relying on checking periodically, you've already lost time you didn't have.
The catch: RTDN runs on Pub/Sub, which means Google Cloud project setup, a topic, the right publish permissions for Google Play, and a subscriber on your side. It's more moving parts than a single webhook, and it's where a lot of developers stall.
The Voided Purchases API (pull)
The Voided Purchases API is the pull mechanism. It returns a list of orders that have been voided, refunded, charged back, or revoked, that you can query on demand. Instead of waiting for an event, you ask Google directly: what's been voided?
Its strength is completeness and recovery. If a push notification was delayed, missed, or never processed, a pull against this API surfaces the voided purchase anyway. It's how you reconcile and make sure your record matches Google's.
The trade-off is that it's not instant by nature, it's something you query, so on its own it's a safety net rather than a trigger.
Why you need both, not one
Here's the distinction that trips people up: this isn't a "pick the better one" decision.
RTDN alone gives you speed but no guarantee of completeness, miss or mishandle a notification and that event is just gone from your view.
The Voided Purchases API alone gives you completeness but not speed, you'd only know about a refund the next time you happen to query.
A dependable setup uses RTDN as the real-time trigger and the Voided Purchases API as the reconciliation layer that catches anything the push path dropped. Speed plus a safety net. Either one by itself leaves a hole you'll eventually fall through.
Where this gets complicated
Wiring this up correctly is more involved than it sounds, and the effort is ongoing rather than one-time:
Pub/Sub provisioning. Creating the topic, granting Google Play the right to publish, subscribing your backend, and getting the permissions exactly right is the step most likely to eat an afternoon or three.
Two systems to keep in sync. You're now running a push consumer and a scheduled pull-and-reconcile job, and making sure they agree.
Deduplication and ordering. The same event can reach you more than once, or out of order; your handling has to be idempotent.
Keeping current. Google revises billing APIs and event types, and your integration has to keep pace or quietly drift out of date.
Individually, none of this is exotic. Together, it's a real piece of infrastructure to build and maintain, for the privilege of accurately tracking refunds you mostly can't contest anyway.
How this fits refund handling
Put the pieces together and Google Play refund handling has two halves: catch the one thing you can contest (the chargeback review) inside its window, and accurately record everything you can't so your entitlements and analytics stay honest. Both halves depend on the RTDN + Voided Purchases foundation being solid.
This is exactly the layer RefundSensor manages for you. It auto-provisions the Pub/Sub topic so you only paste one topic name into Play Console, consumes RTDN in real time, reconciles against voided purchases so nothing is missed, submits a decline recommendation on chargeback reviews inside the window, and records every other refund, all in one dashboard alongside your Apple refunds. You get the result of a correct two-mechanism setup without building or maintaining either mechanism.
Official sources
Google's billing APIs change, so treat its documentation as the final authority:
One setup, both mechanisms, zero maintenance. RefundSensor auto-provisions Pub/Sub, consumes RTDN in real time, reconciles against voided purchases, and handles chargeback reviews, for Google Play and Apple, in one dashboard. Start free
Frequently asked questions
RTDN pushes events to your server in real time over Pub/Sub; the Voided Purchases API lets you pull a list of voided orders on demand. RTDN gives speed, the Voided Purchases API gives completeness.
For a reliable setup, yes. RTDN is your real-time trigger and the Voided Purchases API is your reconciliation safety net for anything the push path missed. Each alone leaves a gap.
An order that's no longer valid, typically due to a refund, chargeback, or revocation. Tracking voided purchases keeps your entitlements and analytics accurate.
RTDN runs on Google Cloud Pub/Sub, so it involves a topic, publish permissions for Google Play, and a subscriber on your side, more moving parts than pasting a single URL. RefundSensor auto-provisions the Pub/Sub topic to remove that friction.
Mostly no. Ordinary refunds and revocations are decided by Google. The one contestable case is a chargeback under review, which you should catch via RTDN and respond to inside its ~24-hour window.
