App Store refunds are Apple's decision. Google Play refunds are mostly yours to make.
An App Store refund is issued by Apple, not by you. The customer files it at reportaproblem.apple.com, Apple decides, and Apple tells them to wait 24 to 48 hours for an update. On Google Play the button is in your own console: you refund an order from Order management, and Google also refunds some orders without asking you. Either way the money comes off your account. What does not come off your account is the store's cut. Apple reverses the line at your Partner Share, and Google says plainly that it returns the service fee to you. Every field name and figure below is from Apple's and Google's own documentation, read on 10 October 2026. Most people meet this the month after they ship in-app purchases.
What follows is the split between the two stores. Who presses the button, what you are allowed to send before the decision is made, how your server hears about it afterwards, and the one refund cost Google moved onto developers this year.
Start hereThe short version
Both stores take the money back. Only one lets you press the button.
The uncomfortable part is not the commission. It is that on the App Store you are told, not asked. Apple's notification reference is written with Apple as the actor throughout: Apple refunds the transaction, Apple declines a refund the customer started in your app, Apple reverses a refund it had already granted after a dispute the customer raised. Your code finds out afterwards and cleans up.
The money is less brutal than most founders assume. Apple's financial reports treat a refund as a Return line, where Quantity goes negative and the amount reversed is built from Partner Share, which is the customer price minus applicable taxes and Apple's commission. Google states the same outcome in one sentence: it returns the service fee to you after a refund. You lose the revenue you earned, not the whole price the customer paid.
Who actually issues an App Store refund?
Apple. Apple's support page for customers walks them through it: sign in to reportaproblem.apple.com, choose Request a refund, pick the reason, pick the app or subscription, submit. Then wait 24 to 48 hours for an update on the request. If Apple approves it, the funds can take additional time to return to the payment method. None of those steps involve you, and there is no refund call on your side of the App Store Server API either. That API gives you a way to look refunds up and a way to send evidence. It does not give you a way to grant one or to block one.
The accounting arrives in two places that disagree for a while. Sales and Trends includes processed refunds in your daily unit totals and shows them as negative unit values once you filter for them, and Apple warns in the same help page that proceeds there are not final. The settled version is the financial report. Every row has a Sale or Return field, S for a sale and R for a return. The Quantity field is documented as positive or negative. Partner Share is the proceeds you receive per unit, defined as the customer price minus applicable taxes and Apple's commission, and it is always positive. Extended Partner Share is Quantity multiplied by Partner Share.
Read those four definitions together and the answer to the scary version of this question falls out. A refund subtracts what you were paid, not what the customer paid, because the per unit figure being multiplied by a negative quantity already has Apple's cut taken out of it. You are not billed for the commission on a sale that was reversed. What you lose is the revenue, the customer, and the time it takes to work out which transaction it was. For how that cut is calculated before any of this happens, Apple's commission has the rates and the conditions that change them.
Apple, App Store Server Notifications, notificationType, read 10 October 2026
What does Google Play do differently?
It hands you the button. In Play Console you open Order management, search by order ID or by the customer's full email address, select the order, pick a refund reason and submit. Full refunds work on anything you sell. Partial refunds are fenced off: you cannot issue them on paid apps, they only apply to orders placed after March 2018, and you can issue several against one order as long as the total stays under the order value. Google also spells out what a partial refund does to the fee. Refund 50 percent of an order and 50 percent of your payout plus 50 percent of the service fee paid to Google goes back to the user.
Three sentences from that page are the ones worth memorising. After you issue a refund, it cannot be reversed. Google will return the service fee to you, and you will see it on your next earnings report. And the payout mechanics: refund before Google has paid you for the order and that amount simply never arrives, refund after and it comes out of a future payout. If a refund leaves your account balance negative and it stays negative for at least 48 hours, Google collects the difference by debiting the bank account that normally receives your payouts.
Google also refunds without consulting you, which is why a refunded order you do not recognise can turn up in your console. Someone who buys a paid app has up to two hours to return it for a full refund, and can only do that once per app. Beyond that, Google issues refunds as a courtesy to users or as required by law, under the Developer Distribution Agreement. The order states name the source when it happens: this refund was paid by Google, or this refund was a chargeback. Chargebacks are the part that changed. For orders placed after 3 August 2026, Google Play and developers share chargeback costs. You carry the purchase price less Play's service fee plus the chargeback fees from the financial institution, and Google continues to cover the service fee cost for that transaction.
Subscriptions have their own fork and it decides whether the customer keeps access. Refund and revoke on the most recent order refunds that order, removes the subscription immediately and cancels future recurrences. A refund on an older order refunds it and leaves the subscription active. If you sell subscriptions, decide which of those two you mean before you click, because one of them ends the relationship and the other one does not.
Google Play Console Help, manage your app's orders and issue refunds, read 10 October 2026
Can you refuse a refund, or influence one?
On the App Store you cannot refuse, and you can influence. When a customer requests a refund for any product type, consumable, non consumable, non renewing or auto renewable, the App Store sends your server a CONSUMPTION_REQUEST notification. If the customer consented, you answer it by calling the App Store Server API endpoint for sending consumption information within 12 hours of that notification. Apple's wording on the outcome is careful and worth repeating to anyone who expects a veto: the App Store uses a variety of factors to determine whether a refund request is approved or denied, and the consumption information you provide informs its refund decisions.
The consent condition is a real obligation rather than a formality. Apple states that you must obtain valid consent from the customer before sharing their personal data through that API, that you are solely responsible for obtaining it because the data is yours, and that if the customer did not consent you should not respond to the notification at all. There is a matching outcome notification for the other direction, REFUND_DECLINED, which Apple sends when it declines a refund the customer initiated inside your app using the refund request API.
Google's equivalent is newer and narrower. A PendingRefundReviewNotification is sent when a customer requests a chargeback and the request needs developer review. You then have 24 hours to call the ReviewRefund API with a refund suggestion and purchase usage evidence, and Google notes that pending reviews support only chargebacks as the reason, so an ordinary refund request is out of scope. For ordinary requests, Google tells customers to contact the developer if it has been more than 48 hours since the purchase, so the awkward reply is genuinely yours to write. A short, published policy saves you from writing it from scratch every time.
How does your app find out a purchase was refunded?
On the App Store, through App Store Server Notifications, if you have given Apple a URL to post to. REFUND means Apple refunded the transaction for a consumable or non-consumable in-app purchase, a non-renewing subscription or an auto-renewable subscription. REFUND_REVERSED means Apple reversed a refund it had granted, after a dispute the customer raised. The transaction payload carries what you need to act on: a revocation date, a revocation reason, and a revocation percentage, which Apple describes as the percentage of the transaction amount the App Store has refunded or revoked, expressed as a decimal.
Notifications get lost, so Apple provides a way to catch up. The Get Refund History endpoint returns a paginated list of a customer's refunded in-app purchases for your app, up to 20 transactions per page, covering App Store approved refunds of any product type. Apple says in that reference to use it to retrieve refund notifications you may have missed, such as during a server outage. Treat the notification as the fast path and the lookup as the reconciliation job that runs on a schedule.
On Google Play the live signal is a real time developer notification. A voidedPurchaseNotification carries the order ID, a product type of subscription or one time, and a refund type of either a full refund or a quantity based partial refund, the latter applying only to multi quantity purchases. The batch equivalent is the Voided Purchases API, and it has two limits worth designing around rather than discovering: it only returns purchases voided in the past 30 days, and the quota is 6,000 queries a day plus no more than 30 in any 30 second window.
There is one trap in that API and it is easy to walk into. Only revoked orders appear in it. If a refund is issued without the revoke option set, the order is refunded and the API never mentions it, so a reconciliation job built on that endpoint alone will quietly miss money that has already gone. Taking access away inside your own app is your code on both stores, with the single exception of a Google subscription refunded with revoke. Decide what revocation means for your product while you are still choosing how to charge, and keep it with the rest of your monetisation decisions rather than bolting it on after the first refund lands.
Apple, App Store Server Notifications, notificationType, read 10 October 2026
The same refund, handled two ways
| The question | App Store | Google Play | Same on both |
|---|---|---|---|
| Who can issue one | Apple, from the customer's own request | You, in Order management, and Google itself | No |
| You can refund an order yourself | No | Yes | No |
| The store's cut comes back to you | The Return line reverses your Partner Share | Google returns the service fee on your next earnings report | Yes |
| You can send evidence before the decision | Consumption information, within 12 hours | ReviewRefund, within 24 hours, chargebacks only | Yes |
| Your server gets a notification | Yes | Yes | Yes |
| A refund can be undone | REFUND_REVERSED exists, after a dispute the customer raised | After you issue a refund, it cannot be reversed | No |
| Taking access away is your code | Yes | Yes | Yes |
Google Play Console Help, manage your app's orders and issue refunds, read 10 October 2026
Where this lands if a builder generated your app
Refund handling is server work, so what matters is whether you own the project and the accounts. Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project that you own, with two way GitHub sync, so the code is never somewhere you cannot reach. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It costs $25 a month and there is no free tier.
Two things follow from that for refunds. The developer accounts are yours, so the refund notifications, the order management screen and the money all arrive on your side rather than a vendor's. And Newly does not submit to the App Store on your behalf, because Apple requires the owner of an app's content to submit it, which means the Apple account receiving CONSUMPTION_REQUEST notifications is yours from the first release.
The honest limit: generating an app does not give you a refund policy or a reconciliation job. An endpoint that verifies a signed notification, a record of what each customer consumed, and a rule about when you take access away are all things you have to ask for and then maintain. They are small pieces of work, and they are much cheaper to add while you are building the paywall than during the week you first see a chargeback.
Questions founders ask about app store refunds
Apple does. The customer signs in to reportaproblem.apple.com, chooses Request a refund, picks the item and submits it. Apple tells them to wait 24 to 48 hours for an update, and says that if Apple approves the request the money can take longer to reach their payment method. You are not asked. Apple's own notification reference is written the same way, with Apple as the actor: Apple refunds the transaction, Apple declines a refund, Apple reverses a previously granted refund.
Make a refund a line in a log, not a mystery
Ask for the notification endpoint and the revocation rule in the same breath as the paywall. Then the first refund is something your app already knows what to do with.
Start building