A 24-Hour Chargeback Evidence Inbox Opens for Small Apps

Payment records alone are no longer enough

On July 6, 2026, Google introduced chargeback review notifications and a submission feature called ReviewRefund. A chargeback is when a customer asks their card issuer or bank—not the app company—to reverse a payment. This does not apply to every chargeback, only to cases Google decides need review by the app operator.

Review requests arrive as notifications that Google sends directly to the app’s operating system. From the time the notification arrives, the operator has 24 hours to submit its view on the refund and evidence of the customer’s purchase and use. This is a literal 24-hour window, not a business-day deadline that excludes weekends or public holidays.

There is effectively one chance to submit. Google records only the first submission. A revised submission may still receive a success response, but the changes will not be reflected. That makes it as important to know who performs the final check immediately before sending as it is to submit before the deadline.

The format of eligible evidence is also specific. It can include whether a free trial was offered, the percentage of the full product that was used, times of use, an obfuscated account number, an access address, an approximate location, and a description of what was used. You can submit up to 1,000 usage events and up to 5,000 characters of description. A usage rate of 45.2%, for example, is entered as 45200.

The cost rules have changed as well. Google says that, when a chargeback for an order created on or after August 3, 2026 is finalized, the app operator bears the sale amount minus the Google Play service fee, as well as the financial institution’s chargeback fee. The chargeback fee in KRW has not been disclosed, but missing a deadline or failing to provide evidence of use can now create a direct loss, not merely an operational mistake.

For a learning app with twelve employees

Imagine an English-learning app company with twelve employees, where one person handles both customer inquiries and payments. To review one chargeback, that person must find the order number in Google’s order screen, confirm the account in member records, find completed lessons in learning records, and check the customer support inbox for a refund request.

The information sits in four separate places. The operator copies and pastes order and member numbers, aligns dates in chronological order, then decides whether to support or oppose the refund. Previously, small apps had to repeat this work for every case, so building a dedicated chargeback-response system could easily cost more than it was worth.

Now, when a notification arrives, they can create a review inbox that shows the case number and the 24-hour countdown. Using the order number, it pulls in payment, login, lesson-start and lesson-completion, free-trial, and customer-inquiry records, then joins them into a single timeline. Instead of moving across four screens, the operator checks only the missing records on one screen.

The evidence package can also be prepared in a fixed format. If a customer completed 12 of 20 lessons, for example, the operator can submit a 60% usage rate with the basis for that calculation, plus the times of the first and last lesson use. Rather than sending more than 1,000 records, the team can create rules for selecting the key records that demonstrate actual use after payment.

The person in charge then chooses one of three options: support a full refund, oppose it, or defer judgment. Before the send button becomes available, the system can require confirmation that the order number is correct, that the usage-rate calculation has support, and that no more personal information than necessary has been included. Because only the first submission counts, this final review screen becomes a small product in its own right.

This reduces the cost of rebuilding materials for every case, but it does not eliminate the initial integration work. If the app has not recorded lesson completion, item consumption, or paid-feature use, a submission tool cannot generate evidence from nothing. The operator must first decide with its development team which actions to record and from when.

Human judgment remains necessary. The actual user and the person who paid may differ in cases such as account takeover or family payments, and some cases involve failure to provide a core feature because of an outage. Since Google may change its fields or deadlines, it is safer to retain the original usage records unchanged and manage the rules that convert them into Google’s submission format separately.

Elsewhere, platforms are reducing response work

When reviewing App Store refunds, Apple asks developers for information about use of purchased content. Developers submit usage levels and their position on the refund. In Apple’s test environment, they can reproduce a flow that responds within five minutes of receiving a request and offers a proportional 50% refund for some products.

This means that other app marketplaces already use actual usage information, rather than payment receipts alone, in platform decisions. But test results do not guarantee the same result in a real refund decision.

Shopify Protect, from Canadian company Shopify, takes another route for online sellers using its payments service in the United States. If sellers ship an order marked as protected through an approved carrier within seven days and submit the tracking number, Shopify handles the response work and costs for unauthorized-payment or fraudulent chargebacks.

There is no extra fee for protected orders, but disputes over non-delivery, defects, or items not matching their description are excluded. Rather than selling an evidence-submission tool, the platform takes on the response work and losses for cases that meet its conditions.

The Beard Club, a subscription-delivery business that used chargeback-response service Chargeflow, automatically collected order history, subscription-renewal materials, and customer documents for submission. According to a case study published by Chargeflow, manual work fell from about 40 hours a week to roughly one hour of high-level review, a 97.5% reduction, while the recovery rate increased by 42.3%.

These are figures published by the service provider, not independently verified results. Still, they show the scale of the cost: work that previously consumed one person’s time each week can be reduced to reviewing exceptional cases. A Google Play-specific service can aim for savings in the same direction if evidence is already being recorded.

Four things you could build from this

1. A 24-hour chargeback review inbox

This service creates a case when it receives a Google notification and displays the owner and time remaining. It is for small app studios where one or two operators handle payment inquiries across several apps. The new 24-hour deadline and one-submission rule make email or a calendar difficult to manage on their own. The first screen shows the order number, the received time in Korea Standard Time, time remaining, the owner, and evidence-preparation status.

2. A usage-evidence assembler for learning apps

This service joins payment records with lesson-start and lesson-completion records to create a timeline for chargeback submissions. It is for operators of language-learning and certification-preparation apps that convert users from a free trial to a monthly subscription. Google can now accept usage rates and up to 1,000 usage events, creating a reason to convert scattered learning records into a fixed format. The first screen shows the timeline from payment through the last learning activity, any missing account-linking information, and the calculated usage rate.

3. An item-consumption recorder for games

This service defines which actions count as granting and consuming an item, then retains product-specific rules for calculating usage rates. It is for small game companies that sell bundled currencies and limited-time items but do not connect usage records to payment records. Since Google may request a usage rate from 0 to 100%, estimating it arbitrarily after a dispute arises is difficult to defend. The first screen places products on sale, each product’s definition of 100% consumption, and currently recorded actions side by side.

4. A post-chargeback entitlement-revocation ledger

This service finds orders with finalized dispute outcomes and verifies that subscriptions, paid features, and remaining items have been properly revoked. It is for content-app operators that sell subscriptions alongside one-time digital products. The process of submitting evidence to Google and the process of cleaning up entitlements after a final refund move separately, so a product can remain available even after the response work is complete. The first screen shows finalized chargeback orders, entitlements to revoke, processing status, and the owner.

Review one recent payment today

Choose one recent payment and write its sequence from the order number to actual feature use within 30 minutes. If you must move among three or more places for payment, member, usage, and customer-inquiry records—or cannot produce one timeline within 30 minutes—it may be worth building an evidence review inbox or assembler. If you can already verify everything immediately on one screen, it is better to add a 24-hour alert and final-submission check than to build a new tool.

Why this matters where you are

Check whether the payment platforms you use request evidence of actual use, rather than payment records alone, and what their submission deadlines allow. The platforms, dispute rules, and who bears the costs may differ in your market. If your records are scattered today, map one disputed payment into a single timeline before deciding whether to build a dedicated workflow.