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 reflect dissatisfaction, and the fix is product and UX work. But app refund abuse requires a different analysis because some refund activity can show patterns that are inconsistent with ordinary customer behavior.
Lumping the two together hides both problems. It can make your product look worse than it is, while potentially recoverable or reviewable refunds disappear into the same bucket as legitimate customer refunds.
Separating customer dissatisfaction from potential abuse patterns is the first step to doing anything useful about either.
The main abuse patterns
A few patterns are worth monitoring:
Trial abuse. The user starts a free trial, uses premium features for what they need, and requests a refund around the time the trial converts into a paid subscription. The timing and consumption history can be useful signals when evaluating the transaction.
Use and refund. Common with utility and one-off-value apps. Someone buys a subscription to complete one specific task, convert a file, unlock a feature, remove a watermark, or use a service, completes the task, and then immediately asks for their money back. The important signal is the relationship between value consumed and the timing of the refund request.
"Accidental" purchases on established accounts. The user claims they purchased by mistake on an account that has been active for months and has meaningful usage history. Genuine accidental purchases happen, but account tenure and usage history can provide additional context when evaluating an accidental purchase refund request.
Serial refunders. A smaller group may show repeated refund behavior across multiple purchases. One refund is an isolated event; a long history of refunds is a pattern worth investigating. Apple's consumption data can include lifetime refund amounts, account tenure, lifetime purchase amounts, and consumption-related information that can help provide context.
The fingerprints each one leaves
The reason these patterns matter for automation is that they're not necessarily invisible. They can appear in the transaction and consumption data used to evaluate refund requests:
High consumption, immediate refund. Significant usage paired with a refund request soon after can indicate a potential use and refund pattern.
Refund timed to the trial-conversion charge. A refund request clustered around a trial conversion can be a useful signal when evaluating trial abuse.
Account tenure vs. "accidental" claim. A long-established, actively used account claiming an accidental purchase creates a mismatch worth reviewing rather than automatically assuming fraud.
Repeat refund history. A customer with a repeated refund history may represent a pattern rather than an isolated incident.
Apple's current consumption-request documentation includes fields such as account tenure, consumption status, play time, lifetime dollars refunded, lifetime dollars purchased, delivery status, and whether sample content or a trial was provided.
That means developers can use available evidence to provide more context when responding to eligible Apple refund requests. Apple says this consumption information helps inform its refund decisions, and developers should respond to a CONSUMPTION_REQUEST within 12 hours.
Why abuse refunds are the ones worth contesting
Here's the strategic bit.
Genuine dissatisfaction refunds usually deserve a different response. Fighting legitimate customer complaints can damage the customer experience and doesn't address the underlying product problem.
Potential subscription refund abuse is different. When the available evidence shows substantial consumption, value delivered, or repeated refund behavior that conflicts with the customer's claim, the case may warrant closer review.
The important distinction is that developers cannot unilaterally deny every refund. Apple and Google make the final decision, and not every refund creates a developer response opportunity.
On Apple, eligible CONSUMPTION_REQUEST notifications allow developers to provide consumption information that Apple uses to inform its refund decision.
On Google Play, chargebacks that require developer review can generate a PendingRefundReviewNotification. Developers can provide a refund preference and relevant purchase-usage evidence through the ReviewRefund API within 24 hours.
That's why refund fraud apps should be approached as a detection and evidence problem, not simply as a problem of denying refunds.
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 decision.
You can't contest every abuse refund; not every refund creates a developer review opportunity, and the available process differs between Apple and Google.
You can respond to every eligible request with the available consumption and purchase evidence inside the applicable response window.
You can identify patterns which apps, which reasons, which products, and which customer behaviors so you can distinguish genuine product friction from potential abuse.
For teams processing large subscription volumes, refund abuse detection software can help centralize refund events, identify suspicious patterns, and ensure eligible requests don't sit unanswered.
RefundSensor does both halves. It responds to eligible Apple CONSUMPTION_REQUEST events and Google Play chargeback reviews, while its analytics break refunds down by app and reason so potential abuse patterns become visible instead of hiding inside a single "refund rate" number.
You stop losing reviewable cases to timing, while gaining visibility into how much of the problem comes from potential abuse versus genuine product friction.
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 may be linked to potential abuse. RefundSensor helps monitor eligible Apple and Google Play refund activity and breaks refund events down by app and reason, so potential abuse doesn't stay hidden inside your overall refund numbers. 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.
