Google Play's chargeback review gives you 24 hours to fight back, here's what to send

When a customer's bank pulls a Google Play charge back, Google Play does not just refund the money and move on. It sends your server a PendingRefundReviewNotification and starts a 24-hour clock. Answer that notification through the ReviewRefund API with a refund preference and evidence of what the customer actually used, and Google Play folds your input into how it contests the chargeback. Stay silent, and the dispute is settled without a word from the one party that knows how the product was consumed.

The Google Play chargeback review is the single Android refund flow that asks you for evidence, the direct counterpart to Apple's CONSUMPTION_REQUEST. It matters more now than it used to. Starting August 3, 2026, Google Play moves the cost of chargebacks onto developers, so a dispute you fail to answer comes out of your account, not Google's. Here is exactly what the notification carries, what you send back, the fields that make up your evidence, and where the silence turns into money.

What a Google Play chargeback review actually is

A chargeback is not a refund request. The customer goes to their bank or card network and disputes the charge, and the bank pulls the funds back. Google Play handles most of these on its own. For a subset, it opens a review and asks you first, because you hold information Google does not: whether the order was delivered and how much of it the customer consumed. That review is the flow behind the ReviewRefund API.

This is the one place in the Android refund system where your evidence changes the outcome. Every other Google Play refund path runs without you. A customer can self-serve a refund within 48 hours of purchase, support can grant one, and an unacknowledged purchase is auto-refunded, all decided by Google. The chargeback review is the exception, and it is worth treating as the only refund conversation you actually get to join.

It is the Android version of Apple's evidence window

Two stores, two flows that ask a developer for evidence, and that is the whole list. Apple sends a CONSUMPTION_REQUEST and gives you 12 hours to answer with Send Consumption Information. Google Play sends a PendingRefundReviewNotification and gives you 24 hours to answer with orders.reviewrefund. The mechanics differ, but the lesson is identical: when the store asks what the customer used, a precise answer is the difference between keeping the sale and handing it back.

One difference matters in practice. Apple's consumption payload is five numeric fields and nothing else. Google Play's evidence is richer. You can send a consumption percentage plus a list of individual usage events, each with a timestamp, an account identifier, and even an IP address and coarse location. Google Play gives you more room to describe delivery, which means more room to be convincing.

The 24-hour clock and how the notification reaches you

The review arrives as a Real Time Developer Notification on your Cloud Pub/Sub topic, the same channel that delivers your subscription and purchase events. The message is a base64-encoded payload with a pendingRefundReviewNotification object inside it. The clock starts when that notification is published, not when you happen to read it, so a consumer that polls once a day is a consumer that misses disputes.

PendingRefundReviewNotification, field by field

The notification is small. It tells you which order is under review, hands you the token you must quote back, and names the reason. Here is every field it carries.

Only a chargeback opens a pending review

The refundReason on a pending review is always CHARGEBACK, delivered as the integer 7. Other refund reasons exist in Google Play's world, but they do not reach you through this flow, because you do not get a say in them. If you see a PendingRefundReviewNotification, a bank has reversed a charge and Google Play is deciding whether to contest it. That is the only trigger.

What you send back through the ReviewRefund API

You respond with a single POST to orders.reviewrefund. The full path is POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}:reviewrefund, authorized with the https://www.googleapis.com/auth/androidpublisher scope, the same OAuth scope your Play Developer API integration already uses. A success returns an empty body with HTTP 200.

The body is where your case lives. You echo the pendingRefundToken from the notification, state a refund preference, and attach consumption evidence.

Your refund preference is a recommendation, not a verdict

The refundPreference field takes one of three values, and it is advice to Google Play, not a final decision. Google still owns the outcome. But it is advice backed by data Google cannot see on its own, so it carries weight.

The evidence fields that back up a DECLINE

A bare DECLINE is a claim without proof. The consumption fields are the proof. consumptionPercentageMilliunits is an integer in milliunits, so 100000 says the customer consumed 100 percent of what they bought and 50000 says half. consumptionUsageEvents is an optional array where each event can carry an obfuscatedAccountId, an obfuscatedProfileId, a consumptionTime, an ipAddress, a consumptionItemDescription, and a coarse location. sampleContentProvided is a boolean for the case where you gave the customer a free sample of the paid content. Together these say, in Google Play's own schema, that the product was delivered and used.

Your first call is your only call

Google Play records the first ReviewRefund call you make against a notification and ignores every call after it, while still returning an OK status. There is no draft and no revision. If your first response is a hurried NEUTRAL with no evidence because your pipeline was not ready, that is the response on the record, and the later call with the full consumption history is silently discarded. Build the complete answer before you send anything.

What the review costs you in money

For years a lost Google Play chargeback cost the developer the sale and little else, because Google Play absorbed the downstream fees. That ends on August 3, 2026. For orders placed after that date, Google Play shares chargeback cost with developers, and the developer's share is the purchase price less Play's service fee, plus the associated chargeback fee charged by the financial institution. Google Play keeps covering the service fee portion. The bank fee is new weight on your side of the ledger.

The refund is never the real number

The dispute returns the customer's payment, but 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 the order was delivered, and none of it comes back with the chargeback. Now add the bank's chargeback fee on top. You are paying the provider invoice, refunding the sale, and covering the dispute fee, three costs for one order you had the evidence to defend.

The scale Google is fighting

Google Play says it blocked US$3.4B of fraud and abuse in 2025 and is adding fraud detection through 2026. The cost-sharing change is part of the same push: give developers a reason to feed evidence into the system, and the system contests more of the illegitimate disputes. The ReviewRefund API is how your evidence gets in. An empty response is a vote to let a friendly-fraud chargeback stand on your dime.

How to be ready before the notification lands

The 24-hour window is not the problem. The problem is that the evidence you need has to exist before the dispute, captured at purchase and consumption time, not reconstructed after a token shows up. A team that starts gathering data when the notification arrives has already lost.

Attach identity at purchase time

Set an obfuscatedAccountId with setObfuscatedAccountId on every purchase, so the notification's account id maps straight to a user in your system. Keep it a hash, 64 characters or fewer, never cleartext email or other personal data, because cleartext identifiers get purchases blocked. Without that link you cannot connect the pendingRefundToken to a real usage history, and your DECLINE has nothing behind it.

Log consumption as it happens

Record what a paid order delivered, when, and to whom, in a form you can turn into consumptionPercentageMilliunits and consumptionUsageEvents on demand.

• Timestamp every unit of consumption, so consumptionTime on each event is real, not estimated.
• Track delivery against the purchase, so you can state a consumption percentage with confidence instead of guessing.
• Keep the account and profile identifiers next to the usage, so an event assembles in one query when the token arrives.
• Capture the request IP and coarse location if you have them, since Google Play accepts both as event fields.

Answer inside the window, automatically

A 24-hour window is comfortable for a machine and brutal for a human who has to be awake and paying attention. The response should be automatic: notification in, account looked up, consumption assembled, one ReviewRefund call out, all without a person in the loop. That is the part RefundHalt runs for you. We listen for the PendingRefundReviewNotification, match the order to the usage we already track for that account, and answer orders.reviewrefund inside the window with a refund preference and real consumption evidence. The token is the thread, and the evidence is the case. Have both ready and the one refund conversation you get to join is one you can win.