Quick answer: Not every refund is a dissatisfied customer. A meaningful share are predictable abuse patterns, trial abuse (use the premium features, then refund the moment you're charged), use-and-refund (get the one thing you needed, then ask for your money back), and "accidental" purchases on accounts that have been active for months. These patterns leave fingerprints in your data, and the contestable ones are exactly what you shouldn't be losing to a missed response window.
Why this distinction matters
If you treat every refund as the same thing, an unhappy user you failed, you'll draw the wrong conclusions and take the wrong actions. Some refunds genuinely are that, and the fix is product and UX work. But a real portion of refunds aren't dissatisfaction at all; they're people using the refund system exactly as they intended from the start.
Lumping the two together hides both problems. It makes your product look worse than it is, and it lets recoverable, contestable refunds disappear into the same bucket as legitimate ones. Separating them is the first step to doing anything useful about either.
The main abuse patterns
A few recur often enough to name:
Trial abuse. The user starts a free trial, uses the premium features for whatever they needed, and requests a refund (or cancels and disputes) the instant the trial converts to a charge. The trial was never a trial to them, it was a free ride with an exit.
Use-and-refund. Common with utility and one-off-value apps. Someone buys a subscription to do one specific task, convert a file, unlock a feature, remove a watermark, run a VPN session, completes it, and immediately asks for their money back. They got 100% of the value and want 100% of the money returned.
"Accidental" purchases on established accounts. The user claims they bought by mistake, on an account that's been active for months, with meaningful usage history. Genuine accidental purchases happen, but a long-tenured, actively engaged account claiming surprise at its own subscription is a different story.
Serial refunders. A smaller group who refund habitually across many apps. One refund is noise; a pattern of lifetime refunds is a signal, and it's one Apple's own consumption fields (lifetimeDollarsRefunded) are designed to surface.
The fingerprints each one leaves
The reason these matter for automation is that they're not invisible, they show up in exactly the data a refund response deals with:
High consumption, immediate refund. Full playtime or completed usage paired with a refund request right after is the classic use-and-refund shape.
Refund timed to the trial-conversion charge. A refund request clustered right at the moment the trial converts points to trial abuse.
Account tenure vs. "accidental" claim. A months-old, actively used account claiming an accidental purchase is a mismatch worth noting.
Repeat refund history. A customer with a track record of refunds across purchases is a pattern, not an incident.
These are the same signals that go into an Apple ConsumptionRequest, consumption status, account tenure, play time, lifetime refunds. Which is the point: the evidence that identifies abuse is the evidence you'd submit in response to it. (See the field-by-field breakdown for what each of those signals says to Apple.)
Why abuse refunds are the ones worth contesting
Here's the strategic bit. Genuine dissatisfaction refunds usually should be granted, fighting them is bad for your reputation and often just delays an outcome the user deserves. The refunds actually worth contesting are the abuse cases: high consumption, clear value delivered, weak or contradicted claims.
And those are precisely the ones most often lost by default. Because they arrive like any other request, at any hour, inside the same 12-hour window, a manual process misses them at the same rate it misses everything. So the abuse refunds, the ones where you have the strongest case and the clearest right to respond, leak away for the dumbest possible reason: nobody was there to answer. (More on that in The 12-Hour Window.)
What you can and can't do about it
Being honest about the ceiling:
You can't block a customer from requesting a refund, and you can't unilaterally deny one Apple and Google make the final call.
You can't contest every abuse refund; not all of them even generate a contestable request (on Google Play, most refunds aren't contestable at all see the Google Play cornerstone).
You can respond to every eligible request with the consumption evidence that exposes the abuse, inside the window, every time.
You can see the patterns which apps, which reasons, which shapes so you know how much of your refund volume is genuine friction versus abuse.
RefundSensor does both halves. It responds to eligible Apple CONSUMPTION_REQUEST events and Google Play chargeback reviews automatically, submitting the consumption evidence, and its analytics break refunds down by app and by reason so the abuse patterns become visible instead of hiding inside a single "refund rate" number. You stop losing the winnable cases to timing, and you finally see how much of the problem is abuse versus your own product.
Further reading
https://developers.google.com/android-publisher/voided-purchases
https://developer.android.com/google/play/billing/provide-refund-and-chargeback-suggestions
https://developer.android.com/reference/com/android/billingclient/api/BillingFlowParams.Builder
https://developer.apple.com/documentation/appstoreserverapi/appaccounttoken
https://developer.apple.com/documentation/appstoreserverapi/consumptionrequest
https://support.google.com/googleplay/android-developer/answer/17068375
See how much of your refund rate is actually abuse. RefundSensor responds to eligible Apple and Google Play refund requests inside the window and breaks every refund down by app and reason, so abuse stops hiding inside your refund rate. Start free
Frequently asked questions
Using the refund system to get value without paying, trial abuse, use-and-refund, or false "accidental purchase" claims. It's distinct from genuine dissatisfaction, where a refund is warranted.
You can't prevent the request or deny it yourself; the stores decide. What you can do is respond to eligible requests with consumption evidence that exposes the abuse, and reduce trial abuse at the source with clearer trial and paywall design.
The data shape tells you: high consumption with an immediate refund, a refund timed to trial conversion, or an "accidental" claim on a long-active account. Refund analytics by reason make these patterns visible.
The abuse cases, where value was clearly delivered and the claim is weak. Genuine dissatisfaction refunds are usually better granted. The problem is that abuse refunds are often lost by default to a missed response window.
It doesn't prevent the request, but submitting accurate consumption data gives Apple the context to factor abuse into its decision, context it never gets if you don't respond in time.
