Google Play is making chargebacks your problem starting August 3, here's what changes
Google quietly rewrote who pays when a Play purchase gets disputed with the bank. For orders placed after August 3, 2026, a lost chargeback comes out of your pocket, and you get 24 hours to fight back. What changed, what it costs, and how to be ready.
Головне
- For orders placed after August 3, 2026, a lost Google Play chargeback costs the developer the purchase price, minus Play's service fee, plus the bank's chargeback fees. Google only covers its own service fee.
- Google now asks for your side first. A PendingRefundReviewNotification arrives over RTDN and you get 24 hours to answer through orders.reviewrefund.
- Your evidence does double duty: Google uses it to contest illegitimate chargebacks with the bank on your behalf.
- You can send a consumption percentage and up to 1,000 usage events, each with a timestamp, an IP address and a coarse location.
- Only your first response counts. Every later call is silently ignored and still returns OK, so the first answer has to be the complete one.
- Chargeback fees are flat and the product price isn't. On cheap in-app purchases the fee can cost more than the product, which makes silence the most expensive answer of all.
Google is about to end one of the quieter perks of selling on Play. Until now, when a customer disputed a charge with their bank instead of asking the store for a refund, Google absorbed the loss and you mostly never heard about it. For orders placed after August 3, 2026, that stops. A lost chargeback comes out of your pocket: the purchase price, minus Play's service fee, plus whatever chargeback fees the bank adds on top. Google's own exposure shrinks to the service fee it already collected.
There was no keynote moment for this. The change sits in a Play Console help article about refund protection, the kind of page you only find once money is already missing. Google's framing is that it's one half of a trade: its systems blocked 3.4 billion dollars in fraud and abuse on Play in 2025, more guardrails are coming, and in exchange developers start sharing the cost of the disputes that still get through.
The other half of the trade is genuinely new, and it's the part worth building for. For the first time, Google asks for your side before a chargeback is decided.
You finally get a say, but only for 24 hours
When a dispute needs developer review, a PendingRefundReviewNotification lands on your Real-time Developer Notifications topic and a clock starts. You have 24 hours to answer through the orders.reviewrefund API with your preference, approve, decline or neutral, plus whatever evidence you have. Google then uses what you send to contest illegitimate chargebacks with the bank on your behalf. If the window closes in silence, the dispute proceeds without you. If the mechanism sounds familiar, it should: it works a lot like Apple's consumption request, which has been asking iOS developers the same kind of question for years.
Here is the before and after in one place:
| Orders before Aug 3, 2026 | Orders after Aug 3, 2026 | |
|---|---|---|
| Who absorbs a lost chargeback | Mostly you | |
| What you lose | Nothing directly | Purchase price (less Play's service fee) plus the bank's chargeback fees |
| What Google covers | Everything | The service fee cost for the transaction |
| Can you contest it | No mechanism | Yes, a 24-hour evidence window |
What answering actually involves
The notification carries an order id and a pendingRefundToken, and the token matters: echo it back in your response or the response is rejected. To say anything useful about the buyer you also need to know who they are, which is what setObfuscatedAccountId at purchase time is for. If you've never attached an account id to purchases, matching a chargeback to a real user is guesswork, and that's the first thing to fix.
The evidence itself is more expressive than you'd expect from Google. Beyond your verdict and whether sample content was available before purchase, you can attach a consumption percentage (in milliunits, so 45200 means 45.2%) and up to 1,000 usage events, each carrying a timestamp, the IP address it happened from, a coarse location and a free-text description of up to 5,000 characters. Where and when the product was actually used is exactly the story a bank never hears from the cardholder.
The math on doing nothing
Chargeback fees are flat and product prices aren't. On a cheap consumable the bank's fee alone can exceed what the customer paid, so a single disputed coin pack can cost you a multiple of its price. Add the compute, storage and API calls you already spent serving that purchase and the arithmetic gets worse. The API is labeled optional, and technically it is. But for orders after August 3 you're paying for lost chargebacks either way, so opting out just means losing the same disputes without a fight.
What to do before August
- Turn on RTDN for all notification types. The review request rides the same topic as your subscription events, and if you only stream subscription notifications it will pass you by without a trace.
- Start attaching an obfuscated account id to every purchase. It's the only reliable way to connect a chargeback to a real user and their usage history.
- Work out where your usage evidence lives. Timestamps and IP addresses are what separate a customer who never launched the product from one who used it for a week and then called their bank.
- Automate the answer end to end, including a fallback that fires before the deadline when your data is missing. A 24-hour, first-answer-wins window is not something a support inbox survives.
This is the shape of problem RefundHalt was built for: we provision the Play topic, turn your usage data into evidence with IP geolocation attached, and answer inside the window every time, so silence never decides a dispute for you. But whether you build it or buy it, have it running before August. The first chargeback under the new rules won't wait for your roadmap.
Поширені запитання
- When does the Google Play chargeback change take effect?
- It applies to orders placed after August 3, 2026. Chargebacks on older orders follow the old rules, so the financial impact phases in as new orders accumulate.
- What does a lost chargeback actually cost?
- Per Google's policy article, the developer carries the purchase price, minus Play's service fee, plus the chargeback fees from the financial institution. Google keeps covering the service fee cost. On small purchases the bank's fee can exceed the price of the product itself.
- What evidence does orders.reviewrefund accept?
- Your verdict (approve, decline or neutral), whether sample content was provided before purchase, a consumption percentage in milliunits, and up to 1,000 usage events. Each event can carry a timestamp, an obfuscated account id, an IP address, a coarse location and a short description.
- Can I change my answer after submitting?
- No. Google records only the first response per notification and silently ignores everything after it, while still returning an OK status. The first answer has to be the right one.
- Is the Review Refund API mandatory?
- No, it's optional. But for orders after August 3, 2026 you pay for lost chargebacks either way, so skipping the one mechanism that lets Google contest them on your behalf just means eating the losses silently.
Джерела та додаткове читання
RefundHalt
Автопілот повернень для App Store і Google Play
Читайте далі
The refunds you cannot contest: what Apple and Google decide without asking you
Only two refund flows ever ask for your evidence: Apple's consumption request and Google Play's chargeback review. Everything else, the 48-hour Play refund, support refunds, voided purchases, unacknowledged trials, is decided without you. Here is the full map, what you can prevent, and what you can only record.
Apple's CONSUMPTION_REQUEST, explained: the 12 hours that decide your refund
When a customer asks Apple for a refund, Apple asks you first. Here's exactly what the CONSUMPTION_REQUEST notification contains, what Apple expects back, how to answer one end to end, and why most developers silently forfeit.