App Store refunds: what the developer actually sees

On the App Store, Apple grants or denies a refund, never the developer. The customer files the request on Apple's site or from inside your app. If you've set up Apple's server notifications, you get a CONSUMPTION_REQUEST notification when the request comes in, then REFUND or REFUND_DECLINED once Apple decides. In between, you have 12 hours to send consumption data and your preference, as long as the customer has consented.

A granted refund removes the purchase from the customer's active entitlements and shows up as a negative in your sales reports. This guide walks through each step, what you can send to Apple, and what you're allowed to do about abusive requests. The rules come from Apple's pages, reviewed on November 3, 2026. The real case comes from an alert I set up on my apps in October.

Who decides an App Store refund?

Apple, and only Apple. Apple's support page describes the customer's path: they sign in to reportaproblem.apple.com, choose "Request a refund", pick a reason, then the purchase. Apple tells them to wait 24 to 48 hours for an answer.

The customer can also request a refund from your app. StoreKit offers a refund request sheet for this, available since iOS 15. Apple recommends calling it from account settings or a help menu. It shows the purchase and a list of reasons, and Apple takes up to 48 hours to decide.

Either way, you have nothing to approve. You can only provide information and a preference, which are just some of the criteria in Apple's decision.

What each side sees, step by step

Step	Customer side	Developer side
Request	Apple's form or the in-app sheet	CONSUMPTION_REQUEST notification
Within 12 hours	Waiting	You can send consumption data
Within 48 hours	Apple's answer	REFUND or REFUND_DECLINED notification
After approval	Money returned to their payment method	Purchase removed from active entitlements, negative units
After a dispute	Refund reversed by Apple	REFUND_REVERSED notification, access to restore

App Store Connect only shows you refunds that have already been granted, in Sales and Trends. The request itself only reaches you through server notifications. Without them, you find out about the refund after the fact.

Server notifications for a refund

App Store Server Notifications V2 sends five types that matter here. You receive them at the HTTPS URL you set in App Store Connect, one for production and one for sandbox.

Notification	What it means	What you do
CONSUMPTION_REQUEST	The customer is requesting a refund	Respond within 12 hours, if consented
REFUND	Apple refunded the transaction	Remove the refunded content or access
REFUND_DECLINED	Apple denied the request	Nothing, access continues
REFUND_REVERSED	Apple reverses a refund after a customer dispute	Restore what you removed
REVOKE	A purchase shared through Family Sharing is no longer available	Remove access for the family member

Your server must respond with an HTTP code between 200 and 206. According to the page on responding to notifications, Apple otherwise retries five times, at 1, 12, 24, 48 and then 72 hours after the previous attempt. In sandbox, it only sends once.

The Consumption API: what you can tell Apple

When the request comes in, you can respond with Send Consumption Information. Apple sums up the rule in one sentence: "Respond within 12 hours of receiving the CONSUMPTION_REQUEST notification." Version 2 of the API covers every product type, subscriptions included.

The fields of the request:

Field	Required	What it tells Apple
customerConsented	Yes	The customer consented to sharing their data
deliveryStatus	Yes	The purchase was delivered and works, or why it wasn't
sampleContentProvided	Yes	A trial, sample or description was offered before purchase
consumptionPercentage	No	How much was consumed, from 0 to 100,000 for 0 to 100%
refundPreference	No	Your preference: DECLINE, GRANT_FULL or GRANT_PRORATED

Two details matter. If deliveryStatus isn't DELIVERED, the consumed share must be zero. And for a prorated subscription refund, you leave out the consumed share: Apple calculates it.

Consent is the condition for everything. Apple writes: "You must obtain valid consent from the customer before sharing their personal data with Apple in the Send Consumption Information API." No consent, no response. Apple also forbids using the ad tracking prompt to collect that consent: "Don't use the AppTrackingTransparency prompt to obtain consent".

If you use RevenueCat

With RevenueCat, it's RevenueCat that receives Apple's notifications and responds to the request, through Refund Control. You pick one of four policies: prefer a full refund, prefer a decline, send consumption data only, or don't respond.

Turning on data sharing means confirming you have your customers' consent. RevenueCat says so itself: "Enabling consumption data sharing confirms that you obtained consent from your Customers." It also recommends keeping "Prefer no refund" for a targeted group, and warns you when that preference affects most of your customers.

To also get the notifications on your own server, RevenueCat offers an "Apple Server Notification Forwarding URL" field in the app settings. It's described in its page on Apple notifications. That's what I use. Setting up a subscription with RevenueCat is covered in RevenueCat and iOS in-app subscriptions.

The impact on your revenue and the subscription

On access. According to the currentEntitlements documentation, "Products that the App Store has refunded or revoked don't appear in the current entitlements". If your app checks entitlements with currentEntitlements, the refunded access disappears on its own. The transaction carries the date and reason for the removal, in revocationDate and revocationReason.

On reports. According to the sales report help page, a refund shows up with negative units and a negative customer price. For subscriptions, the page on subscription data counts full and partial refunds among events, and removes them from daily units.

On your reputation. Guideline 5.6.4 lists excessive refund requests among the signs of poor quality. A high refund rate isn't just lost money: Apple can factor it in when judging whether you follow the code of conduct.

My case: the alert I set up on my apps

On October 12, 2026, I set up an alert on my apps. RevenueCat forwards Apple's notifications to a route on devoria.fr. It verifies Apple's signature, then sends me an alert, with no amount. I wanted to see the request the moment it comes in, not just the outcome.

On October 18, the first real request came in on TradaZen, my trading simulator. An annual subscription, paid at the end of a 7-day free trial. Reason given: an accidental purchase. Three lessons:

1. The same request can arrive several times. I got the same alert three times that evening. Since then, every alert is deduplicated on the notification type and the transaction ID.
2. The decision came in less than a day. Apple declined about 22 hours after the request. The customer kept their access.
3. A decline isn't the end. The same customer filed another request two days later, on the same transaction.

You don't win an "accidental purchase" request at the end of a trial in your response to Apple. You prevent it on the paywall, before the first payment.

Reducing abusive requests without breaking the rules

What's allowed:

• Respond to every request with accurate data, when the customer has consented.
• Express a targeted preference, for example a decline for a purchase that's already been consumed, rather than declining for everyone.
• Link every REFUND to a customer account. Apple's page on refund notifications recommends this to spot repeat refunds.
• Say clearly what people are buying before they buy. Guideline 3.1.2(c) requires you to describe what the user gets for the price before asking them to subscribe.

What's forbidden:

• Sending false data to get a request declined, or responding without consent.
• Collecting consent through the ad tracking prompt, which Apple rules out explicitly.
• Tricking people into buying. Guideline 5.6 forbids pushing customers into unwanted purchases or charging for something that isn't delivered.
• Pressuring a customer who asks for a refund. The same rule requires respectful customer service, with no intimidation.

The best lever is still upstream: a paywall that states the price, the date of the first payment and how to cancel. The mistakes to avoid are in paywall mistakes, and the free trial rules in free trials on the App Store.

Testing before production

According to the page on testing refund requests, sandbox and Xcode's StoreKit testing support refund requests. In sandbox, any reason triggers an automatic approval. To simulate a decline, choose "Other" and type DECLINE. For a prorated refund, type GRANT_PRORATED. In sandbox, your consumption response must go out within five minutes.

A subscription that gets refunded less

The iOS & Android Kit starts from the code of my apps, with onboarding, paywall and subscriptions already built, and follows four steps all the way to the App Store, at your own pace. The full setup is detailed on the iOS in-app subscription page, and Apple's subscription rules in guideline 3.1.2.

Before launching your paywall, take your free diagnostic: it tells you what's really blocking your project and sends you my Apple anti-rejection checklist.

Frequently asked questions

Can the developer refuse an App Store refund?

No. Apple decides alone. You can send consumption data and a preference, DECLINE for example, which are among several criteria. Apple has the final say.

Is the developer notified of a refund request?

Yes, if they've set up App Store Server Notifications V2. Apple sends CONSUMPTION_REQUEST when the request is made, then REFUND or REFUND_DECLINED once it decides. Without notifications, you only see granted refunds, in your reports.

How long does Apple take to process a refund request?

Apple tells the customer 24 to 48 hours. The StoreKit documentation says 48 hours at most. On your side, you have 12 hours to send consumption data.

What happens to access after a refund?

The refunded purchase leaves the customer's active entitlements: StoreKit 2 no longer returns it in currentEntitlements. If Apple later reverses the refund, you get REFUND_REVERSED and must restore access.

Do I need the customer's consent to respond to Apple?

Yes. Apple requires valid consent before any data sharing through the Consumption API. Without it, you don't respond to the notification. The ad tracking prompt can't be used to collect it.

Do refunds count against my app?

They can. Guideline 5.6.4 lists excessive refund requests among the signs of poor quality, which Apple can factor in when judging compliance with the code of conduct.