Automated Fraud: Which Types Actually Become Chargebacks

Automated fraud is fraud run by bots and scripts at machine speed. It tests stolen cards, cracks gift card balances, and fills out applications by the thousand. Which types ever reach a chargeback comes down to one thing, and it has nothing to do with how sophisticated the bot is.

I've had my own checkout hit by small, repeated authorization attempts, months before I could name the pattern. The fix wasn't a smarter fraud model. It was velocity limits at checkout. Sort the four types below by where each one hits you, and you'll know which defense does the work.

Key takeaways

Short on time? Our pre-dispute alerts catch the disputes your checkout controls miss.

What is automated fraud (and how does detection differ)?

Automated fraud is the attack, bots running thousands of attempts a minute, and automated fraud detection is the software that spots them. One person tries six stolen cards by hand. A script tries sixty thousand, and only the script moves fast enough for your logs to notice.

Detection is what you and your bank run to catch what the bots leave behind. Three traces give them away:

1. Hundreds of near-identical requests in seconds.
2. Card numbers that climb in sequence.
3. Click timing no hand could produce.

The attacker can add machines faster than you can add reviewers, so your defense has to score the pattern across many attempts.

The label describes the method the attacker used. A slow manual version of the same scheme is still true fraud, and it costs you the same money per order. It arrives spread across days, so your logs read it as normal traffic.

That distinction matters for what you go buy. Automation leaves a pattern across many transactions, so the controls that catch it read rates and repetition. A single hand-typed order leaves no pattern, and no velocity rule will ever see it.

Types of automated fraud

Automated fraud arrives as credential stuffing, card cracking, bot-driven application fraud, and synthetic identity account creation. The split is whether the bot attacks an account you have or builds a new one. Here's what each one targets:

1. Credential stuffing: Stolen username and password pairs replayed against your login page.
2. Card cracking: Stolen card numbers run at checkout to find the live ones.
3. Bot-driven application fraud: Scripts filing account or credit applications at scale.
4. Synthetic identity account creation: Invented identities built to pass your signup checks.

1. Credential stuffing

Credential stuffing is a bot replaying stolen username and password pairs against your login form until some of them work. The pairs come from breaches at other companies, and because people reuse passwords, a list leaked from an unrelated site opens accounts on yours.

In the second half of 2024, Forter's benchmarks split login traffic into 31% legitimate and 69% bot or malicious, per Deepstrike. That is Forter's own network, so treat the level as theirs and the shape as general.

If your login page has no rate limiting, expect a large share of your traffic to be bots.

The cost arrives when the attacker spends what the account holds, which means a saved card, a stored balance, or an address they can change. Our guide to account takeover covers what happens once they're inside.

Whether that order becomes your chargeback depends on the payment method. A saved card disputes back to you, because the true cardholder never authorized it. Store credit or a loyalty balance stays between you and your customer, since no card network sits in the middle.

2. Card cracking (card testing)

Card cracking is a script running stolen or guessed card numbers through your checkout in small amounts to find out which ones still work. J.P. Morgan describes fraud actors using bots or scripts. They submit hundreds of thousands of card-not-present authorization requests on a single site.

The attacker is testing a list on your store and plans to spend it somewhere else. So they pick a checkout that accepts small amounts, returns a clear approve or decline, and moves fast. A shared prefix across the declines usually means generated numbers rather than a real range, and a free BIN lookup confirms whether the prefix maps to an actual issuer.

Digital goods, loyalty points, and gift card products all fit that description, which is why gift card fraud so often starts as a testing wave.

It's common enough to plan for. Chargebacks911, citing the Merchant Risk Council, reports that 33% of merchants surveyed experienced card testing fraud in 2025.

The damage shows up even when every attempt fails. A wave of declines drags down the approval ratio your processor watches, and a bad enough ratio invites review, higher pricing, or a reserve. You end up paying for fraud that never took a dollar off you directly.

3. Bot-driven application fraud

Bot-driven application fraud is a script filing account, credit, or signup applications faster than a person could, using stolen or made-up details. The attacker is collecting approved accounts.

Each approved one becomes an account that can hold a card, a balance, or a credit line.

This is the type that changes your exposure, because the order that follows comes from an account you already approved. Once it clears your signup checks, the order it places looks ordinary. You see a real account, a plausible history, and card details that pass every check at checkout.

The signal moves to signup, where most merchants aren't watching. Look at applications the way you'd look at authorizations. Count how many arrived from one IP range in an hour. Flag the ones sharing a disposable email domain, and the ones filled out faster than a person can type. Those are the same volume questions, asked one stage earlier.

4. Synthetic identity account creation

Synthetic identity account creation is a bot inventing identities that belong to no real person, then opening accounts under them. It pairs one real identifier with invented details.

Nothing in that identity belongs to one real person, so no cardholder ever sees a strange charge and calls it in.

Silence is what makes synthetics slow and expensive. A synthetic account sits dormant for months, builds a clean payment record, and then passes your risk scoring on that record. Our piece on generative AI fraud covers how AI-made documents drive down the cost of these identities.

The good behavior is the attack. Every clean order the account places buys it a higher limit and a lower risk score, until the day it spends everything the history earned. Account age and order history work as trust signals against real customers, and this is the one case where they point the wrong way.

Which automated fraud types become chargebacks

Card cracking and most credential stuffing die at authorization, while bot-driven application fraud and synthetic identity accounts reach checkout and dispute later. What the bot is actually doing decides the split.

When the automated action is the fraud, your processor kills most of it in real time. Your cost on a declined test authorization stops at the gateway fee and a worse approval ratio, because the cardholder never sees a charge.

Say a script fires 500 small authorizations at your checkout in an hour. Nearly all of them decline on the spot, and those cost you fees rather than disputes. The handful that approve are the problem. A live card number gets spent on a real purchase, and that purchase can come back as a chargeback weeks later.

The other two types only open the door. The fraud happens afterward, at human speed, through an account your systems already approved. That order settles, and the real cardholder eventually reads their statement. Here's where each type lands:

That table assumes your own rules catch what they should, and if you loosen them, the split moves. Approve small odd-amount charges with no address check, and testing traffic settles. Those settled charges become disputes, and disputes push up your chargeback rate.

The same three controls work against all four types.

How merchants can defend against automated fraud

Velocity limits, CVV and address checks, and pre-dispute alerts stop automated fraud, and each one catches what the control before it misses. We call that order the 3-Layer Automated Fraud Filter:

1. Velocity limits: Cap attempts per card, email, and IP at authorization.
2. CVV and address checks: Decline the transactions that stay under those caps.
3. Pre-dispute alerts: Catch the approved orders that still get disputed.

1. Velocity limits at authorization

Velocity limits cap how many attempts one card, email, IP address, or device can make in a set window. A script only wins by trying again and again, so a cap takes away the method.

Set them at your processor, where the traffic already runs. Most platforms expose this as a rules engine, and the setup runs in three steps:

1. Turn on the rules engine: Stripe Radar, Adyen risk rules, and Braintree's fraud tools all block on attempts per card, email, and IP.
2. Start at 10 attempts in 5 minutes per identifier.
3. Watch a week of decline logs: Find the highest attempt count from a customer who completed a purchase, then set your limit just above it.

Rate limits are blunt by design. A distributed attack that spreads attempts across hundreds of IPs stays under any threshold you'd be willing to set.

The other limit is your own processor. Some platforms expose velocity rules only on higher plans, or cap you at a single global rule instead of per-card and per-email counters. Check what yours allows before you build a defense around it. The answer decides whether this is your first line of defense or your second.

2. CVV and address checks on transactions

Card code and address checks catch the transactions that stay under your velocity limits. A stolen card number usually arrives without the data that proves possession. Card testers buy numbers in bulk, and bulk lists rarely carry a matching security code or billing address.

Set your gateway to decline on a mismatch instead of just recording it. Many gateways accept an AVS mismatch and settle the charge anyway. Open your gateway's AVS response settings and confirm which codes trigger a decline. In Stripe, that's Radar's postal-code and CVC decline rules.

Then set two rules. Hard-decline a CVV failure outright, and decline an address mismatch above your median order value from the last 90 days.

Both checks read the transaction alone. A bot-opened account paying with a card that matches its own billing details passes every one of them.

3. Pre-dispute alerts for what gets through

A pre-dispute alert tells you a cardholder has disputed a charge while you can still refund it. Ethoca (Mastercard) and Verifi (Visa) send these notices.

The timing is what matters here. A dispute on a synthetic-account order arrives weeks or months after the signup that enabled it. By then there's nothing left for your fraud rules to catch. An alert opens a refund window before the chargeback is filed.

Alerts have a boundary worth knowing. They start from a cardholder's dispute, so they reach you only after someone contacts their bank. An attacker who drains a bot-opened account without triggering a dispute stays invisible to this layer. What alerts do cover is the case the first two layers can't touch, a settled order that a real cardholder later challenges.

We connect to both networks, and you can see how the notices work in our explainer on chargeback alerts.

How we sourced our data

The reason-code figure in this article comes from anonymized, aggregated alert data across merchants enrolled on the Chargeback.io platform. We counted total alerts in each category, and we report them as shares of the alerts that carried a recorded code. Alerts with no code recorded are dropped from the base rather than counted as a category of their own.

In our dataset, Visa's 10.4 code for card-absent fraud is the largest single code. It runs 11.1% of alerts with a recorded chargeback reason code.

These shares cover alerts our platform processed. Read them as our own merchant mix.

Two things follow from that. The population is merchants who chose to enroll in alert coverage, which skews toward stores already carrying dispute volume. And the unit is alerts received, so the shares describe what cardholders disputed, not every fraudulent order that ever reached a checkout.

FAQ

Does automated fraud have its own reason code?

No. These disputes arrive under the ordinary fraud codes, most often Visa 10.4 or Mastercard 4837, because the issuer classifies what the cardholder reports.

How do I tell card cracking from normal declines?

Card testing leaves three signatures at once. Look for many small or identical amounts in minutes, card numbers sharing their first six digits, and a decline rate well above baseline.

Will blocking bots also block real customers?

Some, yes. Tight limits catch travelers, shared networks, and stale billing addresses, so set your cap above the highest attempt count a real order needed.

Do chargeback alerts cover bot-opened account fraud?

Yes. Alerts fire on the cardholder's dispute, so a bot-opened account reaches you like any other fraud dispute.