Quick answer: When a customer asks Apple for a refund on an in-app purchase or subscription, the App Store sends your server a CONSUMPTION_REQUEST notification and gives you roughly 12 hours to respond with consumption data through the Send Consumption Information endpoint. Apple weighs that data in its decision. If you don't respond in time, Apple decides without your input, and unjustified refunds are often granted by default. Automating this response means every request gets answered inside the window, every time.
The short version
Apple owns the payment rails. When someone buys a subscription or in-app purchase in your app, Apple collects the money, takes its cut, and handles refunds. For years developers had no say in refund decisions at all.
That changed. Apple now lets you send consumption information, structured evidence about how the customer used what they bought, and factors it into the refund decision. You don't get to approve or deny the refund yourself; Apple still makes the final call. But silence gives Apple nothing to work with, and a well-formed response gives it context.
The catch is timing and consistency. The refund window is short, the apple refund response time is limited, it opens at unpredictable hours, and doing this manually at any real volume is impossible. That's the problem automation solves.
How Apple's refund flow actually works
Here's the sequence, end to end:
The customer requests a refund. They go to reportaproblem.apple.com, pick the purchase, choose a reason, and submit.
Apple notifies your server. For eligible purchases, the App Store sends a CONSUMPTION_REQUEST notification through App Store Server Notifications V2. The payload contains signed transaction data identifying the purchase.
You respond with consumption data. You call Send Consumption Information with the original transaction ID and a structured ConsumptionRequest body describing delivery, usage, consent, and your refund preference.
Apple decides. Its refund decisioning system weighs your data alongside the customer's history and other factors, then issues a decision.
You're notified of the outcome. A REFUND notification means the refund was granted; a REFUND_DECLINED notification (for requests initiated via the StoreKit API) means it wasn't.
What a CONSUMPTION_REQUEST contains, and what you send back
The notification itself carries signed transaction info and the customer's stated reason (consumptionRequestReason). Your response is where the real work happens. Apple defines a structured ConsumptionRequest with fields including:
Here is the table reconstructed from your image:
Field | What it tells Apple |
customerConsented | Whether the customer agreed to share this data. Must be true or Apple rejects the submission. |
consumptionStatus | Whether the purchased content was not consumed, partially consumed, or fully consumed. |
deliveryStatus | Whether the in-app value or service was actually delivered. |
accountTenure | How long the customer has had an account with you. |
playTime | How much time the customer has spent in the app. |
lifetimeDollarsPurchased | Total the customer has spent across your apps. |
lifetimeDollarsRefunded | Total previously refunded to the customer. |
sampleContentProvided | Whether the customer could try content before buying. |
userStatus | The current status of the customer's account (active, suspended, etc.). |
refundPreference | Your recommendation to Apple: undeclared, prefer grant, or prefer decline. |
Your recommendation to Apple: undeclared, prefer grant, or prefer decline.
Each field is a signal. Left blank, it's context Apple never gets. We break down every field and its accepted values in What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown.
The 12-hour window
You have about 12 hours to respond to a CONSUMPTION_REQUEST in production. This consumption_request deadline is critical because missing it means you forfeit the chance to provide input; Apple decides on what it already has.
The problem isn't the length of the apple refund response window, it's when it opens. Refund requests don't wait for business hours. The refund window can open overnight, on a weekend, or during a holiday, and a manual review queue can't cover that without someone permanently on call. This is the single most common reason developers lose refunds they could have contested: not a bad response, but no response. We go deeper on this in The 12-Hour Window: Why Most Developers Lose Refunds by Default.
The consent requirement, don't skip this
This is the part that trips up nearly everyone, and it's a legal issue, not just a technical one.
Apple's CONSUMPTION_REQUEST does not tell you whether the customer consented to share their data. That's by design, Apple expects your app, not your server, to collect and confirm consent before any consumption data is sent. You must set customerConsented to true in your API call, and you, the developer, are solely responsible for having obtained valid consent, because you're the one sharing data you collected from the user.
Get this wrong and you don't just risk a rejected submission, you risk a GDPR or DPDP compliance problem. Handle consent properly in your app's terms and purchase flow before you automate anything. We cover exactly where and how in Customer Consent & the Consumption API: What Apple Actually Requires.
What automating this actually takes
On paper, automating the response sounds like a weekend project: catch the notification, fill in the fields, call the endpoint. In production, it's a standing piece of infrastructure, and understanding what's really involved is the difference between "we'll build it" and "we'll skip it."
A reliable in-house responder has to receive and verify Apple's signed notifications, pull accurate, up-to-the-moment usage and billing data for each customer the instant a request arrives, map that data to Apple's exact ConsumptionRequest values, and submit it inside the ~12-hour apple refund response window, at any hour, without a person watching. On top of that it needs deadline-safe retries, failure handling, logging you can audit, monitoring so you know if it breaks, and ongoing maintenance every time Apple revises its payloads or fields. None of that is your product. All of it is infrastructure you'd own indefinitely for a workflow that has nothing to do with what your app does. (We go deeper on the notification layer in Setting Up App Store Server Notifications V2.)
That's the calculation most teams end up making: the mechanics are knowable, but building and babysitting a compliant, deadline-safe responder is a permanent cost with no upside to the app itself. It's exactly the kind of undifferentiated plumbing a managed service is for.
That's what RefundSensor does. It wires into your App Store Connect setup with one webhook URL, no SDK, no code changes, no app resubmission, then answers every CONSUMPTION_REQUEST automatically inside Apple's refund window, maps the fields from your data, handles retries and monitoring, keeps current with Apple's changes, and records every outcome in one dashboard. For teams looking for Apple refund automation software, this removes the need to build and maintain the entire refund-response infrastructure yourself.
Does responding actually reduce refunds?
Yes, though results vary and Apple always decides. Submitting accurate consumption data gives Apple's system more context, and developers who respond consistently generally see fewer granted refunds than developers who leave requests unanswered. Choosing a "prefer decline" recommendation, where your evidence genuinely supports it, is one more input Apple considers.
Responding within the apple refund response time can therefore help ensure Apple receives your information before the consumption_request deadline. It doesn't guarantee an outcome, but it prevents a missed response from becoming the reason your information wasn't considered.
What automation can and can't do
Be honest with yourself about the ceiling:
It can't guarantee any specific refund is declined. Apple makes the final decision, every time.
It can't contest refunds that never generate a CONSUMPTION_REQUEST, not every refund does.
It can make sure every eligible request is answered inside the apple refund response window, with consistent, accurate data, so you never lose a refund simply because nobody saw the notification.
It can automate how to respond to Apple refund requests within 12 hours, reducing the risk of missing the consumption_request deadline.
That last point is where the money is. You're not overriding Apple, you're making sure you always get your turn to speak.
Why manual handling can't close the gap
Teams that try to handle this by hand usually land in one of three places:
The "we'll check in the morning" approach — which misses every overnight and weekend request, i.e. a large share of them.
The on-call rotation — someone technically responsible for a 12-hour-window task around the clock, which is a miserable job and still human-fallible.
The "we gave up" approach — the quiet majority, who stopped responding because keeping up was impossible.
The common thread: the deadline is machine-speed and the response is human-speed. You can't out-discipline a clock that runs while you sleep. Every manual approach is really just choosing which requests to miss.
This is a timing problem, not a product problem
The reframe that matters: losing these refunds says nothing about your app.
You can have a great product, happy users, and a low genuine refund rate, and still bleed revenue through this window because the losses aren't about whether the refund was deserved. They're about whether anyone was there to respond. That's oddly good news. A product problem is hard to fix. A timing problem has a clean solution: make sure something is always there to respond, instantly, regardless of the hour.
What actually fixes it
The only thing that closes a machine-speed window is a machine-speed response. Automation answers every CONSUMPTION_REQUEST the moment it arrives with accurate consumption data and your refund preference inside Apple's window, at 3am on a Sunday exactly as reliably as at 3pm on a Tuesday.
That's what RefundSensor does. It listens for every refund request, responds automatically inside the window, and tracks the outcome, so you never again lose a refund simply because no one saw the notification. Setup takes about 30 minutes with no code changes, and it covers Google Play's chargeback-review window too, which has the same "opens whenever, closes fast" problem. (For the full picture, see How to Automate Apple Refund Requests and Google Play Refunds & Chargebacks.)
[PRODUCT DATA PLACEHOLDER insert a real RefundSensor stat here once the Refund Index is live, e.g. share of requests that arrive outside business hours, or money defended. Do NOT invent a number.]
You're not gaming Apple. You're just making sure you always get your turn to speak the turn most developers forfeit without realizing it.
Official sources {#official-sources}
Apple's timing and process can change, so treat its documentation as the final authority:
The window opens whenever your customers feel like it. Be there anyway. RefundSensor answers every Apple refund request automatically, inside the 12-hour window 3am, weekends, holidays included and tracks every outcome. About 30 minutes to set up, no code changes. Start free →
Internal links to add once published: Apple refund automation cornerstone · CONSUMPTION_REQUEST field-by-field · Google Play refunds cornerstone.
Frequently asked questions
About 12 hours in production, starting when the customer submits the request. Miss it and Apple decides without your input.
Apple proceeds on the information it has, which is the customer's request and nothing from you. Unanswered requests, including unjustified ones, are often granted by default.
No. The window is set by Apple. The only reliable way to always make it is to respond automatically, the moment the request arrives.
Usually not on the merits, on timing. Requests arrive outside business hours and a manual process can't answer every one in time, so contestable refunds are lost by default.
No. Apple always makes the final decision. Automation guarantees you respond every time; it doesn't override Apple's call.
