A bad app update can trigger a wave of refunds, and here is how to contain it before it reaches your payout
A broken release is one of the few refund drivers you can throttle in minutes. A bad app update hands paying customers a reason to ask for their money back, and the sale is the smallest part of what you lose. Here is how to halt one on each store, and what a refund wave really costs.
Key takeaways
- A bad app update is one of the few refund drivers a developer can throttle directly, because both Apple and Google release updates in stages and let you stop the rollout mid-flight.
- Apple's phased release ships an update to automatic-update users over 7 days at 1, 2, 5, 10, 20, 50, and 100 percent, and you can pause it for up to 30 days with no limit on the number of pauses.
- Google Play staged rollouts let you halt a release so no additional users receive it, and you can halt a fully rolled-out version too, at which point the previous version automatically takes its place for users who are not already on the broken one.
- The refunded sale is the smallest cost of a broken release. The compute, API calls, and storage you already spent serving each purchase do not come back when the charge does.
- For Google Play orders placed after August 3, 2026, a bad release that turns into chargebacks costs more, because the developer absorbs the purchase price minus Play's service fee plus the bank's chargeback fee.
- Phased release and staged rollout only cover automatic updates. Anyone who updates by hand or installs fresh always gets the newest build, so halting limits the blast radius but never seals it.
- Once a customer disputes a purchase, your only input is a short window: Apple's CONSUMPTION_REQUEST at 12 hours and Google Play's orders.reviewrefund at 24 hours.
When a release ships broken, the refunds start before your crash dashboard does. A bad app update does not just annoy people. It hands them a concrete reason to ask for their money back, and on a low-price purchase the money is the smallest part of what you lose. The compute you already burned, the third-party API calls you were billed for, and the storage you provisioned do not come back with the sale.
The useful part is that a broken release is one of the few refund drivers you can throttle in minutes, not weeks. Both stores ship an update in stages and let you stop it mid-flight, and that single control is the difference between a handful of affected users and a wave of refunds against your payout. Here is what a refund wave actually costs, how to halt a bad release on each store, and the two short windows that are your only say once a dispute is already filed.
Why a bad app update turns into refunds
A crash on launch, a paywall that will not load, a feature that worked yesterday and does not today. Each one gives a paying customer a clean reason to ask for their money back, and a refund is the polite version of that response. The impolite version is a bank chargeback. Both cost you, and a release that breaks for even a slice of your users can produce enough of them to show up on your payout.
The money you lose is more than the sale
When a purchase is refunded, the sale amount goes back to the customer. What does not come back is everything you already spent to serve that purchase. The compute that ran the work, the third-party API calls you were billed for at the moment of use, the storage you provisioned, and any payout you already sent a creator are gone. On a low-price consumable, those sunk costs plus a possible bank fee can add up to more than the customer ever paid.
A refund wave also moves your refund rate
Refunds are not only a per-sale loss. Card networks and both stores watch the rate at which your sales come back. A single broken release that spikes that rate can draw scrutiny you would rather avoid, so the cost of a bad update includes the standing you spend, not only the dollars.
| Item | Recovered on refund | Notes |
|---|---|---|
| Sale amount | Yes | Returned to the customer |
| Compute and third-party API calls | No | Billed to you at the time of use |
| Storage you provisioned | No | Already paid for |
| Creator or partner payout | No | Sent before the refund |
| Bank chargeback fee | No | Flat, can exceed a low-price sale |
How to stop a bad release on the App Store
Apple's containment tool is phased release, and its whole value is that you can pull the brake before most of your users ever see the broken build.
Phased release ships over seven days
When you turn on phased release for a version update, Apple delivers it to a random sample of users who have automatic updates on. The rollout climbs on a fixed schedule: 1 percent on day one, then 2, 5, 10, 20, 50, and 100 percent across seven days. Because the early days touch a small fraction of your base, a defect caught on day two has reached far fewer people than a same-day full release would.
Pause the moment something looks wrong
If a bad app update slips through, you can pause the phased release at any point. Apple lets you pause for up to 30 days, with no limit on how many times you pause, and the budget is cumulative: pause for 10 days, resume, and you still have 20 days of pause left. When you resume, the rollout picks up on the day it stopped. Pausing does not pull the build from users who already have it, so pair the pause with a fix and an expedited review.
How to stop a bad release on Google Play
Google Play gives you two brakes, one for a release still rolling out and one for a release that already reached everyone.
Halt a staged rollout in progress
A staged rollout on Google Play lets you release to a percentage of users and raise it on your own schedule. If you find a problem, open the release and choose Manage rollout, then Halt rollout. No additional users receive the version, and the users who already got it stay on it. If the build turns out to be clean after all, you resume the same rollout from where it stopped.
Halt a release that already went to 100 percent
Google Play also lets you halt a fully rolled-out release, which the staged-rollout brake cannot do. When you halt it, a previously live, fully rolled-out version of your app automatically takes its place for new and existing users who are not already on the halted build. Two limits matter: you cannot halt the first release on a track, and if the broken version has been live long enough that most users already updated, halting does little, because the damage is already distributed.
| Containment control | App Store | Google Play |
|---|---|---|
| Gradual rollout | Phased release over 7 days, automatic updates | Staged rollout at a percentage you set |
| Stop a rollout in progress | Pause, up to 30 days, no pause limit | Halt rollout, resume later |
| Pull a version that already reached everyone | Not available | Halt a fully rolled-out release, previous version takes its place |
When the refunds and disputes are already in motion
Staging a rollout limits how many people hit a bad app update. It does nothing for the refunds and disputes from the users who already did. Once a customer asks for their money back, the store runs the flow, and your say is narrow.
Most refunds are decided without you
Google Play's 48-hour self-service refund, support refunds, and voided purchases are all decided by the store under its own policy. There is no evidence channel and no appeal. For those, your record is the refund itself and the cost you already ate. The one place you can act is prevention, which is exactly why the rollout brake matters.
Two windows are your only input
Only two flows ask you for anything. 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. On Google Play, a disputed purchase that needs review starts a 24-hour clock, and you answer through the orders.reviewrefund API. Miss either window and the decision is made without you. Neither window lets you undo a bad release. They only let you respond to its fallout.
The containment checklist
None of this is exotic. It is a short routine you run on every release, not only the ones you expect to break.
- Ship every update through phased release on the App Store and a staged rollout on Google Play, never a same-day full push.
- Watch crash and refund signals during the first low-percentage days, when the audience is small enough to protect.
- Pause the App Store phased release or halt the Google Play rollout the moment a real defect appears, then fix and resubmit.
- For a defect that already reached everyone on Google Play, halt the fully rolled-out release so the previous version takes its place.
- Provision the Apple and Google notification feeds so you can answer every consumption request and refund review inside its window.
- Track your refund rate across the release, because a spike is the signal that a rollback is overdue.
Frequently asked questions
- Can a bad app update cause a spike in refunds?
- Yes. A crash, a broken paywall, or a feature that stops working gives paying customers a direct reason to request a refund, and some escalate to a bank chargeback. Because both stores release updates in stages, catching the problem early and halting the rollout is the most reliable way to keep a bad app update from turning into a wave of refunds.
- How do I stop a bad update on the App Store?
- Use phased release. It delivers a version update to automatic-update users over 7 days at 1, 2, 5, 10, 20, 50, and 100 percent, and you can pause it for up to 30 days with no limit on the number of pauses. Pausing stops new automatic updates while you ship a fix, though anyone who updates manually still gets the newest build.
- Can I roll back an update that already went out to all users on Google Play?
- On Google Play, yes. You can halt a fully rolled-out release, and a previously live, fully rolled-out version automatically takes its place for users who are not already on the halted build. You cannot halt the first release on a track, and if most users already updated, halting does little because the version is already distributed.
- Do refunds from a bad release cost more than the sale price?
- Usually. The refund returns the sale amount, but the compute, third-party API calls, and storage you already spent serving each purchase do not come back, and any creator payout is gone. On low-price purchases, sunk serving costs plus a possible bank chargeback fee can exceed what the customer paid.
- Can I contest refunds caused by a broken update?
- Only two flows accept your input, and neither undoes the release. Apple sends a CONSUMPTION_REQUEST with a 12-hour window, and Google Play's orders.reviewrefund gives you 24 hours to respond to a disputed purchase. The 48-hour Play self-service refund, support refunds, and voided purchases are decided by the store with no appeal, so prevention through a staged rollout is your real lever.
Sources and further reading
- App Store Connect Help: Release a version update in phases (the 7-day schedule and pause rules)
- Play Console Help: Release app updates with staged rollouts (halt and resume a rollout)
- Play Console Help: Halting a fully rolled-out release
- Google Play Help: Refund policies for apps, games, and in-app purchases (48-hour self-service refund)
- Google Play Console Help: chargeback cost responsibility for orders after August 3, 2026
- Android Developers: Help Google dispute chargebacks (the 24-hour orders.reviewrefund window)
- Apple Developer: App Store Server Notifications, CONSUMPTION_REQUEST (the 12-hour consumption window)
RefundHalt
The refund autopilot for the App Store and Google Play
Keep reading
Most app chargebacks can be prevented before the bank gets involved, and stopping one now saves more than the sale
App chargebacks are now the most expensive way a sale comes back, because Google Play shifts the cost onto the developer for orders placed after August 3, 2026. Most disputes start as confusion or fraud you can head off. Here is the playbook, and what a lost dispute really costs.
Your dashboard books a sale the day it clears, but net revenue after refunds is the only figure your ad budget should trust
A sale is counted the instant it clears. The refund lands days later, the chargeback months later, and by then you have already spent against the money. Here is how refunds and chargebacks inflate your revenue and LTV, and why net revenue after refunds is the number to run the business on.