The difference between a chargeback and a refund comes down to who decides, and only one of them is final

Two words get used as if they mean the same thing. The customer gets their money back either way, so who cares which one it was. For an app developer selling through the App Store or Google Play, the difference between a chargeback and a refund decides who controlled the outcome, whether you could have changed it, and starting this month, how much the reversal takes out of your account.

Here is the short version. A refund is the store handing money back, and the store decides it. A chargeback is the customer's bank pulling the money, and the bank decides it, with no appeal. You sit in very different places in each one. This is what each looks like on Apple and Google, the two moments where the store actually asks you for anything, and what the gap between them now costs.

The difference between a chargeback and a refund is who decides

Strip away the payment jargon and one question separates the two: who makes the final call. A refund is a decision made inside the store's own system. A chargeback is a decision made at the customer's bank, one layer further out than any store setting can reach. That single fact drives everything else, from whether you can contest it to what it costs.

Who starts it, and who decides

A refund can start two ways. The customer asks the store for their money back, or you issue the refund yourself. Either way the store, Apple or Google Play, approves it and returns the funds. A chargeback starts only one way. The customer skips the store entirely and disputes the charge with their bank or card network, and the bank claws the money back from the store's payment system. The store did not choose it, and neither did you.

The store is the seller, not you

This is the part that trips up developers coming from classic ecommerce. When you sell through the App Store or Google Play, you are not the merchant of record. Apple and Google are. The customer's card statement reads Apple or Google, not your company name. So when that customer disputes the charge, the chargeback lands on the store's payment system first. You are not on the phone with the bank. You find out through the store, if the store tells you at all.

The two side by side

What a refund looks like on the App Store and Google Play

Most refunds are not a conversation you get to join. The store takes the request, checks it against its own rules, and returns the money. You are told after the fact, if you have wired up the notifications that carry the news.

Apple decides, then tells your server

An Apple customer requests a refund at reportaproblem.apple.com, and Apple has up to 90 days from purchase to accept the request for review. Apple reviews each case on its own and decides. When it grants the refund, your server gets a REFUND notification through App Store Server Notifications V2, and the transaction now carries a revocationDate. When it denies the request, you get REFUND_DECLINED. If Apple later undoes a refund it already granted, you get REFUND_REVERSED and the sale comes back. In none of these do you cast a vote. You react.

Google Play refunds most purchases without asking you

Google Play lets a customer self-serve a refund within 48 hours of purchase, straight from their account, with no developer involvement at all. Past 48 hours the customer is routed to you, and you can grant or decline through your own policy. Support can issue refunds, and an unacknowledged purchase is auto-refunded after about 72 hours. All of these run on Google's side. You see the result through a voided purchase notification or the Voided Purchases API, and your job is to revoke access, not to approve the refund.

The two flows where the store actually asks you

There are exactly two moments across both stores where the store stops and asks the developer for evidence before it decides. Apple sends a CONSUMPTION_REQUEST when a customer requests a refund, and gives you 12 hours to answer through Send Consumption Information with usage data. Google Play sends a chargeback review and gives you 24 hours to answer through the orders.reviewrefund API. Everything else is decided without you. These two windows are the only place your input changes the outcome, which is why they are worth automating and the rest is worth monitoring.

What a chargeback looks like, and why it is final

A chargeback is not a refund with extra steps. It is a different mechanism with a different decision maker, and that changes what you can do about it.

The bank pulls the money, not the customer

In a chargeback the customer tells their bank the charge was wrong, fraudulent, unrecognized, or never delivered. The bank sides with its cardholder by default and reverses the transaction, pulling the funds back through the card network. The store did not approve it. The money is already gone before anyone asks whether the product was delivered. This is why a chargeback is slow and heavy where a refund is quick and clean: it runs through the card network's dispute process, which takes weeks or months, not minutes.

The bank's decision is final

You cannot overturn a chargeback the way you might reverse a refund. Once the bank rules, that ruling stands. The one place you get to influence it is before it is decided. On Google Play a bank-initiated dispute can open a review, and Google Play sends your server a notification with a 24-hour clock. Answer through orders.reviewrefund with a refund preference and real consumption evidence, and Google Play folds your input into how it contests the chargeback on your behalf. Miss the window and the dispute is settled without the one party who knows how the product was used.

What each one actually costs you

For a long time the honest answer was that a chargeback and a refund cost an app developer about the same: the sale, and whatever you already spent to deliver it. That stopped being true for Google Play developers this month.

The refund is never the only number

Whether the reversal is a refund or a chargeback, the payment was never your only cost. A generated video, a batch of model API calls, a creator payout, storage you provisioned, all of that money left your account the moment you delivered the order, and none of it comes back when the charge is reversed. The sale is the visible number. The compute, the API calls, the storage, and the payouts are the ones that already cleared. Argue the reversal on value delivered, never on how long the customer waited, because elapsed time is not a cost and Apple and Google do not treat it as one.

From August 3, 2026 a chargeback adds a bank fee

Here is where the two stop costing the same. Until now Google Play absorbed the downstream cost of a chargeback. For orders placed after August 3, 2026, Google Play shifts that cost to the developer. On a lost dispute you pay back the purchase price less Play's service fee, and on top of that you pay the chargeback fee charged by the financial institution. Google Play keeps covering the service fee portion. A refund does not carry that bank fee. So a charge that ends in a chargeback now costs you strictly more than the same charge refunded, and the extra is the bank's fee.

The scale behind the change

Google Play says it blocked US$3.4B of fraud and abuse in 2025 and is still adding fraud detection through 2026. Moving chargeback cost onto developers is part of that push. It gives you a direct reason to feed evidence into the review flow, so the system contests more of the illegitimate disputes. Your evidence is what makes a contest possible, and an empty response is a vote to let a friendly-fraud chargeback stand on your money.

How to keep a refund from becoming a chargeback

The cheapest chargeback is the one that never happens, because the order got refunded first or got contested with evidence that was already sitting there. None of this needs a person awake at the right hour. It needs the plumbing in place before the dispute.

Refund a bad order yourself before the bank does

If an order is clearly going to be disputed, refunding it yourself is cheaper than losing the chargeback. A refund you issue does not carry the bank's chargeback fee. On Google Play you can refund any order under three years old with one orders.refund call, with or without revoking access. Get there before the customer reaches their bank and you turn a bank fee plus a lost sale into just a lost sale.

Answer the two evidence windows automatically

The 12-hour Apple window and the 24-hour Google Play window are comfortable for a machine and brutal for a human who has to be watching. The response should be automatic: notification in, account looked up, consumption assembled, one call out, no person in the loop. That is the part RefundHalt runs for you. We listen for the CONSUMPTION_REQUEST and the Google Play chargeback review, match the order to usage we already track, and answer inside the window with a refund preference and real consumption evidence.

Attach identity and log consumption up front

Evidence you need at dispute time has to exist before the dispute. Set an account identifier on every purchase so a notification maps straight to a user, an appAccountToken UUID on Apple and a hashed setObfuscatedAccountId of 64 characters or fewer on Google Play, never cleartext personal data. Log what each paid order delivered, when, and to whom, in a form you can turn into a consumption percentage on demand. Do that and the narrow window is enough, because the case is already built when the token arrives.