Why you lose disputes you should win

That gap is rarely caused by negligence. Most product systems are designed to fulfill purchases, measure engagement, and help customers. They are not designed to preserve a compact, reviewable history of one transaction. The dispute merely exposes the seam between those systems.

The practical lesson is simple: a dispute response is assembled after the dispute, but its important facts must be recorded before it.

The dispute is the last event, not the first

Google Play's new response flow makes the timing unusually clear. When a chargeback needs developer review, Play sends a PendingRefundReviewNotification. Its official guidance says to respond within 24 hours with a refund preference and relevant purchase-usage evidence. It also says Play records the first API call for that notification and ignores later calls—even while returning OK.

So the 24-hour window is not really an evidence-collection window. It is an evidence-selection window. There is time to inspect, validate, and submit facts that already exist. There is not time to recreate the user's state at checkout, prove when virtual goods were consumed, or recover a correlation identifier that was never stored.

Apple's terminology and payload differ, but the constraint is similar. Apple asks developers to send consumption information after a CONSUMPTION_REQUEST, within 12 hours and only with valid customer consent. Both platforms are effectively asking a historical question: what had already happened to this purchase before the request arrived?

A useful evidence timeline

A good timeline follows the transaction from intent to outcome. It does not begin with the dispute notification.

The rows will not look identical for every product. A subscription service may record successful sign-ins and feature access. A game may record currency grants and spends. A streaming app may record content starts and watch duration. The test is not whether the event name sounds persuasive. It is whether it describes a real product action, from an authoritative system, and joins back to the purchase under review.

What good context actually looks like

More telemetry is not automatically better evidence. A giant event warehouse can still produce a weak response if the relevant events are ambiguous, mutable, or impossible to connect to an order.

It is joined to the transaction

An account ID in one database and an order ID in another are only useful if the relationship between them is explicit. Google Play's ConsumptionUsageEvent supports obfuscated account and profile identifiers for this purpose. They provide continuity without requiring a raw email address or display name in every event.

Choose one durable join path: order to purchase token, purchase token to internal account, and account to fulfillment and usage. Test it with real historical orders. A correlation strategy that works only while a user is logged in or while a cache entry survives is not a strategy.

It separates delivery from consumption

“Purchase successful” proves less than teams often assume. It may show that the store charged the customer and your app acknowledged the transaction. It does not necessarily show that 500 gems reached the player's balance, or that 340 were later spent.

Record delivery and use as separate events. For a digital item, a useful sequence might be: order verified, 500 units granted, 200 units spent on one upgrade, 140 on another. For a subscription, it might be: entitlement activated, account signed in, premium feature used. This creates a factual chain instead of collapsing the whole lifecycle into one boolean.

It preserves event time and receipt time

Event time answers “when did the product action occur?” Receipt time answers “when did the evidence system learn about it?” Keeping both makes delayed batches, retries, clock errors, and suspicious backfills visible.

That distinction matters because a usage event created five minutes after delivery is different from an event claiming old usage but first received after the dispute. The latter may still be operationally useful, but its provenance is weaker and should not be disguised.

It is specific enough to read

“User active” is almost useless. “Premium export completed for project 81 at 14:03 UTC” is legible. “Currency consumed” is vague. “340 of 500 purchased gems spent on Dragon Armor upgrades” explains both the item and the amount.

Descriptions should stay factual and compact. Avoid accusations, conclusions about intent, or prose generated to sound certain. The platform decides the outcome; your job is to make the underlying events understandable.

It preserves the state that existed then

Mutable profiles are dangerous evidence sources. Today's country, subscription tier, balance, or policy acceptance may not match the state at purchase time. Preserve the small transaction-specific snapshot you may need later, including the policy version or sample content shown before purchase. Do not depend on a live profile query to reconstruct old context.

How strong cases become weak packets

Several failure modes appear repeatedly because they are reasonable engineering choices for other goals:

• The receipt is treated as the whole case. It proves a transaction existed, not that the digital value was delivered or used.
• Analytics cannot resolve an order. The events show heavy activity but use device or session identifiers that cannot be joined reliably to the purchase.
• The client is the authority. A modified or offline client can report fulfillment and usage without server confirmation.
• Current state overwrites historical state. The database knows the user's balance now, but not the grants and spends that produced it.
• Logs expire by accident. A 30-day operational-log policy silently removes facts while disputes can still refer to older transactions.
• The event is technically rich but semantically empty. Hundreds of generic session events obscure the two actions that matter.
• The reconstruction begins after the alert. Teams query production, ask support for recollections, and write a narrative that may be true but has no contemporaneous record behind it.

None of these means the underlying customer claim is valid. They mean the response cannot demonstrate why it is not.

Retention and privacy are part of evidence quality

“Keep everything forever” is not a serious answer. It creates privacy risk, access burden, and an eventual pile of data nobody can explain. The better target is minimum sufficient evidence for a defined period.

Start with the platform fields that could be material. Google's API accepts purchase-use timestamps, pseudonymous account/profile IDs, IP addresses, coarse location, a description, and consumption percentage; most are optional. Optional is important. It means you can choose proportionately rather than collecting every possible field for every customer.

Use pseudonymous identifiers where they preserve continuity. Prefer coarse region over precise location. Treat IP addresses as sensitive and retain them only when you have a defined purpose and lawful basis. Keep free-text payloads out of the event path unless they are controlled by your server; otherwise they become an easy place to ingest secrets or unrelated personal data.

Set a documented rolling retention period based on the longest relevant dispute, refund, accounting, and legal window for your business. Automate deletion after that period, with narrow legal-hold exceptions. Restrict access, encrypt stored data, log exports, and make account deletion workflows explicit about transaction records you must retain versus data you can remove.

Consent also belongs in the transaction context, not in a hurried dispute workflow. Apple's rules are direct: consent must be valid, specific, informed, and unambiguous before personal consumption data is shared, and developers should not respond when consent is absent. Whether or not you support Apple, that is a useful design principle: know at collection time what you may store, why, and where it may later be sent.

Build the minimum trail without buying anything

You do not need a dispute platform to fix the foundations. A small append-only table or durable event stream is enough to begin.

1. Make the order ID the primary join key. Map it to the store token and a pseudonymous internal account identifier on your backend.
2. Capture a purchase snapshot. Store the SKU, quantity, app version, sample or trial state, policy version, and relevant consent state as they existed at purchase.
3. Emit server-authoritative lifecycle events. Start with entitlement delivered, item consumed or service accessed, and entitlement revoked. Add custom events only when they explain real value.
4. Keep occurred-at and received-at timestamps. Add an idempotency key so retries do not manufacture duplicate consumption.
5. Make evidence append-only. Corrections should be new events that reference the original, not edits that erase history.
6. Run a retrieval drill. Pick ten old orders and ask one engineer to produce a chronological, human-readable record without querying a client device or asking support what happened.
7. Write the retention rule down. Name the data owner, deletion schedule, access roles, export path, and consent requirement.

Then simulate the notification path. Can the right person or service retrieve the record, choose only relevant events, and submit once before the deadline? The exercise will reveal more than another dashboard of aggregate fraud metrics.

The product thesis, plainly

This is the constraint Dispute.app is built around. Its evidence API accepts server-side delivery, consumption, session, and custom events keyed to an order. Events are append-only; purchase context is a one-shot snapshot. It records the claimed occurrence time alongside server receipt time, then projects supported consumption events onto Google's documented request fields when a case needs a response.

That design cannot recover evidence you never captured, and it should not pretend to. Automation helps with deadlines, selection, formatting, and consistent submission. It cannot turn a post-dispute reconstruction into a contemporaneous event.

The most useful first question is therefore not “What could improve our win rate?” It is “For the orders we would want to defend, can we produce a trustworthy timeline today?” If the answer is no, the next step is instrumentation—not better rebuttal copy.