The real cost of a disputed $9.99 IAP after Aug 3

What Google has actually said

Google's chargeback cost-responsibility policy applies to orders placed after August 3, 2026. When a chargeback occurs, Google assigns developers two items:

• the purchase price, less Play's service fee; and
• the associated chargeback fee from the financial institution.

Google says it will cover the service-fee cost for the transaction. That is the known policy. It does not publish a universal dollar amount for the financial-institution fee, and the article does not assume one exists.

This is also narrower than “every refund costs this much.” A chargeback is a cardholder dispute initiated through a financial institution. A normal refund follows a different path. The cost-sharing announcement concerns chargebacks.

There is a second detail worth keeping separate. Google's 2026 fee schedule distinguishes the service fee from an additional billing fee. For Google Play Billing transactions in the US, UK, and EEA, that billing fee is 5%. Google's chargeback page says Google covers the “service fee”; it does not say in that article whether the separately named billing fee is also credited or covered.

The worked example below uses the conservative interpretation that “service fee” excludes the 5% billing fee. The two cited pages do not confirm that mapping, so the alternate result is shown too. The safest operating approach is transaction-level reconciliation: use the service fee attached to the order and verify the resulting adjustment in Play's financial reporting. Do not hard-code a single net percentage across regions, install cohorts, programs, recurring products, and billing paths.

A worked $9.99 example

We need explicit assumptions before touching a calculator. This example assumes:

• the $9.99 price is the fee basis, with taxes and foreign exchange ignored;
• a non-recurring IAP using Google Play Billing in the US, UK, or EEA;
• eligibility for the first-$1M annual-earnings rate: 10% service fee;
• the separately published 5% Google Play Billing fee;
• the conservative assumption that the separate billing fee is not credited after the chargeback;
• per-component rounding to the nearest cent: $0.999 to $1.00 and $0.4995 to $0.50;
• a hypothetical $15 financial-institution fee—not a Google quote;
• 12 minutes of handling time at a hypothetical $60 loaded hourly rate; and
• $0.40 of marginal cost for value already consumed or delivered.

Google's fee table makes the 10% service fee and 5% billing fee official inputs for this particular scenario. Eligibility and rollout vary. The $15 bank fee, labor rate, handling time, and consumed-value cost are deliberately visible assumptions that you should replace.

Step 1: The original sale

The illustrative order starts like this:

• Customer price: $9.99
• 10% service fee: $1.00
• 5% billing fee: $0.50
• Initial developer proceeds before tax adjustments: $8.49

That $8.49 is what the order initially contributes to cash before the app's own delivery costs. It is not the amount the chargeback policy says the developer owes.

Step 2: The chargeback settlement debit

Under the conservative reading, the developer owes the purchase price less the 10% service fee, plus the financial institution's chargeback fee:

$9.99 - $1.00 + $15.00 = $23.99

The modeled settlement debit is therefore $23.99. It is larger than both the sticker price and the original $8.49 proceeds because the hypothetical bank fee is added, while the separate $0.50 billing fee was already deducted from the sale.

If Google's settlement instead credits the billing fee or treats it as part of the covered fee, the debit would be $23.49. The policy pages do not resolve that $0.50 difference; an actual post-policy financial report must.

Step 3: The final position on the order

Separating the original proceeds from the chargeback debit, even if a statement presents them in one settlement period, the order's cash position becomes:

$8.49 - $23.99 = -$15.50

Add the modeled $0.40 consumed-value cost and $12.00 of handling labor:

-$15.50 - $0.40 - $12.00 = -$27.90

So -$27.90 is the conservative modeled final contribution of this case relative to never having made the sale. Compared with a clean order that would have contributed $8.09 after the same $0.40 delivery cost, the disputed case is $35.99 worse. If the billing fee is credited, those figures improve by $0.50 to -$27.40 and $35.49.

Put another way: $23.99 is the gross settlement debit, -$15.50 is the transaction cash position before labor and consumed cost, and $35.99 is the contribution swing versus a clean order. They answer different questions.

Those are three different numbers with different meanings:

This is the shareable table, but it is not a rate card. Replace every scenario-dependent input before using it in a forecast.

Why the service-fee rate still matters

At first glance, a higher service fee appears to reduce the developer's chargeback debit because Google covers that fee. That is true for the settlement line: if the applicable service fee were 20% instead of 10%, the purchase-price component would be $7.99 rather than $8.99.

But the original clean-order proceeds would also have been lower. With the same 5% billing fee, a 20% service fee leaves $7.49 rather than $8.49 before other adjustments. Looking only at the later debit hides the revenue that was available to lose.

A compact model helps:

• P = purchase-price basis
• s = applicable Play service-fee rate
• b = separate billing-fee rate
• F = financial-institution chargeback fee
• L = incremental handling labor
• C = marginal consumed-value or delivery cost

Under the conservative billing-fee interpretation and the assumptions above:

• Initial proceeds: P × (1 - s - b)
• Chargeback debit: P × (1 - s) + F
• Final case contribution: -(P × b) - F - L - C

The service fee cancels from the final case contribution because Google covers it, while it remains relevant to the size of the clean order you no longer retain. Taxes, fee bases, rounding, alternative billing, and later credits can change actual reporting, so reconcile this model against Play's statements rather than treating the formula as a ledger specification.

The bank fee is the biggest unknown in the simple model

Google calls it the “associated chargeback fees from the financial institution” but does not publish a standard amount on the policy page. That fee may vary by institution, market, payment method, currency, or commercial arrangement. Until your statements contain enough post-policy cases, any fixed value is a planning scenario.

For the same $9.99 example, holding all other assumptions constant:

This range is useful for cash planning, not for claiming the fee will be $15 or $25. Finance should record the actual adjustment by order, currency, institution where available, and outcome. After a few reporting cycles, replace the placeholder with your own distribution—not merely an average that conceals expensive tails.

Google says orders processed, refunded, or charged back during a month are reflected in the payout around the 15th of the following month in its order processing and payouts documentation. That creates a timing issue as well as a unit-economics issue: a cohort can book revenue before its dispute adjustment reaches the payout.

The 24-hour response is an operating cost

For chargebacks that require developer review, Google sends a PendingRefundReviewNotification. Its developer guidance says to evaluate the request and call the Review Refund API within 24 hours. Treat the first submission as final: Google records the first call and ignores later calls, even though they still return an OK status.

That turns each eligible case into a small, deadline-bound production workflow:

1. Receive and deduplicate the notification.
2. Resolve the package, order, account, and entitlement.
3. Determine whether a sample or trial was available.
4. Reconstruct delivery and consumption from retained records.
5. Choose APPROVE, DECLINE, or NEUTRAL under a consistent policy.
6. Validate and submit once, then retain an audit trail.

The Review Refund API reference accepts consumption percentage and up to 1,000 usage events. Events can include consumption time, IP address, an obfuscated account or profile ID, an item description, and coarse location. These are not fields a support agent should improvise from memory at hour 23. Useful evidence has to be captured when the purchase is delivered and retained long enough to answer later.

The API is optional, and a submission is an input to Google's process—not a guaranteed win. A realistic expected-cost model therefore needs your eligible-case rate, response rate, outcome rate, and cost per response. Until you have outcome data under the new policy, model ranges rather than assigning a universal recovery percentage.

Turn the arithmetic into an operating metric

For a portfolio, multiply case economics by volume, but preserve the components:

monthly dispute burden = purchase-component debits + bank fees + handling labor + dispute-specific delivery loss - later credits

Track at least price, currency, product type, service-fee cohort, billing path, bank-fee adjustment, response status, handling time, evidence completeness, decision, and final financial outcome. Keep refunds separate from chargebacks. Keep submitted cases separate from eligible cases. Keep gross avoided debits separate from actual retained revenue.

The commercial decision then becomes ordinary operations math. If reliable notification handling, evidence retrieval, policy application, and one-shot submission cost more to build and run than the expected downside they prevent, buying the workflow is rational. If your volume is tiny and the evidence is already durable, an internal process may be enough. The answer should come from your own twelve months of orders, not a generic scare number.

Replace the assumptions with your numbers

The example above exposes the variables; it cannot supply your service-fee mix, actual chargeback adjustments, consumed value, or case volume. A historical audit can.