Apple's Send Consumption Information now asks for five fields, not twelve, and here's each one

The list of facts Apple asks you for when a customer wants a refund got a lot shorter. The Send Consumption Information payload, the one reply a developer gets to send into an App Store refund decision, used to have twelve fields. It now has five. Apple trimmed it around WWDC24 and folded most of the old account-profiling questions into two simple ones and a number. Fewer fields is not a small edit. It changes what evidence Apple weighs, and it changes which fields you cannot afford to get wrong.

Here is why this is worth your attention and not just a schema note. This payload is the only moment in an Apple refund where your side of the story reaches the decision. A consumable refund reverses revenue you already spent real money to deliver, and the five fields are how you tell Apple the product was delivered and used. Miss the 12-hour window or fill a field in wrong, and Apple rules on the customer's claim alone.

What Send Consumption Information is

Send Consumption Information is the App Store Server API endpoint you call after Apple sends your server a CONSUMPTION_REQUEST notification. That notification means a customer asked Apple for a refund on an in-app purchase and Apple wants your input before it decides. You answer by putting a small JSON body, the ConsumptionRequest, to the endpoint. Apple reads it, weighs it against the customer's history, and makes the call. You never decide the refund. You supply facts.

The body is the whole interface. There is no separate form, no appeal, and no second submission that counts. Whatever you send in that one payload is your entire case, so the meaning of each field matters more than the field count suggests.

The five fields Apple asks for now

The current ConsumptionRequest has five members. Three are required and two are optional. Everything Apple used to ask about the customer's account, their tenure, their lifetime spend, their lifetime refunds, their play time, has been removed from what you send.

customerConsented is the gate

customerConsented is a Boolean, and it is the field that decides whether you send anything at all. It records whether the customer agreed to let you share consumption data with Apple. Apple's guidance is direct: if the customer did not consent, do not send the consumption information. So this is not a field you flip to true to strengthen your case. It reflects a real yes-or-no you must already hold, and a false here means the rest of the payload should not be sent.

deliveryStatus is the field that moves refunds

deliveryStatus is a string enum, and it is the strongest lever you have. It tells Apple whether your app actually delivered a working in-app purchase. One value says yes. The other four say no, each for a different reason, and each one tells Apple the customer has a legitimate grievance.

sampleContentProvided answers a fairness question

sampleContentProvided is a Boolean. It records whether you gave the customer a free sample, a trial, or clear information about what the purchase does before they bought it. A true here is a small fairness signal: the customer had a chance to know what they were buying. It does not decide anything on its own, but it is one of only three required fields, so Apple clearly wants it in every response.

consumptionPercentage is a number now, not a status

This is the field that changed the most. The old payload had consumptionStatus, a four-step enum: UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED. The new payload replaces it with consumptionPercentage, an integer measured in milliunits. 100,000 milliunits means the item was fully consumed, so 50,000 is half and 0 is untouched. A precise number beats a four-way bucket, because it lets you say a customer burned through 90 percent of a credit pack rather than rounding down to partially consumed.

One caveat that trips people up. For auto-renewable subscriptions Apple works out consumption itself from elapsed time, so consumptionPercentage is meant for consumable and non-renewing purchases. Send it where it applies, and let Apple derive it where it does not.

refundPreference states a preference, not a verdict

refundPreference is an optional string, and it is where you tell Apple what outcome you would prefer. It also changed shape. The old field was a number with values like prefer-grant, prefer-decline, and no-preference. The new one is a named string with three values.

What Apple dropped, and why it matters

The old ConsumptionRequest had twelve fields. Seven of them are gone from what you send. accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform, and appAccountToken were the account-profiling half of the payload, the fields that asked you to bucket a customer by how long they had an account, how much they had spent, how much they had been refunded, and how long they had used the app.

Apple cut them for a reason worth noting. Those fields asked developers to hand over a profile of the customer, and most developers either left them undeclared or guessed. The five that remain are about the purchase and the delivery, facts you can actually verify from your own systems. The shift is from who the customer is to what happened with this specific purchase.

The endpoint and the clock

You send the payload with an HTTP PUT to the Send Consumption Information endpoint, keyed by the transaction id of the purchase under dispute: PUT /inApps/v1/transactions/consumption/{transactionId}. A success returns 202 Accepted, and the response body is empty. That empty reply is expected, not a bug. It confirms Apple queued your data, and it tells you nothing about the eventual outcome, which arrives later as a REFUND or REFUND_DECLINED notification.

The clock is the part you cannot stretch. Apple gives you 12 hours from the CONSUMPTION_REQUEST to respond. Only your first response is used, so the first payload has to be the complete and correct one. Apple can send the CONSUMPTION_REQUEST more than once for the same purchase, but the deadline on each is fixed, and a manual review rarely fits inside 12 hours across time zones and weekends.

What a mishandled field costs you

The money left the building before the refund did

A consumable refund is not a clean reversal. By the time a customer asks for their money back on a pack of credits or a batch of AI generations, you already spent to deliver it: GPU inference on every request, third-party model API calls billed per token, storage for whatever you produced, and any creator or partner payout tied to that usage. The store price comes back to the customer. Your delivery cost does not come back to you. So a refund you could have contested is not a break-even event, it is a net loss of everything you paid to serve the account.

The five fields are how you avoid paying twice

deliveryStatus set to DELIVERED and a high consumptionPercentage are the two facts that tell Apple the customer received and used the product. They are your evidence that the compute, the API calls, and the storage all did their job. Leave the payload unsent and Apple never hears that. It decides from the customer's claim, the refund is likelier to go through, and you eat both the reversed revenue and the delivery cost behind it.

Chargebacks are the worse door, and silence points to it

A customer who cannot get satisfaction through Apple's refund flow can still dispute the charge with their bank. A card chargeback is final, it carries a flat dispute fee, and it takes the decision out of Apple's hands and yours. Answering the CONSUMPTION_REQUEST well keeps the dispute inside Apple's system, where you have a say. Ignoring it pushes borderline cases toward the one channel where you have none.

How RefundHalt handles it

The five fields look simple until you have to fill them correctly, inside 12 hours, on every CONSUMPTION_REQUEST, keyed to the right transaction. RefundHalt catches the notification, reads your own delivery and usage records for that purchase, and sends the payload automatically before the window closes. deliveryStatus reflects what your logs actually show, consumptionPercentage comes from real usage rather than a guess, and refundPreference follows the policy you set once. You get the contestable refund reviewed with evidence, not a missed deadline and a decision made without you.