A paid app refund never reaches your server, so the app itself has to notice it

Upfront paid apps get refunded through a side door that most refund tooling never watches. When a buyer returns the app itself, not something bought inside it, Apple and Google take the money back from your payout without sending your server a single notification. Google at least uninstalls the app. On iOS, developers on Apple's own forums report that refunded buyers keep using it. If you sell a paid app, the paid app refund is the one refund you'll only ever see as a negative line in a report, unless the app checks for it on the device.

Paid app refund rules on Google Play and the App Store

Both stores treat the download purchase as its own product with its own rules. Here's what each store's documentation says.

How the Google Play two-hour return works

Google's Play Console help is plain about it: after purchasing a paid app, a user has up to two hours to return it for a full refund, and they can only return an app once. Google's consumer refund policy adds that within 48 hours a buyer may be able to get a refund depending on the purchase, that the app is uninstalled as part of the refund, and that someone who buys the same app again can't get a refund on it. After 48 hours, Google sends buyers to the developer.

How Apple refunds a paid app

On the App Store, a buyer asks Apple through reportaproblem.apple.com, picks a reason, and selects the app. Apple says to expect an update within 24 to 48 hours. You can't refund an App Store purchase yourself. Your contract sets the outer limit. Section 6.3 of Schedule 2 of the Apple Developer Program License Agreement says that if a buyer wants to cancel within ninety days of download, or the app doesn't conform to your specifications or applicable law, Apple may refund the full price, and you reimburse Apple or grant it a credit for that amount.

Why your server never hears about a paid app refund

Every refund signal both stores send is built for in-app purchases. Apple describes its notificationType as the In-App Purchase or external purchase event that triggered the notification. Its REFUND type covers a consumable, a non-consumable, an auto-renewable subscription or a non-renewing subscription. Get Refund History returns a customer's refunded in-app purchases. The app download isn't on any of those lists.

Google is the same. Real-time developer notifications cover subscriptions, one-time products and voided purchases, and the voided purchase productType is either a subscription or a one-time purchase. The Voided Purchases API says it applies to one-time in-app orders and subscriptions, and it only reaches back 30 days.

Does a paid app refund trigger a CONSUMPTION_REQUEST?

No. Apple's documentation says it sends CONSUMPTION_REQUEST when a customer asks for a refund on a consumable In-App Purchase or an auto-renewable subscription. That's one of only two refund flows across both stores that ask the developer for evidence. The other is Google Play's chargeback review, answered through orders.reviewrefund within 24 hours, and it arrives through the same in-app notification stream. Neither is documented for app downloads. A paid app refund is decided without anything you could send.

Does a refunded buyer keep using the app?

On Google Play, the policy says the app is uninstalled. On iOS, Apple's forums hold threads from developers asking exactly this. One from March 2025 reads: "When a user refunds an up-front paid app, they still have access to the app." Another, from 2022, suspects buyers of purchasing, installing, refunding and carrying on. A third, from June 2025, asks whether App Store Server Notifications V2 report app-level refunds at all. None of the three has an answer from Apple.

What a paid app refund costs you in money

The payout side is predictable. Google's Play Console help says it returns its service fee when you refund, so the deduction from your payout is your share, not the sticker price. A refund issued after Google paid you comes out of a future payout, and if your balance stays negative for at least 48 hours, Google may debit your bank account. On Apple's side, the contract says you reimburse an amount equal to the price. In practice, RevenueCat reported in 2022 that Apple deducted the post-commission figure shown as Extended Partner Share, so Apple didn't keep its cut.

The costs that don't come back are the ones you paid to serve that buyer. Here's an illustrative example. A $6.99 paid photo app runs its filters through a cloud model and syncs projects to cloud storage. You paid for an ad that brought the buyer in.

That last row is where iOS gets expensive. A refunded buyer who keeps the app keeps calling your backend, and every inference request, sync and API call after the refund is a cost with no revenue behind it. On a paid app with no server costs, a refund is a lost sale. On one with a backend, it can turn into a running bill.

How to detect a paid app refund inside the app

Since the server hears nothing, the check has to start on the device and then tell your server.

On iOS, read revocationDate on AppTransaction

AppTransaction is the App Store's signed record of the customer's purchase of the app. Apple's StoreKit documentation now lists a revocationDate property on it, described as the revocation date of the app purchase. Read AppTransaction.shared at launch, verify the result, and treat a non-nil revocationDate as a refunded download. Send the signed value to your server so it can stop serving that account.

• appTransactionID stays the same for an Apple Account even after a refund or repurchase, Apple says, so key your records on it and a buyer who pays again is recognized.
• AppTransaction.refresh() fetches a fresh record from the App Store, but it shows a sign-in prompt. Apple says to call it only after an explicit user action, such as tapping a Restore button.
• The signed value lives on the device. Apple's documentation describes no server notification for it, so your server only learns what the app reports.

On Android, ask Play Integrity for the licensing verdict

Google's uninstall handles most cases, but a copy can outlive it, for example one sideloaded from a backup. The Play Integrity API returns an appLicensingVerdict for the signed-in account. LICENSED means the user has an app entitlement. UNLICENSED means they don't, and Google suggests showing the GET_LICENSED dialog. UNEVALUATED means Google couldn't check, for example because the user isn't signed in to Google Play. Google also notes that on some older devices a user keeps the entitlement after uninstalling, so LICENSED isn't proof of a live purchase on every device.

Treat the server as the gatekeeper

Client checks can be patched out. The part worth protecting is the paid work your backend does, so make the backend refuse calls from an account whose last report was a refund, an UNLICENSED verdict, or no verdict at all past a grace period you choose. That's what keeps a refund from turning into free compute.

When a paid app should move to in-app purchases

Apple's own guidance on changing business models describes moving from a paid app to a free app with In-App Purchases and using originalAppVersion on AppTransaction to keep giving premium features to people who bought the paid version. The refund upside of that move is concrete. Once the price sits on a non-consumable or a subscription, refunds arrive as REFUND notifications and voided purchases your server can act on, and a subscription refund request on the App Store triggers a CONSUMPTION_REQUEST. Those are the signals RefundHalt listens to and answers inside the 12-hour and 24-hour windows. A paid download gives you none of them.