Google Play's Aug 3 chargeback policy: what actually changes

The Google Play chargeback policy for 2026, in one table

Google's policy notice is short. Its central sentence is precise: Google Play and developers will begin sharing chargeback costs for orders placed after August 3, 2026.

That order-date language matters. The cutoff is not described as “chargebacks opened after August 3” or “cases reviewed after August 3.” An older order disputed later is not within the wording Google published. Conversely, an order placed after the cutoff can create the new liability even if the chargeback arrives weeks or months later.

Google has not published the cutoff's timezone or explained edge cases for orders placed on August 3 itself. Until it does, do not manufacture a midnight boundary. Preserve the order timestamp and apply Google's literal wording in reporting.

What changes financially

A chargeback is not an ordinary refund request inside Google Play. Google defines it here as a dispute initiated by a user directly with their financial institution. Under the new allocation, the developer is responsible for two components when a covered chargeback occurs:

1. the purchase price after Play's service fee; and
2. the associated chargeback fees imposed by the financial institution.

Google continues to absorb its service fee for that transaction. Put plainly: Google is not passing its commission back to the developer, but it is passing the developer's net proceeds and the external chargeback fee.

There is no official fee schedule in the policy notice. Google does not say that every institution charges the same amount, publish a currency table, or provide a fixed estimate. Any calculator that presents one universal “Google Play chargeback fee” as policy is adding an assumption. Your defensible cost number must come from actual settlement data or a model whose assumptions are shown separately.

Google also says it introduced enhanced guardrails and fraud detection in 2026. It does not publish their mechanics, expected reduction in chargebacks, or a protection guarantee. Treat that as platform context, not a forecast you can put into a budget.

The new review path is selective, optional, and one-shot

The economic policy and the technical review flow were announced together, but they are not the same thing. The policy assigns cost responsibility. The Review Refund API creates a channel for developer input on chargebacks that Google sends for review.

Google's implementation guide says a PendingRefundReviewNotification is sent when a user initiates a chargeback that requires developer review. That qualifier means you should not assume every chargeback will open a review window. Google has not published the selection criteria or promised review coverage for every disputed order.

1. Google Play sends an RTDN

The trigger arrives through Google Play's Real-time Developer Notifications over Cloud Pub/Sub. The RTDN reference defines a pendingRefundReviewNotification containing:

• a pendingRefundToken, which must be returned in the API request;
• the affected orderId;
• refundReason, currently limited to CHARGEBACK with value 7; and
• optional obfuscated account and profile identifiers, when those were supplied at purchase time.

The outer notification also identifies the package and includes an event timestamp. Google warns that Pub/Sub notifications can be delivered more than once and recommends checking messageId uniqueness. Operationally, that means ingestion must be durable and deduplicated before any submission is attempted.

An RTDN is a signal, not a complete purchase record. Google's reference tells developers to call the Google Play Developer API after receiving notifications when complete purchase status is needed. The review packet therefore has to join the notification to your own order, entitlement, and usage history.

2. The developer has 24 hours to respond

For a reviewable chargeback, Google says to evaluate the request and call orders.reviewrefund within 24 hours of receiving the notification. The request requires:

• the pending refund token;
• whether a free sample, trial, or functionality information was provided before purchase; and
• a preference of APPROVE, DECLINE, or NEUTRAL.

Developers can optionally add an in-app consumption percentage and up to 1,000 usage events. An event can carry obfuscated account or profile identifiers, a consumption timestamp, the IP address used, a description of what was consumed, and coarse location. Google describes these fields as information for consideration, not as a checklist that guarantees a successful dispute.

The endpoint requires the androidpublisher OAuth scope. A successful request returns an empty body.

3. The first call is the only call that counts

This is the most important technical constraint. Google records the first API call for a notification and ignores later calls while still returning an OK status.

You cannot submit a placeholder to stop the clock and append better evidence later. You also cannot use a second successful response as proof that Google replaced the first packet. The initial submission needs the intended refund preference and the best evidence available at that moment.

This creates an awkward failure mode for home-grown integrations: if the network fails after Google receives the request but before your system receives the response, a blind retry can return OK without telling you which call Google recorded. The official documentation does not provide a read endpoint for the recorded packet. Submission state, idempotency, and ambiguous outcomes therefore need deliberate handling.

What the evidence can—and cannot—do

The API does not transfer the bank dispute to the developer. You are providing a recommendation and factual purchase-usage evidence to Google Play. Google says it considers those signals so it can better identify and contest illegitimate chargebacks on your behalf.

That distinction prevents three common overclaims:

• DECLINE does not mean the refund is automatically denied.
• A complete evidence packet does not guarantee that the chargeback is won.
• HTTP success means Google accepted the API call; it does not report the financial institution's outcome.

For downstream reconciliation, the existing Voided Purchases API lists purchases that were canceled, refunded, or charged back. Its records include the order ID, void time, source, and reason; reason 7 is Chargeback. That gives operators a factual chargeback count, but it is a separate surface from the empty Review Refund response.

The operational interpretation

The endpoint itself is small. Running it reliably is the larger job.

This is operational interpretation, not additional Google policy. Google does not prescribe your queue, database, alert thresholds, evidence-retention period, or approval workflow. It does, however, publish constraints that make those controls rational.

Evidence quality starts before a dispute exists. Delivery events, item consumption, session activity, timestamps, and stable obfuscated identifiers are much harder to reconstruct accurately under a 24-hour clock. Collect only data you have a legitimate reason to process, retain it under your privacy and security rules, and never fill missing fields with inference. A smaller factual packet beats a richer fictional one.

Your refund preference also needs policy behind it. APPROVE, DECLINE, and NEUTRAL are operational choices, not sentiment. Define which facts drive each outcome, who can override automation, and what happens when evidence is incomplete. Otherwise the integration merely converts an ad hoc manual decision into an ad hoc automated one.

What remains uncertain

As of this writing, Google's public documentation does not specify:

• the amount or currency of financial-institution chargeback fees;
• which chargebacks will be selected for developer review;
• review coverage by country, payment method, or product edge case;
• the exact timezone interpretation of the August 3 order cutoff;
• how Google weights each evidence field;
• expected win rates or any guaranteed financial outcome; or
• a response that directly reports the eventual chargeback decision.

Those are genuine unknowns, not details to solve with confident wording. Build reporting so fee assumptions are explicit and replaceable. Keep policy logic configurable. Watch Google's policy notice, API guide, and release notes for changes rather than treating the July documentation as permanent protocol law.

What to do first

Start with measurement, not automation.

1. Count actual chargebacks separately from refunds. Use voided-purchase reasons and order IDs, not a blended “refund” metric.
2. Measure the cost from your own records. Keep purchase value, Play service fee, and financial-institution fee as separate fields.
3. Verify RTDN delivery. A perfect Review Refund client is useless if pending-review notifications do not reach it reliably.
4. Map available evidence to Google's schema. Identify what is captured now, what can be linked to an order, and what is legitimately absent.
5. Design for the first-call rule. Validate completeness, prevent concurrent submissions, and make ambiguous provider responses visible to an operator.
6. Separate confirmed policy from assumptions. Especially in forecasts presented to finance or leadership.

The August 3 change makes chargebacks a clearer developer P&L line. The Review Refund API creates a useful way to influence some of those cases, but only if notification delivery, evidence capture, decision policy, and one-shot submission all work as one system. Before designing that system, establish the number it is supposed to improve.