Google Play Refunds and Chargebacks in 2026: A Step-by-Step Guide to Chargeback Cost Sharing, the Review Refund API, and Voided Purchases

Google Play changed its refund rules for developers on August 3, 2026 — not the part users see, but the part that decides who pays when a purchase becomes a dispute. Chargeback costs are now shared, and a new API lets you argue your side of a chargeback before it is decided. If your app sells subscriptions or one-time unlocks and you have never looked at your voided-purchases pipeline, this is the quarter to fix that.

Below is the operational sequence: what the cost split actually says, how to tell a refund from a chargeback in Play Console, the only order data source that sees processor chargebacks, and the 24-hour window that decides how much of a dispute you carry.

1. What changed on August 3

The Play Console help page Updates to refund protection and chargeback cost responsibility states the change in plain terms: Google Play prevented US$3.4B of fraud and abuse in 2025, is adding further guardrails and fraud detection in 2026 to reduce refund abuse, and — to align with industry standards — will begin sharing chargeback costs with developers for orders placed after August 3, 2026.

The split is specific. A chargeback is a dispute a user opens directly with their bank or card issuer, not with Play. When one happens:

• Developer: the purchase price (less Play's service fee) plus the chargeback fees charged by the financial institution.
• Google Play: continues to cover the service fee for that transaction.

So a disputed sale is no longer revenue-neutral to you. You return what you collected and absorb a per-dispute bank fee, while Google waives its own commission. How large the returned amount is depends on your service fee tier, which Google documents in Service fees — and that document changed too: for transactions with users in the EEA, UK or US starting June 30, 2026, the fee depends on whether the user's install is classified as new or existing (auto-renewing subscriptions are treated separately, and the first US$1M of annual earnings sits in the lowest tier). Before you model the cost of a chargeback wave, confirm which tier your account is actually on.

2. Four different events look identical in your revenue reports

The Voided Purchases API documentation lists what can void a purchase, and they are not the same event at all:

• the user requests a refund for their order;
• the user cancels their order;
• the order is charged back;
• the developer cancels or refunds the order;
• Google cancels or refunds the order.

That API covers one-time in-app orders and App Subscriptions, and it comes with a warning worth reading twice: unlike other order-related data sources, it includes purchases charged back by payment processors, so you should expect inconsistencies between this API and other order data. Finance reports and your entitlement system legitimately disagree here — knowing that in advance is what stops a false alarm.

Two mechanics follow from the same page. Only revoked orders are returned: if you refund a purchase without setting the revoke option, the order will not appear in the API at all. And some purchases are refunded on the grounds that the purchase was never acknowledged by the developer — meaning the refunded order may not exist in your own records in the first place.

3. Step 1 — classify the order in Play Console

Manage your app's orders and issue refunds is where the money events show up, and the status labels carry the distinction that now costs money:

• Pending refund — a requested refund not yet processed.
• Refunded — with two variants that matter: This refund was paid by Google and This refund was a chargeback.
• Pending partial refund / Partially refunded — for partial amounts.

The chargeback variant is the expensive one: the money left because the user went to their bank, not because you approved anything. The same page also confirms you can issue full or partial refunds for in-app purchases and paid apps yourself — which is the cheaper path when a user is dissatisfied and still reachable.

4. Step 2 — wire the Voided Purchases API

This is the pipeline that lets you react at all, and its constraints are documented precisely:

• Endpoint: GET https://www.googleapis.com/androidpublisher/v3/applications/your_package_name/purchases/voidedpurchases, authorised with an OAuth client or service account that holds the View financial reports permission.
• Lookback: at most the past 30 days. Older voided purchases are not returned regardless of the startTime you send; the default is 30 days ago.
• Paging: maxResults defaults to 1000 and the maximum is also 1000; a nextPageToken continues the list. Keep using continuation tokens rather than raising the page size.
• Subscriptions: type=0 returns in-app purchases only; type=1 adds subscription purchases, and once you ask for subscriptions you must switch to orderId in the response, because a subscriptions-only view returns several orders sharing one purchaseToken.
• Partial refunds: includeQuantityBasedPartialRefund=true adds quantity-based partial refunds carrying a voidedQuantity. When the remaining quantity is finally refunded, that record has no voidedQuantity — that absence is the documented signal of a fully refunded multi-quantity purchase.

One subtlety that breaks naive time-window joins: records are filtered by when the API saw the order become voided, not by the voidedTimeMillis value returned in the response. A job that runs monthly and misses one execution silently loses records, because the window never extends. Schedule it more often than the window, dedupe on orderId or purchaseToken, and treat the response as a revocation signal rather than a complete accounting ledger.

5. Step 3 — answer the chargeback inside 24 hours

Google's guide Help Google dispute chargebacks describes the new flow, and it is time-boxed:

1. Watch for the notification. When a user initiates a chargeback that requires developer review, Play sends the PendingRefundReviewNotification Real-time developer notification. The RTDN reference lists it as a first-class field of DeveloperNotification, mutually exclusive with the voidedPurchaseNotification, one-time-product, subscription and test notifications.
2. Gather evidence and respond within 24 hours of receiving the notification by calling the Review Refund API. You supply a refund preference plus purchase usage evidence — the delivery state of the order and whether the item was consumed.
3. Know the one-shot rule. Play records the first API call made in response to a notification and ignores later calls, while still returning an OK status. An integration that fires twice is not corrected by a second attempt, and a mis-mapped payload is not fixable after the fact.

The Review Refund API is described as optional — Google is not requiring you to answer. But once you carry the purchase price and the bank fee, silence becomes the expensive option, and the 24-hour clock means the integration has to exist before the first notification arrives. This is the same pattern as Real-time developer notifications in general: a working webhook or Pub/Sub subscription, tested, is the prerequisite, not a follow-up task.

6. Step 4 — test the chargeback path before you need it

Google documents a test flow for user-initiated chargebacks in the Play Billing testing guide, which is the only reliable way to confirm three things: that your RTDN subscriber actually receives a PendingRefundReviewNotification, that your handler maps it to the right order and purchase token, and that your Review Refund call succeeds against a test purchase. Keep the handler idempotent and log the first response, since only the first call counts. Confirm the notification path end to end — a subscription set up but never exercised is not a control.

7. Step 5 — understand what refunds do to your payout

The order-management page also spells out the cash mechanics, and they are worse than they look:

• Refund before payout → the amount is not included in your next payout.
• Refund after payout → the amount is deducted from a future payout.
• If your balance goes negative and stays negative for at least 48 hours, Google collects the funds in accordance with the Terms of Service and debits the bank account that normally receives your payouts, in the amount of the negative balance as of the day the debit is initiated.

The practical read: a cluster of chargebacks in a low-revenue month does not simply shrink a payout — it can pull money out of your bank account. Accounts with volatile revenue or a seasonal spike-and-dip pattern should watch this number deliberately rather than discover it as a debit.

8. Step 6 — mind the user-facing 48 hours

Google's user-facing documentation explains why disputes escalate to banks at all. Learn about Google Play refund policies notes that refund policies differ by product, payment method and region, that most apps on Play are made by third-party developers, and that the developer can process refunds pursuant to its own policies and applicable law — with a direct recommendation that contacting the developer is often the quickest way to resolve an issue. Request a refund on Google Play tells users to contact the developer when they want a refund and it has been more than 48 hours since the purchase. EEA and UK users have a separate route for purchases made on or after March 28, 2018.

The operational conclusion is unglamorous: your refund policy page and a reachable support address are chargeback prevention infrastructure. A user who cannot reach you within the first two days is a user whose next step is their bank — and from August 3, 2026, that path is the one that costs you the price plus a fee.

9. What not to do

• Do not blanket-revoke on the first signal. The Voided Purchases API is documented as an indication of when to take additional action, and Google's own guidance calls for a fair, transparent revocation policy: tell users when you revoke access to an in-app product, give them time to understand policy changes before they take effect, and let them dispute your decisions.
• Do not refund without the revoke option and expect your pipeline to catch it. Only revoked orders appear in the API.
• Do not treat the API as a ledger. It includes processor chargebacks that other order sources omit, and it excludes refunds that were never acknowledged in the first place.
• Do not run it on a schedule as long as its window. A 30-day window and a monthly job have zero margin for a single failed run.

Sources

• Updates to refund protection and chargeback cost responsibility — Play Console Help
• Help Google dispute chargebacks — Play Billing, Android Developers
• Real-time developer notifications reference — Android Developers
• Voided Purchases API — Google Play Developer API
• orders.reviewrefund — Google Play Developer API reference
• Manage your app's orders and issue refunds — Play Console Help
• Service fees — Play Console Help
• Learn about Google Play refund policies — Google Play Help
• Request a refund on Google Play — Google Play Help