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.
For developers focused on android refund tracking, understanding this difference is important because a real-time event stream and a historical reconciliation mechanism solve different parts of the refund-monitoring problem.
Real-time Developer Notifications (push)
Real-time Developer Notifications (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 developers searching for RTDN Google Play integration, this is the mechanism that connects Google Play billing events with your backend. 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 Google Play 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 the Google Play Voided Purchases 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.
RTDN Google Play gives your backend a real-time signal, while the Google Play Voided Purchases API provides the reconciliation layer for missed or delayed events.
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. This Pub/Sub Play Billing setup also needs to remain reliable as your billing infrastructure grows.
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.
Google Play refund notifications. Your system needs to correctly process each relevant Google Play refund notification and connect it with the right purchase, entitlement, and customer record.
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.
For teams asking how to track Google Play refunds with RTDN and Voided Purchases API, the answer is to use RTDN for fast event detection and the Voided Purchases API for reconciliation and recovery. This gives your backend a more complete picture of refunds, voided purchases, and chargebacks.
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 {#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 →
Internal links to add once published: Google Play refunds cornerstone · Apple refund automation cornerstone · the 12-hour window.
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.
