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는 자동으로 환불하고 취소합니다. 이것은 고객의 결정이 아니라 통합 실수이며, 완전히 예방할 수 있습니다. 정확한 규칙과 그것이 왜 발동하는지, 잃어버린 매출 한 건이 실제로 얼마의 비용인지 설명합니다.