Refund defense
How Refund Sensor answers refund requests on Apple and Google Play, inside each deadline, and what it can and cannot change.
How a refund is handled
Every refund follows the same path, and it is all automatic once your app is connected:
- The store sends a signed notification the moment a refund is requested or a chargeback opens.
- Refund Sensor verifies the notification is genuine, records it, and shows it in your dashboard in real time with the context the store provided.
- If the notification is one you can respond to, Refund Sensor submits a decline recommendation through the official store API, well inside the deadline.
- The outcome is tracked back to the same case when the store decides.
You do not gather or send anything, and nothing is collected from your customers.
Apple consumption requests
When Apple investigates a refund it sends a CONSUMPTION_REQUEST notification and gives you about 12 hours to respond. Refund Sensor replies through Apple's Consumption API with a preference of DECLINE, automatically and within the window. No usage data is required from you. Duplicate deliveries from Apple are safe, because each notification is handled once and only once.
Google chargeback reviews
On Google Play the one refund you can respond to is a chargeback under review, which gives you about 24 hours and honors the first response. Refund Sensor submits a decline recommendation through the official Google Play Developer API inside that window. Other Google Play refunds and voided purchases are decided by Google on their own, so they are recorded for visibility rather than contested.
How fast we respond
Responses go out within seconds of the notification arriving, so you are never at risk of missing a deadline, even for requests that land overnight or on a weekend. If a response cannot be delivered on the first try, Refund Sensor retries with backoff until it succeeds or the store's window closes.
The store always decides
Refund Sensor recommends declining, but the store makes the final call. Responding with evidence reliably beats staying silent, since an unanswered request is usually approved automatically. No tool can guarantee a specific refund is denied, which is why your dashboard reports real outcomes rather than promises.
Final and historical events
Some notifications are final rather than a request for input, for example a refund that has already been granted, declined, reversed, or a revoke. Refund Sensor records these for your dashboard and analytics but does not act on them, because there is nothing left to contest.
Refunds that predate your integration are detected automatically and kept out of your defense metrics and quota, so your numbers reflect only what Refund Sensor was actually there to defend.

