How to Handle App Store Refund Requests (Including Consumption Data)

App Store refunds are decided by Apple, not by your app. A developer can help a customer understand the process, resolve a product problem, and—when Apple requests it—send consumption information that may inform Apple’s decision. The time-sensitive piece is Apple’s CONSUMPTION_REQUEST notification: Apple asks developers to respond within 12 hours, and customer consent is required before sharing the data.

Those jobs belong in separate workflows. A refund request is not a support ticket you can approve or deny from your dashboard. A consumption response is not an appeal to keep a customer at all costs. And a proactive conversation about a broken feature is not a substitute for explaining how to ask Apple for a refund. Keeping those boundaries clear makes the experience more trustworthy and the implementation easier to audit.

How the App Store refund process works

Customers can request a refund through Apple’s purchase and subscription interfaces. Apps may also present Apple’s native refund request sheet using StoreKit’s beginRefundRequest API where supported. The sheet lets the customer submit the request to Apple without leaving the app experience. Apple reviews the request and decides whether to approve it; Apple says review can take up to 48 hours.

From the developer side, the important question is what happens to the transaction. App Store Server Notifications and the App Store Server API can tell you about refund-related changes and transaction status. Reconcile these against your entitlement records. Do not remove access merely because someone opened the refund sheet; wait for the relevant transaction or revocation state. Conversely, do not continue premium access indefinitely after a verified revocation unless your own policy intentionally grants it.

Support agents should avoid promising an outcome. A useful reply can show the customer where to submit or track a request, explain that Apple handles App Store billing decisions, and help with the underlying issue. If the person bought through another channel, route them to that channel’s policy instead of giving App Store instructions that do not apply.

What is a consumption request?

Apple may send a CONSUMPTION_REQUEST App Store Server Notification when a customer requests a refund for an in-app purchase. It asks the developer for information about how the purchase was used. Apple’s Send Consumption Information endpoint is the current App Store Server API route for that response. Apple can use the information as one input in its review, but it does not hand the decision to the developer.

The 12-hour window starts with the notification. That means your receiving endpoint, queue, consent check, and submission path must work even outside business hours. A manual support queue that is read the next morning may already be too slow. Build retry and alerting around the event; use the notification identifier or another stable key so duplicate deliveries do not trigger inconsistent responses.

Apple requires customer consent before you send consumption data. Treat that as a real product requirement, not a checkbox to add after launch. Document what information you may share, let the user choose, and store a consent record tied to the scope and time of the response. If consent is absent, do not send consumption information. That may mean Apple decides with less data; it does not remove the consent requirement.

What information should you prepare?

Use Apple’s current API fields and definitions as the contract. The response can include information about usage or consumption, delivery, and the customer’s account context, depending on the product and what your systems actually know. Never infer consumption from a login alone. Opening the app does not prove a course was watched, a credit was spent, or a feature worked. Likewise, a server error should not be recorded as successful delivery.

Map each field to a source of truth before implementation. Record the original transaction identifier, relevant transaction identifier, product, purchase time, entitlement status, and the usage events you can substantiate. Keep an audit trail of what was sent and why, but minimize retained personal data. The goal is an accurate account, not a dossier. Apple’s API evolves, so pin implementation decisions to its current documentation rather than copying an old blog post or a deprecated endpoint.

A practical developer workflow

1. Receive and verify. Accept App Store Server Notifications V2 on your backend, verify the signed payload, and persist the notification idempotently.
2. Reconcile the purchase. Use App Store Server API status and transaction history to confirm the transaction and current entitlement before changing your own records.
3. Check consent. Determine whether you have informed customer consent for the specific consumption data. If not, do not submit it.
4. Assemble evidence. Pull only usage and delivery facts supported by your logs. Translate them to Apple’s current Send Consumption Information schema.
5. Submit within 12 hours. Send the response via the current API, monitor failures, and alert before the deadline. Store request and response metadata for audit.
6. Watch the outcome. Process refund or revocation updates, adjust entitlement consistently, and tell the customer what your app can confirm without claiming to speak for Apple.

The backend should make this flow resilient to duplicate notifications, out-of-order updates, temporary App Store API failures, and a user who contacts support while the review is pending. A state machine helps: requested, awaiting consent, data submitted, Apple decision observed, entitlement reconciled. Those are operational states, not extra claims about Apple’s internal review.

What should support say to the customer?

Start with the person’s actual problem. If the app failed to deliver a feature, acknowledge that and give a concrete remedy. If the issue is uncertainty about billing, explain purchase date, plan, renewal setting, and access end date based on verified account data. Then explain that Apple controls App Store refunds and link the customer to the right Apple path. Do not bury the refund path behind a retention offer.

A reply such as “I can help troubleshoot this, and you can also request a refund through Apple” preserves choice. A reply that promises “we have refunded you” when no Apple decision exists creates confusion. If your team can grant an app-specific courtesy credit or extend service, distinguish that from an App Store refund. Each action has different accounting and entitlement effects.

Localization matters here. Refund requests are emotionally charged and often time-sensitive. Short, plain language about what happens next is more valuable than policy jargon. If an AI agent drafts a response, it should be constrained to the verified subscription record and permitted actions, with escalation for ambiguous purchase states. Unsupported confidence is worse than a quick handoff.

Reactive replies versus proactive problem solving

By the time a customer submits a refund request, something has already gone wrong or the purchase no longer fits. The best opportunity may have been earlier: a failed onboarding step, repeated crash, unanswered support question, or auto-renew-off event. A subscription-aware support system can identify those moments and offer help before a refund is requested. This is service, not a way to suppress a refund option.

For example, a user may disable renewal after discovering that data import failed. An early troubleshooting message can resolve the import issue while the paid subscription remains active. If that person later asks for a refund anyway, the app should still support the Apple process and follow the consent rules for consumption data. The two workflows should be able to coexist without one manipulating the other.

Track separate metrics: refund request volume, refunds Apple approves, product issue resolution, verified subscription renewals, and customer satisfaction. A lower refund count alone does not prove better experience; it can also reflect a harder-to-find refund path. If you evaluate proactive interventions, use a holdout group and confirmed transaction outcomes rather than counting every contacted user as “saved.”

Common mistakes to avoid

• Using the old API by default. Apple’s current Send Consumption Information endpoint is in App Store Server API; check migration guidance before copying legacy examples.
• Sending data without consent. The deadline does not override the customer-consent requirement.
• Confusing use with value. Opening a screen is not proof that a purchased benefit was delivered successfully.
• Acting on a request as if it were an approved refund. Reconcile the actual transaction state before changing access.
• Overstating control. Developers provide information; Apple decides App Store refund eligibility.

Frequently asked questions

Can an app developer approve an App Store refund?

No. Apple reviews and decides App Store refund requests. Developers can provide eligible consumption information when Apple asks.

How long do developers have to send consumption information?

Apple asks developers to respond within 12 hours of a CONSUMPTION_REQUEST notification, and to obtain the customer’s consent before sending consumption data.

Building a calmer support path around subscriptions? Review keepwell pricing or request early access.