Most app chargebacks can be prevented before the bank gets involved, and stopping one now saves more than the sale

A chargeback is not a refund, and treating the two the same is how app studios lose money they never had to lose. A refund runs through the store: the customer asks Apple or Google, the money goes back, and that is the end of it. A chargeback skips the store and goes to the bank. The customer tells their card issuer the charge was wrong, the issuer pulls the money, and a separate fee often rides along. For Google Play orders placed after August 3, 2026, that fee and the lost sale land on the developer, not on Google. That single change is why app chargebacks are now worth preventing, and why most of them can be stopped long before a bank is ever involved.

Here is the part that helps you. A large share of app chargebacks are not sophisticated fraud. They start with a customer who cannot tell what a charge is for, or a purchase that should never have cleared in the first place. Both are things you can act on. The rest of this is a playbook: what a lost dispute actually costs, the disputes you can prevent, the fraud you can block at the source, and the two short windows that are your only say once a bank is already deciding.

Why a chargeback costs more than a refund

A refund and a chargeback both end with the customer's money going back, so studios file them in the same mental bucket. The costs are not the same. A refund returns the sale amount and nothing else. A chargeback returns the sale amount and adds the bank's dispute fee, and that fee is flat while your prices are not.

The App Store and Google Play divide the bill in different ways

On the App Store, a card chargeback is resolved between the bank and Apple, and Apple carries the mechanics. On Google Play, the rules changed. For orders placed after August 3, 2026, Google covers only the service fee it already collected, and the developer absorbs the purchase price minus that service fee, plus whatever chargeback fee the bank charges. Google describes the move as bringing Play in line with the rest of the payments industry.

The costs you already spent do not come back

The refunded or disputed amount is only the visible loss. You already paid to serve that purchase. The compute that ran the generation, the third-party API calls you were billed for, the storage you provisioned, and any payout you sent a creator do not reverse when the charge does. On a low-price consumable, a bank's flat chargeback fee alone can exceed what the customer paid, and the sunk serving cost sits on top of that. That is why a prevented chargeback is worth more than its sticker price.

How to prevent chargebacks before the bank gets involved

You cannot stop every dispute, but you can remove the two most common reasons one gets filed: the customer did not recognize the charge, and the purchase was fraudulent from the start. Handle those and the volume drops.

Confusion drives more disputes than fraud

When a customer scans a statement and cannot place a line, many call the bank before they think to contact you. The label you get to control is thin. Apple prints apple.com/bill on every purchase and gives you no setting to change it, so your app name never appears. Google Play prefixes GOOGLE and then shows the statement name you set in Play Console, which is the one descriptor field either store hands you. Set it to a name your customers will know.

Make the charge recognizable everywhere else

Since you cannot fix Apple's descriptor, fix everything around it. A surprise charge is a classic dispute, so remove the surprise before it reaches a statement.

• A branded in-app and email receipt that names the product and the amount, sent as soon as the purchase clears.
• A renewal reminder before the charge on annual and high-price subscriptions, so the renewal is never a shock.
• In-app subscription management and a one-tap way to ask for a refund, so the customer reaches you first.
• A support reply inside the dispute window, since a fast answer often stops a customer from escalating to the bank.

Every one of these turns a would-be chargeback into a support conversation or an ordinary refund, and a refund carries no bank fee.

Stop the fraudulent purchase at the source

The disputes you cannot talk your way out of are the ones where the purchase was fraudulent to begin with. Those you block before they clear, on your server, with tools both stores document.

Verify every purchase on your own server

Never grant an entitlement on the client's word. Send the purchase token to your backend, confirm it against the store, and store it. Google Play makes the purchaseToken globally unique, so you can use it as a primary key and reject any token you have seen before, which kills replay and receipt sharing. Verify with the Play Developer API before you unlock anything, and on the App Store validate the signed transaction the same way.

Never deliver a purchase that is still pending

A pending purchase is not money in hand. Google Play tells you to grant an entitlement only when the purchase state is PURCHASED, never while it is PENDING, because a pending charge can still fail. Deliver early and you have handed away the product on a payment that may never arrive, which is a loss you created, not a dispute you can fight.

Tag every purchase to the buyer

Both stores let you attach an account identifier to a purchase, which helps them spot suspicious patterns and helps you match a dispute to a user. On Google Play, set the obfuscated account id and profile id on the billing flow with setObfuscatedAccountId and setObfuscatedProfileId. On the App Store, set an appAccountToken, which must be a UUID. Feed the store good signals and it blocks some fraud before the transaction completes.

Claw back and cut off repeat abusers

When a purchase is voided, revoked, or charged back, Google Play's Voided Purchases API tells you, so you can claw back the unused item or set a balance negative. Warn a first-time offender, then disable purchases or access for an account that does it again. A serial refunder who keeps their access is an invitation to the next dispute.

When a dispute is already filed, answer the window

Once a chargeback is in motion, you cannot reverse it yourself. What you can do is hand the store evidence, inside a short window, and let the store fight the bank with it.

Apple gives you 12 hours

When a customer requests a refund on a consumable or an auto-renewable subscription, Apple sends your server a CONSUMPTION_REQUEST and waits up to 12 hours for consumption data: whether you delivered, how much was used, and whether you would prefer the refund granted or declined. Apple still decides, but your answer is a documented input to that decision.

Google Play gives you 24 hours

For a disputed Play purchase that needs review, a PendingRefundReviewNotification arrives over Real-time Developer Notifications and starts a 24-hour clock. Answer through the orders.reviewrefund API with your preference and your evidence, and Google uses it to contest illegitimate chargebacks with the bank on your behalf. Let the window close in silence and the dispute proceeds without you.

Why you cannot file the bank evidence yourself

Payments teams talk about Visa's Compelling Evidence 3.0, a rule that lets a merchant defeat a friendly-fraud dispute by showing two prior undisputed transactions on the same credentials, each between 120 and 365 days old, with matching data such as IP address or device id. For your in-app sales you are not the merchant of record. Apple and Google are. So the store, not you, assembles that kind of evidence, and the only way your data reaches the fight is through the review window above. That is the practical reason the 12-hour and 24-hour clocks matter so much. They are your whole seat at the table.

The pre-dispute checklist

None of this is exotic. It is a short list you can put in place before your next billing cycle.

• Set a recognizable Google Play statement name, and send branded receipts everywhere else.
• Send renewal reminders before annual and high-price charges.
• Put subscription management and refund requests one tap inside the app.
• Verify every purchase on your server and store the token as a unique key.
• Grant entitlements only on a PURCHASED state, never on PENDING.
• Attach an account id or a UUID appAccountToken to every purchase.
• Provision the Apple and Google notification feeds and answer every consumption request and refund review inside the window.