Refund rules that actually work: what to grant, what to contest
Blanket-declining every refund is as wrong as ignoring them. A field guide to measuring what refunds cost you and writing policy rules that protect revenue and your review score at the same time.
Principais conclusões
- Before writing rules, measure the problem: App Store Connect and Play Console both let you isolate exactly how much revenue refunds take.
- Contesting every refund is as costly as ignoring them: fighting a first-time customer over $2.99 buys you a one-star review.
- The winning shape is a rules ladder: grant fast where goodwill is cheap, contest with evidence where consumption is real, always contest repeat refunders.
- Usage evidence is what turns a decline preference from an opinion into a case.
- Rules are not fire-and-forget: revisit the thresholds once you can see save rate and review score moving together.
- Whatever your rules decide, a machine, not a person, must guarantee the answer lands before Apple's 12-hour or Google's 24-hour deadline.
This playbook is about the decision itself: once your server can answer Apple's consumption requests and Google's chargeback reviews, what should it actually say? The answer is a policy, not a reflex. Grant everything and you train refund farmers; contest everything and you burn genuine customers for pocket change. The middle path is a short ladder of rules that treats different refunds differently.
The instinct after your first refund wave is to contest everything. Resist it. The stores see your responses in aggregate, and customers you fight over $2.99 leave one-star reviews. The winning strategy is a rules ladder.
First, measure what refunds cost you
You cannot tune what you have not measured, and both stores hide the number in plain sight. In App Store Connect, open Trends, switch the measure to Proceeds, and filter Transaction Type to Refund: that line is your monthly leak. On Google Play, the financial reports in Play Console break out refunds and chargebacks per order. Write the monthly figure down before you touch a single rule; it is your baseline for judging whether any of this works.
While you are there, look at the shape, not just the size: which products get refunded, how long after purchase, and how often the same buyers come back. Those three dimensions are exactly what the ladder below keys on.
| Case | Signal | Response |
|---|---|---|
| Goodwill | Under $5, zero usage, first refund | Grant immediately |
| Real consumption | Days of active usage, then 'unsatisfied' | Decline, backed by the usage curve |
| Repeat refunder | 2+ lifetime refunds on the account | Always contest with full history |
| No data | Buyer can't be matched to usage | Neutral evidence, time-based estimate |
Grant fast where goodwill is cheap
Small purchase, zero usage, first refund ever? Grant it. It costs you a couple of dollars, the customer remembers the experience, and your contested-refund credibility improves for the cases that matter. A rule like price < $5 AND usage == 0 AND prior_refunds == 0 → grant handles this automatically.
Contest with evidence where consumption is real
The unsatisfied-after-heavy-usage pattern is where revenue leaks. Six days of daily usage followed by 'unsatisfied with purchase' deserves a decline preference backed by the usage curve. This is exactly the case consumption data exists for — and it's where automated evidence shines.
Always contest repeat refunders
Refund farming is real: the same account cycling purchase → consume → refund. Track lifetime refunds per user across your apps and harden the response at two or more. The stores weigh this history too; your evidence makes it visible.
Tune the ladder, don't set and forget
Run the rules for a month, then put two numbers side by side: your save rate and your review score. If the save rate climbed and reviews held, tighten another notch, for example by lowering the goodwill price ceiling. If reviews dipped, your contest threshold is catching real customers; loosen it. And remember the consent prerequisite on iOS: Apple expects the customer to have agreed, through your terms, that usage data may be shared before you send any.
Let the deadline never decide
Whatever your rules, the silent failure mode is missing the response window entirely. Make sure something — a system, not a person — is guaranteed to answer before Apple's 12 hours or Google's 24 run out.
Perguntas frequentes
- Should I just decline every refund request?
- No. The stores make the final decision and they see your behavior in aggregate. Granting cheap goodwill cases keeps customers happy and makes your decline preference more credible on the cases where real consumption happened.
- How do I find out how much refunds currently cost me?
- In App Store Connect, open Trends, set the measure to Proceeds, and filter Transaction Type to Refund. In Play Console, the financial reports break out refunds and chargebacks per order. That monthly figure is the baseline your rules should beat.
- Does contesting refunds hurt my app's reviews?
- Contesting the right refunds does not: a customer who used the product for a week rarely reviews over a declined refund. Fighting first-time customers over trivial amounts is what generates angry one-star reviews.
- What if I have no usage data for the buyer?
- Respond anyway. Time-based estimates and delivery status are still evidence, and an answered case always beats silence. You can connect real usage data later and the responses upgrade automatically.
Fontes e leituras adicionais
RefundHalt
O piloto automático de reembolsos para App Store e Google Play
Continue lendo
Anexe um appAccountToken a cada compra na App Store, ou você não conseguirá defender o reembolso
A Apple envia ao seu servidor um CONSUMPTION_REQUEST quando um cliente pede reembolso, mas a transação nunca diz quem ele é. O appAccountToken é o UUID que liga uma compra de volta ao seu usuário. Configure-o e você poderá responder à Apple com dados reais. Pule essa etapa e você estará adivinhando.
Não confirme uma compra do Google Play em três dias e o Google a reembolsa, veja o que isso custa a você
O Google Play reembolsa e revoga automaticamente qualquer compra que seu servidor não confirmar em três dias. É uma falha de integração, não uma decisão do cliente, e é totalmente evitável. Aqui está a regra exata, por que ela dispara e o que cada venda perdida realmente custa.