Introducing Refund Saver: Automated App Store Refund Management in Magify

Set your refund policy, respond automatically to Apple's consumption requests, and track the outcome from portfolio level down to individual transactions.

The refund decision happens before the refund

App Store refunds create an unusual product problem. Apple makes the final decision, but developers can provide consumption data and a preferred outcome before that decision is made. Apple is explicit that a developer's refund preference is [one of several factors informing the outcome]{.s1} rather than an instruction to the store — but it is a factor, and it is only present if someone submits it.

The catch is operational. After a CONSUMPTION_REQUEST arrives through App Store Server Notifications V2, the developer has [12 hours to respond]{.s1}.

The problem is operational, not conceptual

Nothing about that workflow is conceptually hard. All of it is infrastructure.

Responding reliably within the window means running verified notification intake, resolving the incoming request to a specific transaction and user, holding consent state, assembling validated usage signals for that transaction, submitting the response, deduplicating retried notifications so the same case isn't answered twice, and then joining Apple's eventual verdict back to the original request so anyone can tell what happened. Each piece is straightforward. Together they are a backend service with a hard latency commitment, competing for roadmap space against product work with clearer ownership.

Refund Saver turns that workflow into a configurable policy.

The policy: four refund preferences

Refund Saver applies a stated preference to eligible refund requests. The four options differ in mechanics, and the right one depends on your monetization model and refund strategy rather than on a universal best practice.

Always decline is the default. Every eligible request receives a decline recommendation alongside the consumption data that consent permits.

Decline first request, grant the next ones introduces state into the policy. The first eligible request in a given user and product context receives a decline recommendation; subsequent requests in that context receive a grant recommendation. Unlike a static preference, the recommendation depends on refund history rather than treating every request identically — which means the system has to maintain that history, and that the same user can receive different outcomes over time.

Always refund sends a grant recommendation on every eligible request.

No preference sends eligible consumption data without expressing a preferred outcome. This suits teams that want Apple to evaluate the available usage evidence without an explicit recommendation attached. It can also serve as an observational baseline for monitoring outcomes, though it should not be treated as a causal control group — switching to it changes the recommendation and leaves the evidence in place, so the two effects are not separable.

What happens when a refund request arrives

Once the policy is set, each eligible case runs the same sequence:

Apple sends a CONSUMPTION_REQUEST .

Refund Saver resolves the transaction and the associated user.

It determines the applicable refund preference.

It checks consent status.

It assembles the eligible consumption data.

It responds to Apple within the required window.

It records the recommendation and, later, the store outcome that comes back.

Step seven is the one that changes how refunds get managed rather than just how they get handled. A refund response without a recorded outcome is an action; a refund response joined to its verdict is a measurement.

Built on validated transaction data

Refund Saver runs on top of Magify's transaction validation layer, so the response is assembled from validated purchase and usage data rather than from an isolated refund webhook. That is the reason the consumption data has any evidentiary weight: it describes verified transactions and verified usage, not an application's self-report.

The dependency runs in one direction. If validation becomes unavailable, Refund Saver is disabled automatically rather than continuing to respond without the transaction context it relies on.

Consent determines how much of the workflow can run

Apple requires valid user consent before consumption data is shared, and recommends obtaining it on an opt-in basis. Refund Saver tracks consent status and lets teams define how an unknown status should be treated by the system. That setting governs system behavior; it does not replace the developer's responsibility to obtain valid consent.

When consent is unavailable, the consumption data supporting a request cannot be sent, and the interface says so directly rather than reporting a clean number over an incomplete base.

Consent is therefore both a compliance requirement and a coverage constraint, and the second half matters for how the reporting is read. Consent coverage sets the denominator: if consent is present for a fraction of your users, consumption data accompanies that same fraction of refund requests, and any recovery figure describes that subset rather than the full population.

From portfolio KPI to individual transaction

The reporting is built as three levels, each answering a different question.

Portfolio — which application needs investigation$1 Every connected application shows refunds requested and won-back refunds for the selected period, with the change against the previous 28 days, and negative trends are highlighted rather than left to be spotted. The screen is meant to be scanned before it is read.

Application — what changed$2 Refunds requested, won-back refunds, and won-back rate sit above a trend view filterable by product and country. Requests and their outcomes are kept on their own dates instead of being collapsed into the request date, because a request and its resolution do not necessarily occur in the same period.

Transaction — why$3 Each case is logged with its transaction identifiers, masked user reference, product and product type, the recommendation that was applied, and the store outcome once Apple returns it, updating in place as verdicts arrive.

That hierarchy is the whole point of the reporting. Won-back rate fell against last month — policy, consent coverage, product mix, or a single high-value transaction that resolved partially$4 The trend shows the shape of the change; the records show what produced it. A refund KPI without that layer produces meetings, not decisions.

What "won back" actually means

Won-back refunds cover requests that were prevented or reversed after Refund Saver shared validated usage data. It is a product metric, not a counterfactual estimate: it tells you the value associated with refund requests that ended in a favorable outcome after Refund Saver participated in the process. It does not establish that those refunds would otherwise have been granted.

Refund Saver reports observed outcomes and does not claim causal attribution. The dashboard can show how requests and outcomes changed after a policy change; it cannot show how many outcomes would have differed without it. Before crediting a movement to the policy, rule out the things that move refund volume independently — a price change, a shift in geo or product mix, a fraud wave, a store promotion, a seasonal spike, a paywall regression.

Partial outcomes deserve their own treatment. They should be interpreted by the amount actually recovered rather than counted as equivalent to a fully declined refund.

Current scope and what comes next

The current release applies one global refund preference per application. Planned Stage 1 rules add segment- and user-level overrides, with individual rules taking priority over segment rules, and segment rules over the global default. The distinction that creates is worth being precise about. A global rule gives a first-week trial user and a long-standing subscriber the same refund recommendation, even though the consumption evidence sent to Apple for the two may be very different. Overrides let the recommendation vary along with the evidence instead of holding it constant across cases that are not alike.

The point is not the toggle

Refunds are one of the few revenue events where a developer is invited to submit evidence before the outcome is decided, on a clock, through a documented interface. The reason most teams submit nothing is not strategy — it is that the workflow behind it never clears the roadmap.

Refund Saver removes that constraint. What remains is a product decision rather than an engineering one: what do you want to argue when a customer asks for their money back, and can you show your work$5