Quick answer: App Store refunds started informal in 2008, became a formal customer-friendly system over the next decade, and only in 2024 did Apple give developers a real way to weigh in, by responding to a CONSUMPTION_REQUEST with consumption data. Understanding that history explains why refunds still tilt toward the customer, and why the developer's role today is narrow but genuinely worth using.
Why the history matters
If refunds feel stacked against developers, it's not your imagination, and it's not an accident. The App Store refund system was built customer-first from the start, and every major change reinforced that. Knowing how it got here makes the present rules make sense: why Apple owns the decision, why the window is short, and why the one lever you do have (responding with consumption data) is worth pulling even though it doesn't guarantee anything.
The timeline
2008, The App Store launches. Apps are one-time purchases. Refunds exist but are handled informally, case by case, with little structure and no developer involvement.
2009, In-app purchases arrive. IAP opens up, especially for games, and the volume and variety of purchases grows, and with it, refund requests. The mechanics are still Apple's alone.
2014, The EU forces a no-questions-asked policy. To comply with EU consumer-protection rules, Apple introduces a 14-day refund right for digital purchases. This cements the customer-first posture: users get a broad right to their money back, and developers get no say in the process.
2019, Server-to-server refund notifications. Apple begins notifying developers' servers when refunds happen, a real step toward visibility. But it's notification, not influence: you learn a refund occurred, you still can't contest it, and it covers in-app purchases rather than subscriptions.
2021, The Consumption API is announced (WWDC21). Apple previews a way for developers to send consumption information in response to refund requests for consumable in-app purchases. For the first time, developers can inform, not decide, but inform, Apple's refund decisioning.
2024, Subscription contesting arrives. Apple expands the system so developers can respond to CONSUMPTION_REQUEST notifications for subscriptions, not just consumables. Because subscriptions are the revenue backbone of so many apps, this is the change that made refund response actually matter at scale, and it's why a tool category for automating it exists at all.
2025 to 2026, Automation becomes the norm. With the window fixed at roughly 12 hours and requests arriving around the clock, responding by hand proves impractical, and automated refund response moves from a nice-to-have to standard practice for serious subscription businesses.
The pattern across every change
Step back and one thread runs through all of it: Apple owns the payment system, so Apple owns the refund. Every improvement for developers has been about visibility and input, never control. You went from knowing nothing, to being notified, to being able to submit evidence but the final decision has never left Apple's hands, and there's no sign it will.
That's the realistic frame for anyone handling refunds today. The goal isn't to win control you were never given. It's to use the input you now have, fully and consistently, instead of forfeiting it.
Where developers stand today
In 2026, the developer's role is narrow but real:
You're notified of refund requests in real time via App Store Server Notifications.
For eligible purchases and subscriptions, you can respond to a CONSUMPTION_REQUEST with consumption data and a refund preference.
Apple weighs your input and decides.
The one lever is that consumption response and its value is entirely about using it every time, inside the window. That's precisely the part that's hard to do manually and easy to automate. (For how it works end to end, see How to Automate Apple Refund Requests, and for the timing problem specifically, The 12-Hour Window.)
RefundSensor exists because of exactly this history: Apple finally gave developers a voice in refund decisions, but made it time-boxed and relentless. Automating the response is how you actually use the voice the last 15 years slowly earned you.
Official sources
For specifics, treat Apple's own materials as the final authority:
The industry spent 15 years earning developers a voice in refunds. Use it every time. RefundSensor automatically responds to Apple CONSUMPTION_REQUEST notifications inside the window and tracks every outcome, for Apple and Google Play. Start free
Frequently asked questions
Apple expanded the consumption-response system to subscriptions. The underlying Consumption API for consumable in-app purchases was introduced earlier, announced at WWDC21.
Because Apple owns the payment system. Users buy through Apple, so Apple collects the money and handles refunds. Developers have gained visibility and input over time but never final control.
Apple introduced a 14-day no-questions-asked refund right for digital purchases to comply with EU consumer-protection rules, reinforcing a customer-first refund posture.
No. Developers can respond to a CONSUMPTION_REQUEST with data and a preference, but Apple always makes the final decision.
Because the response window is short (~12 hours) and requests arrive at all hours, making manual handling impractical. Automation ensures every eligible request is answered in time.
