Subscription refunds don't work like one-time refunds, and the store you're on decides how much say you get

Refunding a subscription and refunding a single in-app purchase feel like the same button. They are not. A one-time purchase is one charge you hand back. A subscription is a recurring charge with a live entitlement attached, so subscription refunds have to answer two questions a one-time refund never asks: how much of the current period do you return, and does the subscription keep running. The App Store and Google Play answer those two questions in opposite ways, and the gap decides how much control you have and how much money leaves your account.

Here is the short map. On the App Store, Apple owns the decision and you find out after the fact. On Google Play, you hold the controls and choose full or prorated yourself. This walks through both stores, the exact fields and notifications each one uses, which order you touch when a subscription has billed many times, and what a subscription refund actually costs once you count the compute you already spent.

How subscription refunds differ from one-time refunds

Both stores treat a refund as reversing a specific order. For a one-time purchase there is only one order, so there is nothing to choose. A subscription is a chain of orders, one per billing period, with an entitlement that is either active or not. That structure is why a subscription refund carries choices a one-time refund does not.

The unit that reverses is a billing period

When you refund a subscription, you are not returning a lifetime of payments. You are acting on one order in the chain, usually the latest one, which is a single billing period. A full refund returns that whole period. A prorated refund returns only the part of the period the customer has not used yet. Either way the sale you reverse is one period's price, not the customer's entire history with the app.

Who decides is the real difference

The sharper split is authority. On the App Store, Apple decides whether a subscription refund happens at all, and you supply context at most. On Google Play, you decide, and the API does exactly what you tell it. Same outcome for the customer, a completely different seat for the developer, and it changes what you build to handle each one.

How the App Store handles a subscription refund

On Apple's side you are a spectator with a small microphone. The customer talks to Apple, Apple makes the call, and your server reads the result.

The customer asks Apple, and Apple rules

An App Store customer requests a subscription refund at reportaproblem.apple.com, not from you. Apple reviews the request against its own signals and decides. You do not approve it, and there is no Apple console button that lets you issue a subscription refund the way Google Play does. Apple has up to 90 days from the purchase to accept a request for review, and once it rules, the decision is Apple's.

What your server sees when the refund lands

You learn the outcome through App Store Server Notifications V2. A granted refund arrives as a REFUND notification, and the transaction now carries a revocationDate marking when access should end. The subscription's autoRenewStatus is set to false, so it stops renewing and the customer loses the entitlement. If Apple denies the request you get REFUND_DECLINED, and if Apple later undoes a refund it already granted you get REFUND_REVERSED and the subscription comes back. Your job is to read these and flip access, not to cast a vote.

Apple measures a subscription by time, not by your metrics

For a consumable, you can tell Apple how much was used through consumption data. For an auto-renewable subscription, Apple computes consumption from elapsed time on its own. Apple's own example is a customer six months into an annual subscription, who has consumed about 50 percent of it. So your usage metrics do not set the number for a subscription. The one lever you can pull is refundPreference, and for a subscription the relevant value is GRANT_PRORATED, which says you would prefer Apple return only the unused portion. It is a preference, not a decision. Apple still rules.

How Google Play handles a subscription refund

Google Play puts the decision in your hands. There is a Play Console screen and a set of API methods that let you refund a subscription directly, choose how much, and decide whether access ends. This is the opposite posture from Apple, and it comes with choices you have to get right.

Full or prorated, and it is your call

The current way to refund and revoke a subscription is purchases.subscriptionsv2.revoke, called with a revocationContext. Pass fullRefund and Google Play terminates the subscription and returns the full amount of the current billing period. Pass proratedRefund and Google Play terminates the subscription and returns only the remaining, unused entitlement time. The older method could only do full refunds, which is the reason to use the newer one. A prorated revoke is a two-line body, a revocationContext wrapping proratedRefund, and you swap in fullRefund for the whole period. Either revoke triggers a SUBSCRIPTION_REVOKED real-time developer notification, which is your signal to cut off access.

Which order you refund changes what happens

Google Play also lets you refund an order without revoking, through orders.refund, and here a subtle rule bites. If you refund the most recent order in a subscription, the order is refunded, the subscription is removed immediately, and future recurrences are canceled. If you refund an older order in the chain, that order is refunded but the subscription stays active. On orders.refund the revoke parameter only revokes when the order is the latest one, so to end access on an active subscription you use purchases.subscriptionsv2.revoke instead.

The limits that trip developers up

A few hard edges catch people, and none of them are in the happy path.

• Orders older than three years cannot be refunded at all.
• Partial refunds work only on orders placed after March 2018, and never on paid app purchases.
• You can stack multiple partial refunds on one order, but not up to or beyond the order total.
• A refund cannot be reversed once it is issued.

Google Play usually returns a refund decision within a day, though it can take up to four. Plan for that lag when a refund needs to reflect in your own access controls.

What a subscription refund actually costs you

The refunded charge is never the whole bill. The moment a subscription order was delivered, you had already spent real money on it: compute, model API calls, storage, and any payouts tied to that period. A refund returns the sale. It does not return what you spent to serve it. On a subscription, the shape of the loss depends on which refund you issue.

Full versus prorated is a money decision

A full refund on Google Play hands back the entire current period, so you lose the whole period's revenue while keeping every cost you already incurred that period. A prorated refund hands back only the unused slice, so you keep the revenue for the part the customer actually had. If a customer is 60 percent through a monthly period on a 10 dollar plan, a full refund costs you the full 10 dollars, and a prorated refund costs you about 4 dollars, the unused 40 percent. Apple applies the same elapsed-time logic on its side when it sizes a subscription refund.

The costs that never come back

Whichever refund you issue, the downstream costs of that period are gone. A model API call you paid for, a video you rendered, storage you provisioned, a creator payout you already sent, none of that reverses when the subscription refund clears. Size the refund on what the customer actually used, never on how long ago they subscribed, because elapsed time is not a cost and neither store treats it as one. And after August 3, 2026, if a Google Play subscription charge ends in a bank chargeback rather than a refund you issue, you also absorb the bank's chargeback fee, which a refund you grant first avoids.

How to handle subscription refunds without a person watching

None of this should wait on someone reading a dashboard. The notifications arrive at any hour, and access should flip the moment a refund lands, not the next morning.

Read the outcome and revoke access on both stores

On the App Store, listen for REFUND, REFUND_DECLINED, and REFUND_REVERSED, and use the revocationDate and autoRenewStatus to end or restore access automatically. On Google Play, listen for SUBSCRIPTION_REVOKED and voided purchase signals and do the same. This is the plumbing RefundHalt runs for you: notification in, account matched, access flipped, no person in the loop.

Keep the evidence ready before the dispute

The narrow windows that do ask for your input, Apple's 12-hour CONSUMPTION_REQUEST on consumables and Google Play's 24-hour chargeback review, only help if the evidence already exists. Attach an account identifier to every purchase, an appAccountToken UUID on Apple and a hashed setObfuscatedAccountId of 64 characters or fewer on Google Play, and log what each paid period delivered. Then when a token arrives, the case is already built, and answering inside the window is a machine's job, not a scramble.