It’s hard to know exactly how big the chargeback problem is, but we can make reasonable assumptions to estimate the impact of refunds on IAP revenue. Let’s consider the following factors.

‍

How much revenue do Android apps make?

In 2025, Android apps earned $49.2B on Google Play, according to multiple sources tracking revenue from the publisher side.

‍

The exact breakdown between subscriptions, app purchases, and in-app purchases is a bit fuzzy. Here’s what we know, according to Business of Apps’ synthesis of data from Sensor Tower and Appfigures.^,

• $49.2B Google Play revenue 
  
  • $21.1B subscription app revenue
  • $19.2B “app revenue” (let’s read this as IAP)
  • $8.9B unspecified (let’s read this as buying an app outright)

Side note: How much revenue did Google Play make last year?

^{Google’s parent company, Alphabet, does not disclose Google Play revenue. The latest-available data from Alphabet’s 2025 financial disclosures shows about $116B in “Services,” which includes its entire advertising business, YouTube, Google Play, and Google One (among others). This is not particularly useful for figuring out the impact of chargebacks on app revenue; it’s why we have to rely on revenue data from the publishers.}

‍

Fraud blocked by Google Play

Remember how Google Play blocked $3.4B in fraud/abuse in 2025? We can’t know exactly how much of it came from disputing chargebacks, but we can add it to Google Play’s $49.2B revenue to get a fuller picture of the impact of fraud on app revenue. 

‍

Now we’re talking about $52.6B. Google was effectively blocking 6% of transactions due to fraud and abuse. That means developers and publishers need to make plans on how to prevent fraudulent transactions from now on.

/vide

Short answer: a lot more than the refund itself.

‍

A single disputed $10 purchase quickly balloons to a $35 loss for the developer: 

• $10 purchase price
• $25 card-network dispute fee (charged win or lose)

‍

A mid-size app absorbing 100 of these chargebacks a month is out about $3,500 monthly, or $42,000 annually. That doesn’t even account for the hours of your team’s time or the risk to your dispute ratio with card networks and payment service providers.
‍

What is a good dispute ratio?

Your dispute ratio counts total chargeback volume regardless of outcome, and it does more damage than any single dispute. The magic number to stay below is 0.9% to stay out of monitoring programs.
‍

If your dispute ratio gets too high, you'll end up in a card network's monitoring program, which may escalate to monthly fines, forced remediation plans, and losing access to card processing. A publisher can fight every chargeback, win half, and drift past 0.9% anyway.

^{TL;DR: First-party fraud is the cardholder disputing a purchase they made and used themselves. Third-party fraud is a purchase the cardholder never made, on stolen card details or a compromised account. The first gets contested with evidence; the second must be blocked before the charge exists.}

First-party fraud definition

Also known as “friendly fraud,” first-party fraud is the cardholder's own doing. Let’s say someone bought in-app currency for a puzzle game. They paid for 100 gems, cashed them in for 5 extra lives, but still told their bank the charge was unauthorized. 

What causes first-party fraud? 

Sometimes it's just good old buyer’s remorse. It could also be a clever kid bypassing a device’s parental controls to use a saved payment method. Or it might be deliberate: consume the purchase, dispute the purchase, keep both. In digital goods and gaming, some estimates peg friendly fraud at roughly 70% of all disputes. For ecommerce, first-party fraud can also be “digital shoplifting,” where the buyer keeps the sneakers and disputes the charge. 

‍

Third-party fraud definition

Third-party fraud means someone else made the purchase: stolen card details, a hijacked account, or an account its real owner rented out for a cut. When the bank statement arrives, the cardholder disputes (as they should).

What this means for app developers

For in-app purchases, the issuing bank might view first-party and third-party fraud the same way: a cardholder says a charge is invalid, and banks tend to believe their cardholders. 

‍

Telling the friendly fraud vs. nefarious fraud is your job, and it splits your defense. First-party disputes get contested with evidence that the account holder received and consumed the purchase post-transaction. And repeat abusers should be blocked and prevented from returning. Third-party fraud must be blocked upstream, because your "evidence" would simply document a fraudster enjoying the purchase.

Special considerations: Chargebacks for offers and rewards

Rewarded apps carry double exposure. The fraudster extracts your reward payout. You face chargebacks from in-app purchases along the way to rewards or offers. Google used to cover that second loss. As of August 3, you lose on both fronts.

‍

When a chargeback needs your input, Google Play sends a PendingRefundReviewNotification through Real-time Developer Notifications. You have 24 hours to respond by calling orders.reviewrefund with your decision and evidence. Only your first submission counts. There's no edit and no appeal.

‍

Your one call sets the refundPreference field and attaches a case file. You declare your preferred course of action as Approve, Decline, or Neutral.

The Review Refund API case file supports your choice:

• sampleContentProvided: whether the buyer saw a trial, sample, or clear product description before paying.
• consumptionPercentageMilliunits: how much of the purchase was used. A refund request on a fully consumed gem pack gives you an edge in the dispute.
• consumptionUsageEvents: up to 1,000 events with timestamps, IPs, coarse location, and descriptions. Only send your strongest events; longer lists are rejected.

‍

Google carries this file to the bank or card network when it contests the chargeback on your behalf. 

‍

A word of warning: everything in the file must exist before the dispute does. If your backend doesn't log per-order delivery and consumption today, the notification will arrive, you'll query your database, and the database will shrug. 24 hours is enough time to pull records that already exist.

‍

(Engineering details, including Pub/Sub delivery, deduplication, and refund-reason filtering, are in Google's RTDN and orders.reviewrefund reference docs.)

How to prevent chargebacks for in-app purchases

With chargebacks, prevention is the cure. For in-app purchases, avoiding costly refunds requires a two-pronged approach: 

‍

For first-party fraud, proactively gather your evidence before you need it.

• Log delivery and consumption per order: timestamps, IPs, coarse location, and what the user did with the purchase.
• Auto-trigger an internal workflow whenever Real-time Developer Notifications issues a PendingRefundReviewNotification. Make sure you have a named owner who can respond within 24 hours. (Sadly, disputes don't respect weekends.)
• Set decision rules in advance: know which disputes auto-approve, which you fight, and what evidence attaches automatically. You’ll need to consider your margins and user LTV. For example:
  
  • A $2 dispute from a high-LTV user likely isn’t worth the headache or damage to your ratio.
  • A $20 chargeback from a user who just signed up and definitely consumed all the in-app purchases should be an easy win (assuming you’ve captured the evidence ahead of time).
• Block repeat offenders: Block users with negative LTV or frequent chargebacks; make sure to use a system to prevent them from coming back with a new account on the same device. 

For third-party fraud, you can block it at multiple checkpoints.
‍

1. Signup. Multi-accounters share device and network signals with accounts you've already banned. Catch duplicate accounts at registration and the scheme stops. Why? Our data from > 2 billion users/year shows that, in most instances, 80-90% of all chargebacks are committed by just a few users. In an extreme case, one device accounted for >50% of $900K chargebacks in a single month.
2. Login. Account takeovers (ATOs) from hijacked or rented accounts show fresh device and network signals on aged credentials. That mismatch is visible at authentication, long before any refund request.‍
3. Purchases. Invisibly validate device, network, location, and app install validity before letting users make in-app purchases. While it might feel weird declining money, it will save you in the long run.‍
4. Payout. Add a final risk check before gift cards or cash go out. Hold, step up, or review suspicious cash-outs. If needed, block the payout. Fraudsters assess ROI faster than most startups. If your app is no longer paying out a profit, they’ll move on to an easier target.

Before any of the above: baseline your dispute rate this week. Pull chargeback counts from the Play Console, divide by transactions, and find out how far you sit from a 0.9% dispute ratio. How aggressively to fight, how much to invest in prevention, which users need friction: all of it depends on how close that number is to 0.9%.

We’re here to help

As with any major policy change rollout, we can assume some bumps in the road for app developers and publishers. While everyone’s figuring out their workflows around the Review Refund API, it’s prime time to get ahead of chargebacks altogether. 

‍

Verisoul evaluates risk in real time across the user journey to protect apps against multi-accounting, ATO, automated behavior, and fraudster payouts. We've helped companies like

Interested in how to keep app chargebacks low with device, network, and behavioral signals? Let’s talk.