Who pays for a refund on your app is mostly you, but not for the commission you think you're losing

There's a belief that won't die in developer forums: you keep 70 percent of a sale, but a refund makes you pay back 100 percent, so every refund quietly costs you the store's cut. It's wrong. When Apple or Google refunds one of your customers, the store gives its commission back too, and your books reverse only the share you actually kept. So the honest answer to who pays for a refund on your app is you, but for a different bill than most people name. You lose the sale and everything you already spent delivering it, not an extra 30 percent to the store. Here is where the money really goes, line by line, and why one kind of reversal, a chargeback, breaks the rule.

Who pays for a refund, split by store

Start with the reversal itself, before any talk of delivery costs. A refund on the App Store and a refund on Google Play unwind the sale the same way at the ledger level: the store stops charging you its commission and you give back your net proceeds. The customer gets their full price back either way. Here is the split, per store.

Does Apple keep its commission when a customer is refunded

This is the question developers ask most, in the Apple Developer Forums and on Hacker News: if Apple refunds a buyer, does it keep the cut it took on the sale? Read the financial report and the answer is no. A refund shows up as a row with Sale or Return set to R and a negative Quantity, and the money reversed is the Extended Partner Share, Quantity times Partner Share, where Partner Share is the customer price minus tax and Apple's commission. Apple is pulling back what it paid you, your net proceeds, not the gross price. Developers who pulled their own detailed reports found the same thing: Apple deducted the post-commission amount, not the full sale.

There's a catch in the fine print. Apple's Paid Applications Agreement says Apple has the right to retain its commission on a sale notwithstanding a refund to the end user. So the give-it-back behavior is how the reports settle in practice, not a promise. Apple keeps the contractual option to withhold its cut, and the common reading is that it does so when it decides a developer is doing something wrong.

What Google returns, and what a chargeback later keeps

Google is more explicit in writing. Its order-management help says that when you refund an order, Google returns the service fee to you and you see it on your next earnings report. The timing is tied to your payout. Refund an order before Google has paid you for it and you simply never receive that amount in your next payout. Refund it after you've been paid and the amount is deducted from a future payout. Partial refunds scale: refund half an order and half of both your payout and the service fee goes back to the buyer.

That's the clean case. A chargeback is not clean, and it's the one place where the store stops giving its cut back the way a plain refund does.

What actually leaves your account

So if the commission comes back, why does a refund still hurt? Because the sale price was never the whole cost of that customer. Walk the money in two buckets.

The first bucket is the sale itself. On a refund it nets close to zero. The customer gets their money back, the store returns its commission, and you reverse your proceeds. You're out the profit you had booked, which matters at scale, but you're not paying a penalty to the platform.

The second bucket is the one the reports never show. It's everything you already spent turning that payment into a delivered product, and none of it reverses when the payment does.

• Compute you already ran: the GPU seconds behind a generated image, video, or model response the customer already received.
• API calls you already paid for: every third-party request, from a maps lookup to an LLM token, billed to you the moment it fired.
• Storage you're still paying for: the files, exports, and history the customer created and you keep hosting.
• Payouts you already sent: the creator, driver, or seller share you disbursed against a sale that just reversed.

Add those up and a refunded customer can cost more after the refund than a customer who never bought. The sale washes out. The spend behind it doesn't.

How a refund moves through your payout

Refunds don't bill you separately. They travel through the same monthly settlement your sales do, which is why a heavy refund month can shrink a payout you already counted on.

On the App Store

Apple generates a financial report for each fiscal month, and refunds are booked into the month they settle, as negative Return lines. The report for a fiscal month is available by the first Friday of the next one. A refund issued this month reduces this month's proceeds. There's no separate invoice, just a smaller number.

On Google Play

Google puts every movement on your earnings report as its own line, one for a charge, one for a fee, one for a refund. If the refund lands before your payout for that order, the order's revenue never arrives. If it lands after, the refund is subtracted from a later payout. Either way it comes out of earnings, not a bill you pay.

The one line in your report that is the refund

On Apple, filter for Sale or Return equal to R. Every one of those rows is money leaving. On Google, look for the refund transaction type on the earnings report and the matching returned-service-fee line. Reconciling those against your own refund events is how you catch a customer who was refunded but never lost access, which is the failure that turns a cheap refund into an expensive one.

Why a chargeback costs more than a refund

Line the two up and the difference is the bank. On a normal Google Play refund, the service fee comes back and you're out only your share of a sale that reversed. On a chargeback under the August 3, 2026 policy, you're out the purchase price minus the service fee, and the financial institution's chargeback fee on top. Same lost sale, plus a fee that exists only because a bank, not a store, ran the reversal.

Apple's side has its own sharp edge. A chargeback, or a refund Apple grants after a CONSUMPTION_REQUEST you answered late, still reverses your proceeds, and Apple keeps the contractual right to retain its commission if it decides the pattern looks like abuse. The plain-refund math, where the store returns its cut, holds only while nothing about the transaction looks wrong.

What you can actually control

You can't decide whether a refund happens. Both stores reserve that. You can decide how much each one costs after it fires.

• Cut access the moment the reversal lands. A refunded or charged-back customer who keeps generating results, calling your APIs, and filling your storage turns a break-even reversal into a growing bill.
• Answer the two evidence windows on time. Apple's CONSUMPTION_REQUEST gives you 12 hours to send consumption data. Google's orders.reviewrefund gives you 24 hours to contest a chargeback. Those are the only moments your side of the story counts.
• Reconcile refunds against your own records every month, so a reversal that didn't revoke access shows up as a line you can act on, not a slow leak.

None of that changes who pays for a refund. It changes how big the bill is by the time you're done paying it.