Back to blog
App Store July 28, 2026 · 8 min read

App Store Refunds for Developers: The Complete Guide

RefundShield Team
App Store Refunds for Developers: The Complete Guide

Every mobile developer loses revenue to refunds they never had a chance to answer. A customer buys an in-app product or subscription, uses it, requests a refund, and, because the developer never responds, the App Store approves it. The customer keeps the content, and the developer loses the money.

This guide explains how App Store refund requests actually work, why the default outcome favors the customer, and how developers can respond in time with the tools Apple provides.

How an App Store refund request works

When a customer requests a refund on the App Store, Apple reviews the request against its own criteria. Apple can approve it immediately, or, for certain purchases, especially consumables and subscriptions, it can ask the developer for more information first.

That request for information arrives through App Store Server Notifications V2 as a CONSUMPTION_REQUEST notification. Apple is effectively saying: "this customer wants their money back; tell us what you know about how the content was used before we decide."

If you don't answer, Apple proceeds with its default decision. In practice, that means the request is approved by default and the revenue is lost.

What Apple asks developers to send back

Apple's Consumption API lets developers submit information about the customer and the purchase: whether the content was delivered, whether it was consumed, account age and tenure, login history, and related signals. Apple uses this data to judge whether the refund request is legitimate or abusive.

The response is sent through the App Store Server API, is tied to the original transaction, and must be delivered within Apple's response window. This is where many manual implementations stall: mapping transaction data, signing requests, and responding reliably 24/7 is real engineering work.

Why refund abuse is common on the App Store

The App Store's refund flow is intentionally customer-friendly. That's good for users and bad for developers, because the same flow is easy to exploit:

  • Buy, use, refund: purchase a consumable, spend it all, then request a refund.
  • Subscription hopping: use a premium subscription, cancel via refund, and repeat on another account.
  • Friendly fraud: claim "my kid did it" or "I didn't buy this" even when the content was clearly used.

Without consumption data, Apple has no way to tell these apart from genuine mistakes. With it, patterns like "purchased five minutes ago and already fully consumed" become obvious.

What you need to respond to a refund request

To respond to a CONSUMPTION_REQUEST, you need three things in place inside App Store Connect:

  • An API key with App Store Connect access, used to authenticate requests to the App Store Server API.
  • A Server Notifications URL configured for your app, so Apple knows where to send events like CONSUMPTION_REQUEST.

Apple documents the full notification format in the App Store Server Notifications reference. Every notification is a signed JSON Web Signature (JWS), so you can verify it came from Apple before acting on it.

How to build a fair refund response

A good response policy is not "refuse everything". It's a consistent set of rules based on evidence:

  • Act fast: the response window is short and notifications arrive at any hour.
  • Use real signals: time since purchase, consumption state, renewal history, and account history.
  • Stay consistent: the same evidence should produce the same outcome, including partial refunds where Apple supports them.
  • Keep a record: log every request and outcome so you can review and adjust your policy.

You can implement this yourself, or use a service like RefundShield that handles the notification pipeline and API responses for you while you define the policy. The full setup is covered step by step in the docs:

One compliance note: Apple requires valid consent from the customer before you share consumption data, and puts the responsibility on you as the developer. Make sure your consent flow and privacy disclosures cover this: see the FAQ for details.

The App Store gives developers a real way to defend revenue, but only if you respond with the right data inside the response window. Automation turns a fragile manual workflow into a consistent policy. If you also publish on Android, don't miss our guide to Google Play chargeback protection.

Ready to protect your revenue?

Connect your first app in minutes. No SDK, no code changes required.