Most app refunds are decided without you, so the way to reduce app refunds is to prevent them before the request lands

Here is the uncomfortable part of trying to reduce app refunds. You do not get to approve most of them. A Google Play customer taps a button inside 48 hours and the money is gone before your server hears about it. An App Store customer files at reportaproblem.apple.com and Apple rules on it alone. A bank reverses a charge months later and that one is final the moment it lands. Fighting refunds after the fact is the wrong instinct, because in almost every flow there is nothing to fight. The way to reduce app refunds is to move upstream, to the handful of things that actually sit in your code and your billing setup, and to the two short windows where a store does ask for your evidence. This is that map.

What you actually control when you try to reduce app refunds

Split every refund into two piles. In the first pile, the decision is made without you: the store or the bank rules, and you learn the outcome as a notification after the money has already moved. In the second pile, a store pauses and asks for evidence before it decides. The first pile is large. The second pile is exactly two flows. Knowing which pile a refund lands in tells you whether the lever is prevention or response.

The refunds no one asks you about

Most refund paths never route to you. Google Play's 48-hour self-service refund is decided by Google with one customer tap. Support refunds, refunds Apple grants from reportaproblem.apple.com, and Google's own goodwill refunds are all decided by the store. Google also auto-refunds a purchase your app never acknowledges, and voids purchases it judges abusive, with no input from you. A bank chargeback is the extreme case: once the bank sides with the customer, the reversal is final and no store can undo it. For every refund in this pile, the only work available to you happened before the request existed.

The two moments you get a say

Two flows, and only two, pause to ask for your evidence. When a refund is in question for an eligible Apple purchase, Apple sends your server a CONSUMPTION_REQUEST and gives you 12 hours to answer through the Send Consumption Information endpoint. When a Google Play customer disputes a charge with their bank, Google sends a chargeback review and gives you 24 hours to answer through the orders.reviewrefund API. Both are evidence you submit, not a verdict you reach. They are the direct counterparts of each other, and they are the last line where your input still counts.

Prevent the refund before the store ever decides

Because the large pile is decided without you, the highest-leverage work is making sure those refunds never get triggered. Four levers do most of the job, and each one maps to a concrete store mechanic, not a vibe.

Acknowledge every purchase within three days

Google Play requires your app to acknowledge a purchase after you grant entitlement. Google's own words: the acknowledgment must be done within three days so that the purchase is not automatically refunded and entitlement revoked. That is a refund you caused, silently, with a bug. A crash between granting the item and calling acknowledgePurchase, a dropped server call, a pending purchase you acknowledged too early, any of them can strand a real sale and Google will claw it back at the three-day mark. This is the cheapest refund to eliminate because it is entirely inside your code.

Deliver what they paid for, every time

The most honest refund is the one where delivery failed. A customer paid, the coins never arrived, the pro features never unlocked, and now they want their money back and they are right. Double charges, entitlements that do not sync across a customer's devices, and content that never downloads are all refunds you manufactured. Reliable delivery, idempotent purchase handling, and restoring entitlements on a fresh install remove a whole category of legitimate requests before anyone opens a refund form.

Make your billing descriptor recognizable

A customer who does not recognize a line item on their statement does not file a friendly refund request, they call their bank. Google states it can act on unrecognized card or PayPal disputes for up to 120 days from the transaction, and carrier billing disputes for 60 days. A clear, searchable billing descriptor and an obvious app name on the receipt turn a would-be chargeback into, at worst, a support email. Given what a chargeback now costs on Android, this is the highest return per hour of work on this list.

Tag every purchase to an account

You cannot respond to a dispute you cannot trace, and you cannot revoke access from a customer you cannot identify. Tag every purchase with your own account identifier at buy time. On iOS, appAccountToken must be a UUID. On Android, setObfuscatedAccountId takes a hash of 64 characters or fewer, and it must never contain cleartext personal data, because Google blocks purchases that carry identifiable information in that field. This one habit is what makes every later step, evidence, revocation, and abuse detection, actually possible.

Cut the abuse you can see coming

Some refunds are neither honest nor accidental. A customer buys a consumable, spends every unit of it, then asks for the money back. Apple's own developer forums are full of this exact question about consumable in-app purchases, because the store cannot un-spend what the customer already used. You cannot stop the refund, but you can make sure it does not also leave them holding the goods.

Revoke access the moment a refund lands

When a refund or chargeback settles, cut the entitlement. On Android, the Voided Purchases API lists orders that were refunded, charged back, or revoked so you can pull back the item. On iOS, a REFUND notification on your server is the signal to revoke. If you skip this, a serial abuser keeps every coin, level, or premium unlock they already paid to reverse, and your app becomes the cheapest store in town. Revocation does not recover the sale, but it removes the reason to run the play again.

Answer the two evidence windows on time

For the two flows that do ask, showing up is the entire job. Apple's 12 hours and Google's 24 hours are hard deadlines, and they open on the store's schedule, not yours, often in the middle of the night. A CONSUMPTION_REQUEST you answer with delivery status and usage data is one Apple weighs against a refund. An orders.reviewrefund reply with delivery and consumption details is data Google uses to contest an illegitimate chargeback on your behalf. An unanswered window is a default loss. These cannot be handled by hand at any real volume, which is the whole reason to automate them.

What a prevented refund is worth in money

Prevention pays because a reversal is never just the sale price flowing back out. By the time a refund or chargeback lands, you have already delivered the purchase, and that spend does not return with it.

The sale price is the smallest part

When a refund clears you lose your net proceeds after the store's commission. But the compute that ran, the third-party API calls that were billed, the storage that was written, and any creator payout that went out the door are all gone too, and none of it comes back with the reversal. A prevented refund keeps the price and all of that delivery cost. The longer the refund window a customer used, the more of those costs you had already stacked up before the money left.

The August 3 change makes Android prevention pay more

For Google Play orders placed on or after August 3, 2026, a lost chargeback also costs the developer the bank's chargeback fee, on top of the purchase price less Play's service fee. Google continues to cover only its own service fee. Because chargeback fees are flat and product prices are not, on a cheap in-app purchase the fee alone can exceed what the customer paid. Every unrecognized-charge dispute you head off with a clear descriptor is now worth the sale plus a fee, not just the sale.

RefundHalt is built for the part of this you cannot do by hand. It watches for Apple's CONSUMPTION_REQUEST inside the 12-hour window and Google Play's chargeback review inside the 24-hour window, assembles the delivery and consumption evidence, and answers on time without anyone on your team awake to catch a 3am notification. It tracks refunds and chargebacks back to the account that made them, so the abuse you can see coming is visible instead of buried. You will never reduce app refunds to zero, because most of them are not yours to decide. You can make sure the ones you could have prevented never happen, and the two you can contest never go unanswered.