Understanding what a CONSUMPTION_REQUEST is takes about a paragraph. Building something that handles one reliably takes rather more, and the parts that catch people out are not the parts you'd expect.
Signature verification is one. Consent is another, because it has to exist before the notification arrives. And the retry schedule interacts with the response window in a way that surprises most teams the first time they look at it closely.
This walks through the handler from the moment the request hits your endpoint to the entitlement update that closes it out.
Key Takeaways
• CONSUMPTION_REQUEST asks for information during a refund review. Apple still makes the decision.
• Verify the signed payload before acting on it. Never trust an unverified notification.
• Consent must already exist in your app. You can't collect it after the request arrives.
• Apple asks for a response within 12 hours of the notification.
• Apple retries failed deliveries on a fixed schedule, and the second retry lands after the response window has closed.
• Track the outcome and update entitlement afterwards. Responding isn't the last step.
What is an Apple CONSUMPTION_REQUEST notification?
An Apple CONSUMPTION_REQUEST notification is an App Store Server Notification telling your server that a customer has requested a refund and that Apple is inviting you to send consumption information about that purchase. It arrives at the notification URL you configured, carries the relevant transaction, and gives you a limited time to reply.
It is not a refund and not a decision. Apple is partway through a review and collecting context. Your role is to supply accurate information about what happened with the purchase; Apple's role is to decide.
Why does Apple send a CONSUMPTION_REQUEST?
Because Apple can't see inside your app. It knows the transaction, the account, and the purchase history. It doesn't know whether the content was delivered, whether it worked, or how much of it the customer used.
Consumption information fills that gap. It's one of several factors Apple weighs, not the deciding one, and a high consumption figure is not a refusal switch. Treat it as context you're contributing rather than a case you're arguing.
What should developers do when they receive a CONSUMPTION_REQUEST?
Validate the notification, identify the transaction and customer, confirm consent, assemble accurate consumption data, send it inside Apple's window, then record what happened.
Ten steps in practice:
1. Receive the notification at your configured server endpoint and persist it immediately.
2. Verify the signed payload before treating any field as real.
3. Read the notification type and route it. A consumption request is not a refund outcome.
4. Identify the related transaction from the decoded payload.
5. Resolve the transaction to a customer account in your own system.
6. Check whether that customer's consent allows a response.
7. Gather delivery and usage data from your records, not from estimates.
8. Prepare the response and check it against the field validation rules.
9. Submit to Apple's consumption endpoint and capture the result.
10. Track the refund outcome that follows, then update entitlement and records.
How should developers validate a CONSUMPTION_REQUEST?
Verify the signature before you trust the contents. Notifications arrive as signed JWS payloads, documented in the Apple App Store Server Notifications documentation, and your handler should check them against Apple's certificate chain and confirm the bundle ID matches your app.
The reason is straightforward. Your notification URL is a public endpoint. An implementation that parses whatever arrives and acts on it is one that anyone who finds the URL can drive.
Three handler details matter as much as the signature:
Respond with the right status code. Apple treats HTTP 200 through 206 as success. A 40x or 50x tells the App Store to retry. Return success once you've stored the notification, not once you've finished processing it — those are different moments, and coupling them means a slow downstream job can trigger unnecessary retries.
Handle duplicates. Retries mean the same notification can arrive more than once, and each carries a notification UUID you can use to deduplicate. Acknowledge repeats rather than erroring on them; a failure response just restarts the retry cycle.
Remember the sandbox behaves differently. Retries apply in production. In the sandbox the App Store attempts delivery once, so a handler that looks fine in testing may still be losing events in production, and the reverse is also true.
What should developers check before responding?
Four things, in this order.
Consent first, because it's the one that can stop everything. Apple requires valid customer consent before you share their data, obtaining it is your responsibility rather than Apple's, and the notification itself carries no consent flag. Apple also states plainly that the App Tracking Transparency prompt is not the mechanism here. If consent isn't there, the guidance is not to respond.
Transaction identity second. You need to know which purchase this is and which account sits behind it. That mapping is what appAccountToken and Apple refund defense is about without a stable link from transaction to account, you're inferring under a deadline.
Product type third, since it affects which options are available to you. And finally, whether you actually hold usable data. If your systems can't say whether the content was delivered, that's worth knowing before you start assembling a response.
What consumption information can developers send to Apple?
Apple's current Send Consumption Information documentation defines five fields. Three are required and two optional.
Field | Required | In plain terms |
customerConsented | Yes | Did the customer agree to this? Must be true, or the request is rejected. |
deliveryStatus | Yes | Did your app actually deliver a working purchase, and if not, why not? |
sampleContentProvided | Yes | Could the customer try it before buying? |
consumptionPercentage | No | How much did they use? In milliunits — half is 50000, not 50. |
refundPreference | No | What you'd prefer: grant in full, decline, or prorate. |
Two rules trip people up. If delivery status is anything other than delivered, consumption percentage must be zero. And the refund preference is a preference, not an instruction; Apple can and does decide differently.
Worth checking which endpoint you're on. Apple also documents Apple's ConsumptionRequestV1 documentation, the earlier version with a twelve-field body that most third-party articles still describe. Apple's note there points standard In-App Purchases to the current endpoint and scopes V1 to Advanced Commerce API purchases. If your integration predates the change, that's the first thing to look at.
How long do developers have to respond to CONSUMPTION_REQUEST?
Apple's current documentation asks for a response within 12 hours of the notification.
Here's the part that deserves attention. Apple retries failed deliveries five times, at 1, 12, 24, 48, and 72 hours after the previous attempt. Line that up against a 12-hour window and the arithmetic is uncomfortable: if your endpoint misses the first delivery, the first retry arrives an hour later and you're fine. If it misses that one too, the next attempt lands around thirteen hours in after the window has already closed.
So endpoint reliability isn't a general hygiene concern here. For consumption requests specifically, roughly one hour of downtime is recoverable and half a day is not.
Apple doesn't state that missing the window means the refund is automatically approved, and it would be wrong to claim so. What it means is simply that Apple decides without information you could have supplied.
What happens after the developer responds?
Apple takes your information into its review, weighs it with everything else, and decides. The outcome arrives as a separate notification: granted, declined, or reversed if Apple later undoes a refund it approved.
Three distinct things are happening here and it helps to keep them apart. Your response is information. Apple's decision is a decision. Your system update is a state change. Only the middle one belongs to Apple, and the third doesn't happen unless you build it.
How developers handle Apple refunds after the response
Once the outcome lands, the work moves back to you.
Record the result against the transaction and the customer. Update the subscription status, since a refunded period usually ends the subscription rather than leaving it running. Revoke the entitlement on a granted refund, restore it on a reversal, and handle the prorated case where only part of a transaction is revoked.
Then reconcile the amount into the right reporting period and keep the refund in a queryable history. That history is what later tells you whether one product or price point is producing a disproportionate share, and it's also what support needs when a customer asks what happened to their access.
What are the common mistakes when handling CONSUMPTION_REQUEST?
The ones that come up repeatedly:
• Treating the notification as a refund and revoking access immediately. Nothing has been decided yet.
• Skipping signature verification because the payload looks fine in testing.
• Discovering there's no consent flow, at the moment a response is due.
• Sending estimated consumption figures instead of real ones.
• Firing the request and never checking whether it succeeded. A failed submission looks identical to a successful one afterwards.
• Confusing a cancellation with a refund. They are different events with different effects on access.
• Handling the granted and declined outcomes but forgetting the reversal case, which locks paying customers out.
• Relying on someone noticing a notification manually, against a 12-hour clock.
Can CONSUMPTION_REQUEST handling be automated?
Yes, and almost all of it should be, because nearly every step is deterministic.
Automation covers notification monitoring and validation, transaction lookup, consent checks, consumption-data preparation, submission, response logging, outcome tracking, internal alerts, and reporting. None of that requires judgement in the moment.
What stays human is upstream: designing the consent flow in your app, and deciding what your refund preference policy should be. And automation has no influence on Apple's decision, whatever some tooling implies.
How RefundSensor helps developers handle Apple refund workflows
App Store refund management is the category, and RefundSensor covers the developer's side of it: monitoring Apple refund workflows, handling the supported response path for consumption requests, tracking refund events and outcomes, and taking the repetitive parts off people.
In practice, responses go out inside the window without anyone watching a dashboard at 3am, and refund records stay accurate as volume grows. It doesn't prevent refunds and can't influence what Apple decides. It removes the manual monitoring and the missed steps.
Where These Rules Are Documented
Send Consumption Information — the current endpoint. Consent requirement, the 12-hour window, and the five request fields. Build against this for standard In-App Purchases.
Send Consumption Information V1 — the earlier endpoint with the twelve-field body. Useful for identifying which version your integration calls, and for Advanced Commerce API purchases.
App Store Server Notifications — notification delivery, the signed payload format, the expected response codes, and the retry schedule.
If this is still handled by hand
A 12-hour window, a retry schedule that can outlast it, and notifications arriving overnight make a poor fit for manual monitoring. RefundSensor handles the developer side of these workflows validating notifications, preparing and submitting responses inside the window, and tracking outcomes through to your entitlement records.
Frequently asked questions
An App Store Server Notification telling your server that a customer requested a refund and that Apple is inviting you to send consumption information about the purchase. It isn't a refund notification or a decision. Apple decides separately, treating your response as one input among several factors.
Because Apple can't see what happened inside your app. It knows the transaction and the account history, but not whether content was delivered, whether it worked, or how much the customer used. That context sits in your systems, so Apple asks for it during the review.
Verify the signed notification, identify the transaction and the customer behind it, confirm consent exists, gather real delivery and usage data from your records, then submit to Apple's consumption endpoint inside the window. Capture the response result rather than assuming the call succeeded.
Five fields on the current endpoint. Three required: customer consent, delivery status, and whether sample content was provided. Two optional: consumption percentage and your refund preference. The earlier V1 endpoint asked for twelve fields, which is why older guidance describes a longer list.
Apple's current documentation describes the notification in connection with refund requests across all product types, broader than older docs suggested. Apple doesn't publish a guarantee for every case, so build a handler that responds when a request arrives rather than logic that assumes one always will.
Apple asks for a response within 12 hours of the notification. Worth noting that Apple's retry schedule for failed deliveries runs at 1, 12, 24, 48, and 72 hours, so an endpoint that stays down past the first retry may only receive the notification after the window has closed.
Apple weighs it alongside other factors and decides. The outcome arrives as a separate notification indicating the refund was granted, declined, or later reversed. From there it's your job to update entitlement, subscription status, and revenue records to match the new transaction state.
Yes. Validation, transaction lookup, consent checks, data preparation, submission, logging, and outcome tracking are all deterministic. What stays human is designing the consent flow and setting your refund preference policy. Automation has no effect on Apple's refund decision.
