How the App Store Refund Process Really Works

Understanding the App Store Refund System

App Store refunds have historically been a black box for publishers. Apple controlled everything — from payments to refunds — and developers were left out of the loop. Refund decisions appeared later as unexplained drops in revenue.

Apple introduced refund-related server notifications in 2021, starting with consumable purchases. In 2024, this capability was extended to auto-renewable subscriptions, giving developers limited ability to participate in the refund process.

In this article, we'll explore what refunds are, how they worked before 2024, what changed, how the new system operates, and how RefundKeeper helps publishers handle it all with confidence.

What Is a Refund in the App Store?

A refund is a reversal of payment — full or partial — usually tied to a subscription or in-app purchase. It's initiated by the user and handled entirely by Apple through their portal at reportaproblem.apple.com.

Refunds are not chargebacks. Apple alone evaluates and resolves refund requests. The publisher cannot approve, deny, or contest them.

Despite this, refunds directly impact key business metrics: they reduce net revenue, distort cohort retention, and introduce noise into LTV and ROAS models — all while remaining invisible in most analytics systems.

App Store Refunds in Practice

Until 2024, the App Store refund process offered developers little to no visibility — especially for subscriptions.

Here's what typically happened:

• A user would request a refund through reportaproblem.apple.com.
• Apple reviewed the request internally, usually within 24-48 hours.
• Developers weren't notified and had no ability to provide usage data or dispute the request.
• If approved, the refund appeared retroactively in financial and transaction reports — without warning or explanation.

Evolution of Developer Visibility and Control

Before 2021

• Developers did not receive any notifications about refund requests or decisions.
• Refunds appeared retroactively in financial reports, with no context or breakdown.

In 2021

• Apple introduced the App Store Server API and Server Notifications V2.
• For consumable purchases:
• Introduced CONSUMPTION_REQUEST — sent when a user requested a refund. Developers had 12 hours to respond with usage data.
• For all purchase types (including non-consumables and non-renewing subscriptions):
• REFUND: refund approved.
• REFUND_DECLINED: refund denied.
• However, auto-renewable subscriptions were not covered by CONSUMPTION_REQUEST.

April 2024

• Apple expanded CONSUMPTION_REQUEST to include auto-renewable subscriptions.
• Added new field: consumptionRequestReason (reason selected by user for refund).
• Developers gained the ability to:
• Submit structured usage data for subscriptions.
• Express a refundPreference (e.g. suggest approval or denial).
• The final decision is still made by Apple.

How the Refund Flow Works (Today)

Here's how the modern refund process works:

1. A user requests a refund from Apple
2. If notifications are enabled, Apple sends a CONSUMPTION_REQUEST to your backend
3. Your backend submits structured usage data — including device details, in-app behavior, purchase history, and timestamps of content access.
4. Apple evaluates the response
5. A decision is made — usually within a few hours to several days
6. A REFUND notification is sent confirming the outcome.

If no response is provided within 12 hours, Apple proceeds without publisher input.

What You Need to Enable It

To use this flow, your app must:

• Switch to App Store Server Notifications (V2) in App Store Connect
• Build a secure endpoint to receive POST requests from Apple
• Track usage data that qualifies as "consumption"
• Collect user consent (customerConsented) before submitting consumption data — otherwise, Apple may ignore your response.
• Format and send the response within the 12-hour timeframe

Without this infrastructure, refunds happen entirely outside your visibility.

Why Refunds Matter More Than You Think

Not every refund is harmful — some reflect legitimate user experience issues. But when refunds go untracked or are exploited, they distort your understanding of product performance and financial health.

How Refunds Distort Product and Growth Metrics

Refunds don't just impact revenue — they ripple through your entire analytics and growth strategy:

• Analytics: Refunded users can remain in retention cohorts unless excluded, skewing product metrics and masking friction points.
• Marketing Attribution: Campaign performance is often evaluated based on early revenue. If that revenue gets refunded on Day 5 or 7, you may be scaling the wrong channels.
• Churn & Retention: Churn appears lower if refunded users are still counted as active. This can create a false sense of product-market fit.
• Forecasting & Budgeting: Refunds affect LTV and payback periods. If refund behavior isn't modeled correctly, UA budgets may overshoot and CAC recovery windows become misleading.
• Abuse Patterns: Some users exploit the system by consuming premium features — including full trial access or first-month value — and then requesting a refund. This "use-and-refund" behavior distorts metrics and creates invisible losses.

Responding to Apple with real usage data — even if the refund still goes through — brings your models closer to reality and gives your team earlier signals to act on.

Where RefundKeeper Fits In

What RefundKeeper Does

RefundKeeper helps publishers plug into the refund flow without building custom infrastructure.

Here's what RefundKeeper currently delivers:

• Automated handling of CONSUMPTION_REQUEST events
• Real-time tracking of user interactions, such as device details, in-app behavior
• Compliant payloads sent to Apple, within the 12-hour review window
• Logging and syncing of refund outcomes, with easy export into your BI tools
• Dashboards to monitor refund rates by transactions

How RefundKeeper Supports Your Workflow

RefundKeeper is built to make integration with Apple's refund flow simple and reliable. Instead of engineering custom logic and backend systems, you get an out-of-the-box setup that ensures your consumption data is delivered on time, every time.

RefundKeeper doesn't interpret or influence Apple's decisions — we provide only the facts. We collect and structure the usage data you already have and deliver it to Apple in the way they expect. The goal is not to argue, but to document: to give Apple the clearest possible picture of whether the user consumed the product. At the same time, we help your team understand refund patterns in context — not through guesswork or assumptions, but through structured logs and tracked responses. We learn from your data to improve the quality of what's submitted, ensuring your responses remain consistent, complete, and aligned with Apple's evolving expectations.

Final Thoughts

You can't stop refunds — but you can stop them from wrecking your metrics.

With Apple's refund API, developers finally have a way to participate. RefundKeeper helps you respond on time, with clarity and structure — so your business decisions reflect reality, not refund noise.