When Fraud Looks Like Growth: Chargebacks in Digital Goods

There is a dangerous moment in digital commerce when fraud looks exactly like growth.

Sales are increasing. New users are signing up. Transaction volume is climbing, and the revenue chart is moving in the right direction. Everyone is happy. Then, a few weeks later, the chargebacks start arriving.

I have seen this closely in B2C products that sell digital goods such as gift cards and mobile top-ups. This post covers why those products attract fraud, why the internal debate about it is often harder than the fraud itself, the controls we put in place, and the metric I would watch instead of gross revenue.

Why do digital goods attract fraud?

Fraudsters use stolen credit cards or compromised payment accounts to buy something that can be delivered and used almost instantly. That creates an uncomfortable imbalance:

The product is delivered in seconds. The fraud may take weeks to surface.

A fraudster buys a $100 digital product. The payment is authorized, the product is delivered, and your dashboard records $100 in revenue.

Later, the real cardholder disputes the transaction and the money is reversed. By then, the digital product has already been used, transferred or resold.

The lost revenue is only part of the bill. You may also lose the value of the product itself, the payment processing fees, the chargeback fees, and the time your operations and support teams spend on each case.

The risk is highest when a product has three characteristics:

• Instant delivery. The value leaves before any check can catch up.
• Easy transfer or resale. A fraudster can turn it into cash or pass it on.
• Irreversible consumption. Once used, it cannot be taken back.

Gift cards, mobile top-ups, eSIMs, gaming credits and vouchers all fit this description.

When “growth” turns out to be fraud

At a networking session, someone shared an experience with me that sounded very familiar. Their eSIM purchases had been growing fast, and at first the numbers looked great.

Then they investigated. A large share of that activity came from a small group of users. When the chargebacks arrived later, all of that revenue turned into a loss.

I had seen the same pattern with gift cards and mobile top-ups. I have been always cautious and it confirmed:

Revenue is not good revenue until you understand the quality of the transactions behind it.

The internal fight: when your product blocks hundreds of users

The fraud was not always the hardest part. Sometimes explaining it inside the company was harder.

There were uncomfortable days when our security module blocked hundreds of users. From the marketing team’s point of view, this looked terrible. They had spent money and effort bringing traffic to the product. Campaigns were working. People were reaching the website and trying to buy. And then our own software was stopping them.

Their argument was understandable: “We are putting so much effort into bringing these users in, and the product is stopping them from buying.”

As the Product Manager, I had to dig deeper and ask who exactly we were blocking:

• How many cards had each of these users tried?
• How many accounts were coming from the same IP address?
• How quickly were they making purchases?
• Were several accounts sending value to the same recipient?
• Was someone registering and immediately attempting unusually large transactions?
• Did the card country, IP location and account details match?

Once we looked beneath the headline number of “hundreds of blocked users,” the picture changed. Many of them were not customers we had lost. They were transactions we were lucky not to complete.

Marketing, security and finance can all be right

This is where fraud becomes a product management problem rather than only a security problem. Each team is optimizing for a different chain of numbers:

• Marketing: Traffic → Signup → Conversion → Revenue
• Security: Fraud attempts → Block rate → Chargebacks
• Finance: How much money did we actually keep?

All three can look at their own dashboards and reach different conclusions. Weighing those views against each other is part of the job, as I wrote in The Prism of Priorities.

Suppose a campaign produces 10,000 visitors, 1,000 signups and 300 purchases. It looks like a success. Now suppose 120 of those purchases are fraudulent.

Marketing analytics will report strong conversion and revenue at first. Security will report a rise in suspicious transactions. Finance will find the real problem several weeks later, when the chargebacks arrive.

The business needs to connect these views. A more realistic funnel for digital commerce looks like this:

Traffic → Signup → Purchase attempt → Fraud screening → Successful fulfilment → Chargeback window → Realized revenue

That last number matters far more than the revenue shown right after checkout. A top-line number that hides what is really happening is a common trap, and it is the same reason teams often misread a product problem as a marketing problem.

Is every blocked user a lost customer?

No, and the difference matters when you measure conversion.

If 1,000 people reach checkout and 200 are blocked by security controls, counting all 200 as lost conversions is misleading. Checkout outcomes should be split into separate groups:

• blocked by security controls
• payment failed
• abandoned by a legitimate customer
• sent to manual review
• confirmed fraud
• successful

Without that split, the product team may get a request to “improve checkout conversion.” The easiest way to move that number is to weaken the fraud controls. Conversion goes up. Revenue goes up. Everyone celebrates. Three weeks later, chargebacks go up too.

At that point you have optimized the dashboard, not the business.

Not every user you lose is a customer you lost. Sometimes your product is doing exactly what it was designed to do.

The fraud controls we put in place

No single feature solved fraud for us. We added layers.

Third-party fraud detection

We integrated third-party fraud detection instead of relying only on our own rules. The goal was to check more signals about the transaction, the payment method and the user before releasing the digital product.

Stronger payment authentication

We added 3D Secure for credit and debit cards, plus extra authentication around PayPal transactions. Authentication is one layer, though, not the whole fraud strategy.

Purchase limits by IP address

If one IP address suddenly starts buying several gift cards, or topping up many different numbers, it deserves a closer look. We introduced velocity controls based on IP address, number of transactions and time period.

IP limits alone are not enough, because fraudsters can change IP addresses.

Purchase limits by identity

So we also looked at behavior at the account level:

• How many transactions is this user making?
• How much value are they buying?
• How many cards have they tried?
• How many recipients are receiving value?
• How old is the account?

A fraudster can use many IP addresses, so identity and behavior signals need to sit alongside network-level controls.

Transaction limits

A five-minute-old account probably should not be able to buy thousands of dollars’ worth of irreversible digital products straight away. Limits can be based on transaction value, daily value, number of transactions, account age, payment method and previous successful activity. As trust builds, the limits can relax.

Geographic restrictions

We also restricted transactions from countries where fraud exposure was disproportionately high. I consider this a coarse control. Every country has both legitimate customers and fraudsters, so geography should be one signal among many, not the whole decision.

What I would add today

Looking back, these are the signals and controls I would now treat as essential.

• Device fingerprinting. An attacker can change IP addresses more easily than devices. Device signals can link accounts that otherwise look unrelated.
• Card velocity. One card tried across several accounts, devices or recipients in a short period should raise the risk score.
• Recipient velocity. This matters most for gift cards, top-ups and eSIMs. Ten apparently unrelated accounts sending value to the same phone number or email address may be one fraud operation.
• Failed payment patterns. Fraudsters often test several stolen cards before one works. Failed attempts are valuable signals, not only payment errors.
• Risk-based verification. A trusted returning customer buying $10 should not face the same checks as a new account attempting a $500 transaction.
• Delayed fulfilment for risky transactions. Instant delivery can stay the default without every transaction being instant. High-risk orders can go through a short verification step first.
• Account age and reputation. A customer with months of successful transactions should earn trust. A new account has no such history.
• Allow lists as well as block lists. A fraud system should learn who to trust, not only who to block.
• Chargeback evidence. Store transaction, authentication, device, account and fulfilment details. Even when disputes are hard to win, good evidence helps.
• Post-purchase monitoring. Detection should not stop when the payment succeeds. Redemption, activation and transfer behavior can reveal patterns that were invisible at checkout.

Risk-based verification works best as a simple tiered model:

• Low risk: approve
• Medium risk: ask for authentication
• High risk: hold, review manually, or decline

How does fraud differ across B2C, B2B and B2V?

The controls above are shaped by B2C digital goods. The risk changes with the relationship.

B2C: speed is the risk

In B2C digital products, fraud depends on speed. The fraudster wants to turn stolen payment details into usable or resellable value before anyone notices. Common pain points include:

• stolen cards and compromised payment accounts
• card testing
• account takeover
• fake accounts and identities
• unusually high purchase velocity
• many accounts targeting the same recipient
• chargebacks after the product has been consumed
• false positives that block legitimate customers

The Product Manager’s challenge is to stop fraud without ruining checkout for legitimate customers.

B2B: fewer transactions, bigger losses

Instead of hundreds of small fraudulent transactions, one compromised account or fraudulent business order can cause a much larger loss. Risks include compromised corporate accounts, stolen company cards, fraudulent organizations, unauthorized employees, fake purchase orders and manipulated invoices.

Here, company verification, role-based permissions, approval workflows and alerts on unusual purchasing behavior matter more. For some transactions, requiring a second authorized person to approve a payment is worth more than another checkout rule.

B2V: the vendor may be the attack surface

In business-to-vendor relationships, the attacker may not look like a suspicious customer at all. They may look like your supplier. Problems include fake vendors, duplicate or inflated invoices, compromised vendor accounts and requests to change payment details.

Imagine working with the same vendor for two years. One day an email arrives: “We have changed our bank account. Please send all future payments here.” Everything may look legitimate. But any change to financial details should trigger extra verification: confirming the new bank details through an independent channel, approval workflows, duplicate invoice detection and payment thresholds.

Can fraud prevention be too successful?

Yes. You can become so aggressive at stopping fraud that you start stopping customers.

Suppose stricter rules prevent $20,000 of fraud but wrongly block $50,000 of legitimate transactions. Your fraud dashboard looks better. Your business is $30,000 worse off.

That is why fraud rate on its own is a poor success metric. Product teams should look at these together:

• fraud loss
• chargeback rate
• false-positive rate
• checkout conversion
• manual review cost
• legitimate revenue retained

The goal is not zero fraud. You could reach zero fraud by accepting zero payments. That would be a very secure product and a very bad business.

Which metric should you watch?

Instead of celebrating gross transaction volume, I want the business to understand its realized revenue:

• Gross sales
• minus refunds
• minus fraudulent transactions
• minus chargebacks and chargeback fees
• minus payment costs
• minus fraud operations cost
• equals realized revenue

Then I would still ask one more question: how much legitimate revenue did our fraud controls block by mistake? That number is harder to measure, but it matters just as much.

This is where product, marketing, security and finance need to look at one shared view of the problem instead of four separate dashboards. Fraud prevention is a product optimization problem. You are balancing security, friction, conversion, customer trust and revenue.

Growth or fraud?

The biggest lesson I learned was simple. A rising revenue chart does not always mean your product is growing. Sometimes fraudsters are growing faster than your customers.

And sometimes the hundreds of “users” your security system blocked were never customers in the first place.

If your numbers are moving but you are not sure how much of that growth is real, let’s talk.

About the author

Tahir Shahzad

Tahir Shahzad is a Product Manager, Product Owner, and technology consultant with over a decade of experience helping startups and organizations build products people actually use. If you are working on a product problem worth solving, reach him at tahirshahzad.com/contact/