Consumable in-app purchase refunds are the ones that cost you twice, because you already spent the money delivering them
A consumable in-app purchase, a coin pack, a gem bundle, a batch of AI credits, is the one purchase you have already spent money delivering before anyone asks for it back. Here is what a consumable refund costs you on the App Store and Google Play, and the one window where your answer counts.

Key takeaways
- A consumable in-app purchase is redeemed the instant it is bought. Coins, gems, credits, and generation packs turn into compute, API calls, and delivered content before the customer ever thinks about a refund, which is why a consumable refund reverses the price but never the cost you already paid.
- On the App Store you cannot issue or block a consumable refund. Apple decides every one through reportaproblem.apple.com. Your only input is the CONSUMPTION_REQUEST notification, which gives you 12 hours to send consumption information back.
- The CONSUMPTION_REQUEST fires for consumables and auto-renewable subscriptions, and for a consumable your answer counts more, because Apple cannot infer usage from elapsed time the way it does for a subscription. The consumptionStatus and consumptionPercentage you report are the actual evidence.
- consumptionStatus takes four values: 0 undeclared, 1 not consumed, 2 partially consumed, 3 fully consumed. consumptionPercentage is an integer in milliunits, where 100,000 means 100 percent consumed. A fully consumed consumable is the strongest case you can make against a refund.
- On Google Play you can refund a consumable yourself from the Play Console or the Order Management API, with an optional revoke, but Google's 48-hour self-service refund runs without asking you at all, and a spent consumable cannot be clawed back out of your economy after the fact.
- The only Google Play flow that asks for your side of a consumable dispute is a chargeback review through orders.reviewrefund, and you get 24 hours to respond. Everything faster than that is decided without you.
- From August 3, 2026, a Google Play chargeback moves the purchase price less Play's service fee, plus the bank's chargeback fee, onto the developer. On a consumable you already delivered, that turns a single disputed coin pack into a loss larger than the sale.
Every refund hurts, but a consumable in-app purchase refund is the one that takes the money back after you have already spent it. A subscription refund reverses access you can switch off. A non-consumable refund takes back a permanent unlock. A consumable is different. A coin pack, a gem bundle, a pack of AI image credits, a boost, is redeemed the moment it lands in the customer's balance, and by the time a refund request shows up the coins are gone, the credits are burned, and the compute that produced the output has already been billed to you. This is what makes consumables the sharpest refund problem in an app, and why the usual advice about proving value does not save you here.
Where a consumable refund is different from every other refund
The store treats every purchase type as one of three things, and refunds land differently on each. The difference is not academic. It decides how much of your cost comes back.
A consumable is spent the moment you deliver it
A non-consumable, a permanent level unlock or an ad removal, stays on the account. A subscription grants time-boxed access you can revoke. A consumable is used up on redemption. The customer buys 1,000 coins, spends 600 on a feature that called your servers, and the 600 are gone. The value was not held in reserve waiting to be judged. It was converted into your paid costs on the spot.
That is why the stores built a separate refund evidence flow for consumables in the first place. For a subscription, the store can reason about how much of the paid period elapsed. For a consumable, there is no clock to read. Either you delivered the coins and the customer used them, or you did not, and only your server knows which.
You cannot un-deliver what has been consumed
When a refund is granted on a consumable, the money reverses but the coins do not un-spend themselves. If a customer bought a credit pack, generated forty images with it, and then got a refund, you paid for forty generations and received nothing for them. Revoking the remaining balance is the most you can do, and only if any of it is left. A fully consumed consumable leaves nothing to take back.
What a consumable in-app purchase refund actually costs you
The headline number on a consumable refund is the sale price coming off your books. The real number is the sale price plus everything you already spent turning that purchase into delivered value. Most of the second part never comes back.
| Cost | When you pay it | Comes back on a refund |
|---|---|---|
| Compute or GPU time to fulfill what the coins bought | At redemption, before the refund | No |
| Third-party API calls the purchase triggered | At redemption | No |
| Storage and bandwidth for delivered output | At and after redemption | No |
| The store's commission on the sale | At purchase | Usually yes, the store reverses its own cut |
| The purchase price itself | At purchase | No, the full amount reverses to the customer |
| A bank chargeback fee, if it becomes a dispute | After the charge | No, and on Google Play you now pay it too |

The refund reverses the price, not the compute
Say a customer buys a $9.99 pack of AI credits and spends all of them generating output. Each generation cost you a real API call. When Apple grants the refund, the $9.99 goes back and Apple reverses its commission, so your reported revenue nets to zero. Your compute bill for those generations does not net to zero. You paid it, it cleared, and it stays paid. The refund did not touch it. This is the exact case RefundHalt was built around, because elapsed time proves nothing about a consumable and the only defense is knowing what was actually delivered.
The App Store side, the one 12-hour window where your answer counts
On the App Store you have no refund switch. You cannot grant a consumable refund and you cannot deny one. Every refund is decided by Apple, one request at a time, through reportaproblem.apple.com. What you get instead is a single chance to speak, and it is narrow.
The CONSUMPTION_REQUEST is the only place Apple asks you anything
When a customer requests a refund on a consumable, and consumption data sharing is enabled for the app, your server receives a CONSUMPTION_REQUEST App Store Server Notification. You then have 12 hours to reply with Send Consumption Information. Miss the window and the decision is made without your input. Apple introduced this flow for consumables specifically, and in 2024 extended the same notification to auto-renewable subscriptions.
The reply carries a set of fields. The two that matter most for a consumable describe how much of it was used and whether you delivered it at all.
| Field | What it reports | Values that matter |
|---|---|---|
| consumptionStatus | How much of the consumable the customer used | 0 undeclared, 1 not consumed, 2 partially consumed, 3 fully consumed |
| consumptionPercentage | The used share, in milliunits | 100,000 means 100 percent consumed |
| deliveryStatus | Whether your app actually delivered a working item | delivered, or one of several undelivered reasons |
| refundPreference | Your preferred outcome | grant full, grant prorated, or decline |
| customerConsented | Whether the customer agreed to share consumption data | must be true or Apple ignores the rest |
Why your reply matters more on a consumable than on a subscription
For an auto-renewable subscription, Apple already computes how much of the billing period elapsed and leans on that. Your consumption reply mostly nudges a preference. For a consumable there is no elapsed period to measure. The consumptionStatus you send is close to the only usage signal Apple has. If your server can say, with certainty, that the customer consumed 100 percent of the pack, that is the difference between a defensible transaction and a silent giveaway. If customerConsented is false, none of it is read, so the consent has to be captured in your purchase flow long before the request ever arrives.
The Google Play side, you can refund but the item is already gone
Google Play gives the developer more direct control than Apple does, and less of it helps than you would think, because the fastest refund paths never reach you.
The 48-hour self-service window skips you entirely
Within 48 hours of purchase, a Google Play customer can request a refund through the store and often get it automatically, without your involvement. You are not asked, you do not weigh in, and for a consumable that means the coins are spent and the money is gone before you know a request happened. The Voided Purchases API is how you learn about it after the fact, so you can revoke whatever entitlement is left.
Refund and revoke, and what revoke cannot do
You can issue a consumable refund yourself from the Play Console or the Order Management API, with an optional revoke parameter that pulls back access. Revoke works cleanly on things that persist, a subscription or a durable entitlement. It cannot un-spend a consumable. If the customer already turned the coins into a delivered result, revoke has nothing to reclaim, and you carry the fulfillment cost with no offsetting sale.
What it means in money when the chargeback rules change
A refund and a chargeback are not the same loss, and on a consumable the gap is about to widen. A refund reverses the sale and usually returns the store's commission. A chargeback is the customer's bank forcing the money back, and it is final.
From August 3, 2026, Google Play shifts the cost of a chargeback onto the developer: the purchase price less Play's service fee, plus the bank's chargeback fee. On a consumable you have already delivered, the arithmetic is brutal. You paid the compute to fulfill it, you lose the purchase price, and now you pay the bank's fee on top. A single disputed coin pack can cost more than several sold ones earned. The lesson is not to fight chargebacks after the fact, which you rarely win, but to keep unhappy customers in the refund path, where the loss is smaller and the store's cut comes back, instead of the dispute path, where it does not.
How to lose less to consumable refunds
You cannot stop the stores from refunding. You can make sure that when they do, you have delivered honestly, answered fully, and can see the pattern before it grows.
Deliver server-side and record it
Grant consumables from your server after you verify the transaction, and log the moment of delivery and consumption against the transaction id. That record is what lets you answer a CONSUMPTION_REQUEST with a true consumptionStatus instead of a guess. A consumable you delivered but cannot prove you delivered is a refund you will lose by default.
Answer every CONSUMPTION_REQUEST, and answer it straight
Reply inside the 12 hours, every time. Report the real consumptionStatus. Overstating usage on a customer who genuinely did not receive their coins invites the chargeback you were trying to avoid, and the chargeback is the more expensive outcome. Honest, complete, on time. That is the whole play, and it only works if the data is already captured before the request lands.
Watch consumables as their own refund cohort
Blend consumable refunds into your overall refund rate and the signal disappears. Track them on their own. A spike in refunds on one coin pack or credit tier usually points at a specific problem, a broken redemption, a misleading price, a pack that delivers less than the icon implies. Read consumable refunds against consumable sales, by product, and the cause is usually obvious.
The short version
A consumable in-app purchase refund is the refund that costs you before you even hear about it, because the coins were spent, the credits were burned, and the compute was billed the moment the customer bought. Apple lets you speak once, for 12 hours, through the CONSUMPTION_REQUEST, and on a consumable that reply is close to the only evidence that exists. Google Play lets you refund but rarely asks first, and from August 2026 a consumable chargeback costs more than the sale did. Deliver server-side, log what you delivered, answer every request truthfully, and keep the loss in the refund lane instead of the dispute lane.
Frequently asked questions
- Can I refund a consumable in-app purchase myself?
- On Google Play, yes. You can issue a consumable refund from the Play Console or the Order Management API, with an optional revoke. On the App Store, no. Apple decides every refund through reportaproblem.apple.com, and your only input is the CONSUMPTION_REQUEST notification you have 12 hours to answer.
- What is a CONSUMPTION_REQUEST and how long do I have to respond?
- A CONSUMPTION_REQUEST is the App Store Server Notification Apple sends when a customer requests a refund on a consumable, if consumption data sharing is enabled. You have 12 hours to reply with Send Consumption Information, reporting fields like consumptionStatus and consumptionPercentage. Miss the window and Apple decides without your input.
- Why does my consumption reply matter more for a consumable than a subscription?
- For a subscription, Apple computes how much of the billing period elapsed and relies on that, so your reply mostly sets a preference. For a consumable there is no elapsed time to measure, so the consumptionStatus you report is close to the only usage evidence Apple has. A fully consumed consumable is the strongest fact you can send.
- If a consumable refund is granted, do I get the compute cost back?
- No. The refund reverses the purchase price and usually the store's commission, but the compute, API calls, and storage you spent delivering the consumable were already billed and stay billed. That is why a consumable refund costs you more than the sale price alone, and why proving delivery is the only real defense.
- How does the August 2026 Google Play chargeback change affect consumables?
- From August 3, 2026, a Google Play chargeback moves the purchase price less Play's service fee, plus the bank's chargeback fee, onto the developer. On a consumable you already delivered, you lose the fulfillment cost, the sale price, and the bank fee together, so a single disputed pack can cost more than several sold ones earned. Keeping customers in the refund path, not the chargeback path, is the cheaper outcome.
Sources and further reading
- Apple Developer: Send Consumption Information (App Store Server API)
- Apple Developer: consumptionStatus values
- Apple Developer: ConsumptionRequest fields
- Apple: Request a refund at reportaproblem.apple.com
- Google Play Console Help: Manage your app's orders and issue refunds
- Google Play Developer API: Method orders.refund
- Google Play Developer: Voided Purchases API
- Google Play Console Help: Updates to refund protection and chargeback cost responsibility (August 3, 2026)
RefundHalt
The refund autopilot for the App Store and Google Play
Keep reading
Unauthorized in-app purchases by children get refunded to the parent almost every time, and you carry the cost
When a child buys a coin pack on a parent's phone, both Apple and Google refund it and neither one asks you first. Regulators built it that way. Here is how these unauthorized in-app purchase refunds work on each store, the 15-minute window where the money goes, and what one actually costs you.
You never owned the app refund tax, so a refund costs you your share, not the total on the receipt
Refund an in-app purchase and the receipt shows the price plus tax going back. The tax was never your money. Apple and Google collect and remit it as the merchant of record, then reverse it on a refund without touching your share. Here is what a refund actually costs, and the one setup where the tax becomes yours.