Does sending consumption data to Apple stop a refund?

Not on its own. Apple's documentation says the App Store uses a variety of factors to decide a refund and that your consumption data is used to inform that decision. Your reply, including a refundPreference of prefer decline, is one input Apple weighs, so it can move a borderline case but will not guarantee a denial, especially on a purchase the customer fully consumed.

How long do I have to respond to a CONSUMPTION_REQUEST?

12 hours. Apple says to respond within 12 hours of receiving the CONSUMPTION_REQUEST notification through the Send Consumption Information endpoint. A reply that arrives after the window is a reply Apple never weighed, which is why the response has to be automated rather than handled by a person who may be asleep.

Why did Apple refund a purchase after I sent prefer decline?

Because prefer decline is a recommendation, not a command. Apple states your refund preference is one of a variety of factors it uses to inform its decision. On a given request the customer's history, the reason they gave, the dollar amount, and Apple's own fraud signals can outweigh your preference, so a refund after a prefer decline is the flow working as documented.

Do I need customer consent to send consumption data?

Yes. Apple rejects a Send Consumption Information request unless customerConsented is true, and its guidance is that if the customer did not consent you should not respond to the CONSUMPTION_REQUEST at all. Apple also states that you, the developer, are solely responsible for obtaining valid consent before sharing the customer's data.

Does the consumption flow work for subscriptions or only consumables?

Both, since WWDC24. The CONSUMPTION_REQUEST now fires for a consumable in-app purchase or an auto-renewable subscription. For auto-renewable subscriptions Apple calculates consumption itself and does not accept a prorated preference, so your leverage is narrower than on a consumable whose usage you can describe directly.

All articles

Deep diveAugust 27, 20269 min read

Your consumption data informs Apple's refund decision, it doesn't control it

When a customer asks Apple for a refund, you get 12 hours to send consumption data. Apple's own docs call it one of a variety of factors, not a verdict. Here is what your data actually moves, why a DECLINE can still end in a refund, and what the nudge is worth in dollars.

A hand placing one small brass weight onto a balance scale already holding several others, standing in for consumption data as one factor in Apple's refund decision

Key takeaways

When a customer requests a refund, Apple sends your server a CONSUMPTION_REQUEST notification and gives you 12 hours to reply with consumption data through the Send Consumption Information endpoint. Miss the window and Apple decides without your input.
In Apple's own words, the App Store uses a variety of factors to decide a refund, and the consumption information you send is used to inform that decision. Your refundPreference is one of those factors, not the verdict.
You can send a refundPreference of prefer decline, prefer grant full, or prefer grant prorated. Apple weighs it. That is why teams see a purchase they marked prefer decline still get refunded, and it is working as documented.
Apple rejects your consumption data unless customerConsented is true. If the customer did not consent to share the data, Apple's guidance is to not respond to the notification at all, and you are solely responsible for obtaining that consent.
Since WWDC24 the CONSUMPTION_REQUEST fires for auto-renewable subscriptions too, not only consumables, so the same 12-hour reply now reaches far more of your refunds than it used to.
For auto-renewable subscriptions Apple calculates consumption itself and forbids a prorated preference, so your leverage there is thinner than on a consumable you can describe as fully consumed.
The dollars you already spent serving the purchase, the compute, the third-party API calls, the storage, are gone whether Apple grants the refund or not. Your consumption reply changes the refund, never the cost you already paid to deliver.

A customer taps refund, and within a minute your server gets a CONSUMPTION_REQUEST from Apple. You have 12 hours to answer with consumption data, and it is tempting to read that reply as a veto: send prefer decline, keep the money. It is not a veto. Apple's own documentation says the App Store uses a variety of factors to determine if a refund request is approved or denied, and that the consumption information you provide is used to inform its refund decisions. Inform, not decide. This post walks what your consumption data actually moves, why a purchase you marked prefer decline can still be refunded, and what the whole exercise is worth once you count the money you already spent.

What Apple actually does with your consumption data

The Send Consumption Information endpoint exists so you can hand Apple context at the moment a refund is in question. It does not hand you the decision. Reading the flow in the right order is the difference between setting sane expectations and filing a bug against behavior that is documented.

The App Store decides, and you recommend

Apple is explicit about the split. On the Send Consumption Information reference, Apple writes that the App Store uses a variety of factors to determine if a refund request is approved or denied, and that it uses the consumption information you provide to inform its refund decisions. On the refundPreference field itself, Apple states that your refund preference is one of a variety of factors that the App Store uses to inform its refund decisions. So the strongest signal you can send, a flat prefer decline, is still one input into a model you do not control. The customer's history, the reason they gave, the product type, and Apple's own fraud signals all sit in that same model beside your reply.

CONSUMPTION_REQUEST now covers subscriptions, not just consumables

This used to be a consumables story. Since WWDC24 the CONSUMPTION_REQUEST notification fires when a customer requests a refund for a consumable in-app purchase or an auto-renewable subscription. That is a large expansion of surface. The same 12-hour reply now applies to subscription refunds, where your leverage is different because Apple computes consumption for auto-renewables on its own and will not accept a prorated preference from you. Read the product type on every request before you decide how hard your reply can push.

The five inputs you are allowed to send

The V2 request body Apple accepts is small, five fields do the work, and three of them are required. Each one is an input Apple weighs, not a switch that forces an outcome. Here is what you can put in the reply and what it tells Apple.

Field	Required	What it tells Apple
customerConsented	Yes	Whether the customer agreed to share this refund data. Must be true or Apple rejects the request.
consumptionStatus	No	How much was used: undeclared, not consumed, partially consumed, or fully consumed.
deliveryStatus	No	Whether your app delivered a working purchase, or hit a problem you want on record.
sampleContentProvided	No	Whether you offered a free sample, trial, or a description of the feature before the purchase.
refundPreference	No	Your recommended outcome: prefer decline, prefer grant full, or prefer grant prorated.

Two mechanics decide whether your reply even counts. One is a clock. The other is a consent flag that stops a lot of well-meant replies at the door.

Respond within 12 hours or the moment passes

Apple's instruction is plain: respond within 12 hours of receiving the CONSUMPTION_REQUEST notification. That is the whole window. A refund request does not wait for your next business day, and a consumption reply that lands late is a reply Apple never weighed. If you are answering these by hand, the 12-hour clock is the part that quietly fails first, on weekends, on holidays, and at 3am in your timezone. The reply has to be automated to be reliable, because the window does not care when your team is awake.

An analog clock face on a desk beside a smartphone lying screen down, standing in for the 12-hour window to respond to Apple's CONSUMPTION_REQUEST

You cannot send data unless the customer consented

Here is the gate teams trip on. Apple rejects a Send Consumption Information request whose customerConsented value is anything other than true. In Apple's words, if the customer provided consent, respond by calling the API and sending the consumption data; if not, do not respond to the CONSUMPTION_REQUEST notification. Apple also puts the responsibility squarely on you: you must obtain valid consent from the customer before sharing their personal data, and you, the developer, are solely responsible for obtaining it. So the first question on every request is not how much did they use, it is did this customer agree to let us tell Apple. No consent, no reply, and the refund is decided on everything except your side of the story.

What actually moves Apple's refund decision

If the reply is a recommendation, the honest question is how much it recommends. The answer is that your data matters most exactly where a human would hesitate, and least where the outcome was never really in doubt.

Why you can send prefer decline and still see a refund

Developers report sending prefer decline on a purchase the customer fully consumed and watching Apple refund it anyway. That is not a broken API. Apple told you it weighs a variety of factors, and on any given request some of those factors can outweigh a fully-consumed consumable: a customer with a clean history, a stated reason Apple treats as strong, a small dollar amount, a first-time request. Your reply pushed against the refund. Other inputs pushed harder. The lesson is not to stop replying, it is to stop expecting a clean consumable to always survive. Where the signal is genuinely mixed, a partially consumed status, a documented delivery problem, and an honest preference are the inputs that can tip a borderline case your way.

What a recommendation is worth in dollars

A refund is not the price of the sale. It is the price of the sale plus everything you already spent to deliver it, and the consumption reply only ever touches the first part.

The money is already spent by the time the request arrives

By the time Apple asks whether to refund, the customer has already used the thing. On a consumable that means the compute ran, the third-party API calls were billed, the images or tokens or generations were produced, and the storage was written. Those are paid costs on your side and they do not come back if Apple declines the refund, and they are lost twice if Apple grants it. Your consumption reply can win back the sale price on a borderline case. It cannot win back the cost of goods you already handed over. That is the real reason a fully consumed purchase is the expensive one to refund, and it has nothing to do with how long ago it was bought.

The sale price: your net proceeds after Apple's commission, reversed if the refund is granted. This is the only piece your reply can influence.
The delivery cost: compute, API calls, storage, and any payout you already made against the purchase. Gone regardless of the decision.
The staff time: every refund answered by hand is minutes of a person's day, and the 12-hour window means those minutes land at inconvenient hours.
The pattern you miss: a customer who refunds again and again is a cost you only see if you are tracking consumption and history across requests, not treating each one as a one-off.

How Google Play handles the same question

Apple is not the only store that asks you to weigh in and then decides for itself. Google Play runs a parallel flow for bank chargebacks, and the shape is the same: you send evidence, the store decides. The differences are in the clock and in what you are allowed to send.

Question	App Store	Google Play
Trigger	CONSUMPTION_REQUEST notification	PendingRefundReviewNotification for a chargeback
Your window	12 hours	24 hours
How you answer	Send Consumption Information	orders.reviewrefund
Your recommendation	refundPreference: decline, grant full, grant prorated	refundPreference: APPROVE, DECLINE, or NEUTRAL
Who decides	The App Store	Google Play, or the bank on a chargeback

The takeaway across both stores is identical. Your job is to answer inside the window with accurate consumption evidence and an honest preference. The store's job is to decide. Confusing the two is how a team ends up either ignoring the window because the reply is only a recommendation, or trusting the reply as a veto and getting blindsided when a refund lands anyway. Neither is right. Answer every time, answer accurately, and treat the outcome as a decision you informed, not one you made.

RefundHalt catches the CONSUMPTION_REQUEST the moment Apple sends it, checks consent, assembles the consumption status, delivery status, and an evidence-based refund preference, and replies inside the 12-hour window without anyone on your team watching a clock. It does the same for Google Play's chargeback review inside its 24-hour window. You cannot make Apple decide your way. You can make sure Apple never decides without your side of the story, on every refund, in time.

Frequently asked questions

Does sending consumption data to Apple stop a refund?: Not on its own. Apple's documentation says the App Store uses a variety of factors to decide a refund and that your consumption data is used to inform that decision. Your reply, including a refundPreference of prefer decline, is one input Apple weighs, so it can move a borderline case but will not guarantee a denial, especially on a purchase the customer fully consumed.
How long do I have to respond to a CONSUMPTION_REQUEST?: 12 hours. Apple says to respond within 12 hours of receiving the CONSUMPTION_REQUEST notification through the Send Consumption Information endpoint. A reply that arrives after the window is a reply Apple never weighed, which is why the response has to be automated rather than handled by a person who may be asleep.
Why did Apple refund a purchase after I sent prefer decline?: Because prefer decline is a recommendation, not a command. Apple states your refund preference is one of a variety of factors it uses to inform its decision. On a given request the customer's history, the reason they gave, the dollar amount, and Apple's own fraud signals can outweigh your preference, so a refund after a prefer decline is the flow working as documented.
Do I need customer consent to send consumption data?: Yes. Apple rejects a Send Consumption Information request unless customerConsented is true, and its guidance is that if the customer did not consent you should not respond to the CONSUMPTION_REQUEST at all. Apple also states that you, the developer, are solely responsible for obtaining valid consent before sharing the customer's data.
Does the consumption flow work for subscriptions or only consumables?: Both, since WWDC24. The CONSUMPTION_REQUEST now fires for a consumable in-app purchase or an auto-renewable subscription. For auto-renewable subscriptions Apple calculates consumption itself and does not accept a prorated preference, so your leverage is narrower than on a consumable whose usage you can describe directly.

Sources and further reading

RefundHalt

The refund autopilot for the App Store and Google Play

Keep reading

Playbook8 min read

Tag every Google Play purchase with an obfuscated account id, or a chargeback arrives with no way to trace it

Google Play lets you stamp a stable, hashed id onto every purchase and reads it back when a dispute lands. Set it and a chargeback review ties to the exact user whose usage you have to report. Skip it and you are matching a bare order id to guesses under a 24-hour clock.

Deep dive8 min read

An unrecognized charge on a bank statement turns into a chargeback, and a chargeback costs you more than a refund

When a customer can't tell what your app charged them, they call the bank instead of you, and that dispute lands as a chargeback. Apple shows everything as apple.com/bill and lets you change nothing. Google Play lets you set the statement name. Here is what each costs and what you control.