The 7-day pre-flight checklist for Aug 3

Google's official notice says developers will be responsible for the purchase price less Play's service fee, plus associated chargeback fees from the financial institution. Google will continue to cover its service fee. The change applies to orders placed after August 3—not chargebacks opened after that date.

Google also introduced an optional review flow. When a chargeback requires developer review, Play sends a PendingRefundReviewNotification; the developer can provide a refund preference and relevant usage evidence through the Review Refund API. Google's implementation guide gives that response a 24-hour window and says only the first API call is recorded.

1. Put one person on the hook

Owner: A payments-operations or product-operations lead, with a named backup.

Start with an ownership sheet, not an architecture diagram. List every Play developer account, package name, billing backend, Pub/Sub project, support queue, and finance contact in scope. Name the person who watches pending reviews, the person allowed to choose APPROVE, DECLINE, or NEUTRAL, and the person who reconciles the eventual cost.

Record the handoffs explicitly. Engineering owns reliable delivery and evidence retrieval. Operations owns the response clock and decision. Support owns customer communication. Finance owns the ledger. If legal or privacy approval is required for new evidence fields, name that reviewer now rather than discovering the dependency during an incident.

Do not invent an exact midnight cutover: Google's notice does not publish a timezone for the August 3 boundary. Preserve the original order timestamp and flag boundary cases for separate review.

Pass: A primary and backup can take a sample order from notification to decision, customer action, and ledger entry without asking who has authority.

Fail: Responsibility sits in a shared channel, only one person has Play access, or no one owns nights and weekends.

This week: Build the inventory, verify console and cloud permissions, publish the rota, and run one 30-minute handoff exercise.

2. Prove that evidence can be joined to an order

Owner: Backend engineering, supported by data or analytics.

The review endpoint accepts facts tied to one order: whether a sample, trial, or functionality information was provided; a refund preference; optional consumption percentage; and up to 1,000 usage events. Those events can include obfuscated account or profile identifiers, timestamps, IP addresses, descriptions, and coarse location. Optional does not mean “fill it if you can guess.” Send only accurate data you legitimately collect and are permitted to process.

Map the chain from Play order ID and purchase token to your internal account, product, entitlement delivery, and subsequent consumption. Check whether obfuscatedAccountId and obfuscatedProfileId are supplied consistently at purchase time. For each evidence field, document its source, timestamp semantics, retention period, and what “missing” means.

Sample real records across one-time products and subscriptions. A polished event warehouse is irrelevant if an operator cannot retrieve a specific order's delivery and usage history inside the response window.

Pass: For 20 sampled orders, an engineer can produce a factual, timestamped packet and explain every field's source. Missing evidence is explicit rather than inferred.

Fail: Usage exists only as aggregate analytics, identifiers cannot join purchase and account records, or delivery state depends on client logs that have already expired.

This week: Define the evidence schema, repair the highest-value join, add server-side capture for future purchases where feasible, and document the remaining gaps. Do not attempt a wholesale analytics rebuild.

3. Separate chargebacks from the rest of “refunds”

Owner: Finance or data, with payments operations reviewing classifications.

The Voided Purchases API includes cancellations, refunds, and chargebacks. A useful baseline must separate void reason 7 (Chargeback) from other voids and retain both purchase time and void time. Include subscriptions by requesting the appropriate purchase type, paginate every response, and respect the API's retrieval window and quotas.

Create an order-level ledger with at least: package, order ID, purchase timestamp, void timestamp, currency, gross purchase value, Play service fee, financial-institution fee, void source, void reason, expected developer liability, and actual settlement amount. Keep unknown fees unknown. Google has not published one universal financial-institution chargeback fee, so a made-up flat rate will contaminate the forecast.

Reconcile the ledger against Play financial reports or payout records. Differences are findings: timing, currency conversion, missing orders, partial refunds, or classification errors should not be silently netted away.

Pass: Finance can state the chargeback count and value separately from developer refunds and Google-issued refunds, with a traceable order list and documented unknowns.

Fail: The only metric is a blended refund rate, totals cannot be traced to orders, or estimates are presented as settled costs.

This week: Backfill the data currently available, reconcile one reporting period, and schedule a daily incremental import. Historical perfection can wait; repeatable classification cannot.

4. Test notification delivery and the 24-hour clock

Owner: SRE or platform engineering; payments operations owns escalation.

A reviewable chargeback begins with a Real-time Developer Notification delivered through Cloud Pub/Sub. The notification carries the order ID and pending refund token needed for the API call. Treat receipt as a durable queue event, not a log line.

Verify the Play topic, Pub/Sub subscription, push authentication or pull worker, dead-letter behavior, and production package routing. Deduplicate by Pub/Sub messageId, while retaining the original payload and receipt time. Monitor oldest-unhandled age, delivery errors, dead-letter count, and the absence of expected worker heartbeats.

Set internal alerts early enough for humans to recover before Google's 24-hour deadline. The exact thresholds should match staffing and volume; one reasonable starting ladder is an operations notification at 15 minutes, escalation at one hour, and an incident page well before the final six hours. These are internal controls, not Google policy.

Pass: A test notification reaches the production consumer, appears in the operations queue, survives a duplicate delivery, and triggers both primary and backup alerts in a controlled drill.

Fail: Success means “Pub/Sub says delivered,” the oldest case age is invisible, or the alert reaches only the engineer who built the consumer.

This week: Instrument and drill the path. A Play Console test notification proves connectivity, not that your pending-review parser is correct, so separately exercise that parser with a versioned fixture.

5. Write the one-shot response runbook

Owner: Risk or payments operations, approved by whoever owns refund policy.

Google offers three preferences: APPROVE, DECLINE, and NEUTRAL. Define the facts that justify each one. For example, your table may consider verified delivery, meaningful consumption, account compromise signals, prior support contact, an already-issued refund, or insufficient evidence. The table should produce consistent recommendations without pretending to dictate Google's final decision.

The runbook must respect the dangerous API mechanic: Google records the first call for a notification and ignores later calls while still returning OK. There is no harmless placeholder submission. Require packet validation, decision approval, and a concurrency guard before the call. Record exactly what was sent, by whom, and when. Treat a timeout after submission as ambiguous; a later OK does not prove that Google replaced the first packet.

Include a manual path for incomplete evidence, unavailable systems, and cases nearing the deadline. NEUTRAL is a valid preference when policy does not support a stronger recommendation.

Pass: Two trained operators reach the same disposition on three tabletop cases, and the system prevents concurrent first submissions.

Fail: Operators “use judgment” without criteria, retries are assumed to update evidence, or HTTP success is recorded as a won chargeback.

This week: Approve a one-page decision table, add a pre-submit checklist, define ambiguous-outcome handling, and run approve, decline, and neutral scenarios end to end.

6. Align support, refunds, and entitlement actions

Owner: Support lead, with product and finance sign-off.

Google's order-management guidance says developers are responsible for their own refund policies, user notification, and legal compliance. A direct support refund, subscription cancellation, refund-and-revoke action, and bank chargeback are different events. Your queue and customer language should preserve those distinctions.

Give support a macro that requests the minimum identifiers needed to find an order, explains the published refund path, and routes suspected account compromise appropriately. Define when support may refund directly, who approves exceptions, and how that decision updates entitlements and finance. Remember that canceling a subscription does not itself issue a refund, while a completed refund cannot be reversed.

Coordinate revocation carefully. The Voided Purchases API is a signal for orders that need revocation, but Google recommends uniform, transparent policies and fair ways for users to contest an action. Do not bolt an automatic account ban onto every void reason.

Pass: A sampled refund ticket produces one consistent customer answer, one recorded financial action, and the intended entitlement state. Support can identify an existing chargeback before issuing a conflicting action.

Fail: Support, billing, and the game or app can each change the order independently, or users receive contradictory refund and access messages.

This week: Update macros and escalation rules, document refund-versus-cancel-versus-revoke behavior, and walk five recent tickets through the new procedure.

7. Measure exposure before buying automation

Owner: Operations and finance together.

The final control is a baseline both teams trust. You can build the import yourself, use existing data tooling, or run Dispute.app's free read-only audit to classify Google Play voided purchases and expose the current chargeback denominator. The useful output is not a readiness badge. It is an order-level count and value, the period covered, and an explicit list of missing data.

Do not use a tool to paper over failed controls above. Measurement cannot assign an incident owner, recover events you never captured, or approve your refund policy. Likewise, a Review Refund integration should not be switched on merely because the endpoint exists. Operate manually first if that is the safer path, then automate the stable parts.

Pass: Operations and finance sign off on the same baseline, can trace it to source orders, and know which costs remain unavailable until settlement data arrives.

Fail: A dashboard blends all voids, hides its retrieval window, or turns estimated savings into booked results.

This week: Produce the baseline, save the query or audit artifact, nominate a weekly reviewer, and set the first post-cutover comparison date.

Seven days will not eliminate chargebacks. It can eliminate ambiguity about who acts, what evidence exists, whether the clock is running, and what the event cost. That is the useful pre-flight standard for August 3.