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.
要点
- 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.
常见问题解答
- 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.
来源和延伸阅读
RefundHalt
App Store 和 Google Play 退款自动驾驶
继续阅读
Apple 可以撤销它已经批准的退款,而你的服务器若忽略这种已撤销的退款,就会把付了钱的客户挡在门外
当 App Store 撤销它已经批准的退款时,它期望你的服务器恢复你此前收回的访问权限。以下说明退款、退款被拒和退款撤销这些通知在 App Store 和 Google Play 上如何运作,以及当你忽略它们时每一种各会付出什么代价。
你应用上的退款主要由你买单,但你损失的并不是你以为的那笔佣金
当客户获得退款时,Apple 和 Google 都会把各自的佣金退还给你,所以你损失的并不是应用商店的抽成。本文讲清楚谁为你应用上的退款买单,你的收款里实际流走了什么,以及为什么拒付比普通退款代价更高。