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 退款自动驾驶
继续阅读
为每一笔 App Store 购买附加 appAccountToken,否则你无法为退款辩护
当客户申请退款时,Apple 会向你的服务器发送一个 CONSUMPTION_REQUEST,但这笔交易从不说明他们是谁。appAccountToken 就是那个把购买关联回你的用户的 UUID。设置它,你就能用真实数据回应 Apple。跳过它,你就只能靠猜。
三天内不确认 Google Play 购买,Google 就会退款,这会让你付出什么代价
只要你的服务器在三天内没有确认某笔购买,Google Play 就会自动退款并撤销这笔购买。这是集成失误,不是客户的决定,而且完全可以避免。下面讲清楚具体规则、它为什么会触发,以及每一笔流失的销售真正的代价。