Card testing fraud: how to spot it and stop an attack

Card testing fraud is when criminals use your checkout to find out which stolen or guessed card numbers work. They rarely want what you sell. A bot submits hundreds or thousands of small payments, notes which cards get approved, and the working cards are sold or used for bigger purchases somewhere else. Visa calls the automated, large-scale version enumeration, and it puts the cost of these brute-force attacks at $1.1 billion in fraud losses a year.

Many owners find out the morning after: a page of $1 charges, hundreds of declines, and an email from the processor. This guide explains how attacks work, how to spot one early, which controls stop them, and what to do while one is running. Our ecommerce fraud prevention guide covers the wider set of fraud layers. This one stays on the bots.

How does card testing work?

Visa's guidance for merchants separates two versions. Account testing means running one or two low-dollar transactions to see whether a card is active, usually on cards from a single BIN range (the first digits of a card number, which identify the issuing bank). Enumeration is the industrial version. Software works through the payment fields, such as the card number, security code, expiry date, and postal code, trying values until some combination is approved.

A typical attack runs like this:

1. The fraudster gets card data from a breach, a phishing kit, or a list of numbers generated from a known BIN.
2. They look for a checkout that's easy to hit: a donation form, a cheap product, a free trial that verifies a card, or a payment page where the payer sets the amount.
3. A script submits payments, often for tiny amounts, rotating cards, IP addresses, and email addresses.
4. The script records which attempts are approved, and which fail on the security code or postal code, which tells the attacker which fields are right.
5. Working cards get sold or used elsewhere, on purchases big enough to be worth the risk.

Visa notes that attack transactions are often under $10 (Visa). Small amounts keep each test cheap for the fraudster and make it less likely the cardholder notices.

Which businesses do card testers target?

Any checkout that accepts a card with little friction. A few setups draw more than their share:

Take a made-up food bank in Columbus with a donation page that accepts any amount from $1 up, no login required. That's exactly the page a script looks for. Our guide to credit card processing for nonprofits covers donation setups, and the payment link guide covers open-amount links.

What does a card testing attack cost you?

More than people expect, even though the tester buys nothing. The cost shows up in four places:

• Authorization fees. Your plan may charge for every authorization attempt, approved or declined, and thousands of attempts add up fast.
• Disputes. Cardholders who spot a strange $1 charge may dispute it, and each dispute can bring a chargeback fee.
• Staff time. Someone has to find the attempts, void or refund the approved ones, and answer your processor's questions.
• Account risk. A sudden flood of declines is the kind of pattern acquirers watch for.

Visa watches it too. The fact sheet for its acquirer monitoring program defines an enumeration ratio, enumerated authorization attempts divided by all authorization attempts, with a threshold of 20% together with at least 300,000 enumerated transactions. A small merchant won't reach that count alone, but your acquirer answers to Visa for its whole portfolio and may step in long before.

Now a made-up example. A subscription snack box in Austin gets hit overnight with 6,000 attempts at $1 each. Suppose its plan charges $0.10 per authorization attempt: that's $600 in fees by morning. Say 2% are approved, so 120 people now have a $1 charge they didn't make. If the shop reverses them all quickly, it's out the $600 and a few hours of work. If it doesn't, and 25 of those cardholders dispute at a made-up $20 chargeback fee each, that's another $500. About $1,100 for one bad night, and nobody bought a snack box.

There's a bigger reason to care, too. Cards that pass a test go on to be used for online fraud, and online fraud mostly lands on merchants. The Federal Reserve's report on 2023 debit card transactions at issuers with $10 billion or more in assets puts card-not-present fraud at 54.3% of fraud losses, with merchants absorbing 65.1% of those card-not-present losses (Federal Reserve). Those are debit figures from large banks only, but the pattern is plain enough.

How do you spot card testing?

Watch for patterns real customers don't produce. Visa's guidance tells merchants to investigate sudden spikes in the daily average and in declined transactions, and to alert on a large volume of approvals or declines from a similar BIN range. In practice, these are the signs:

One sign on its own can be innocent. A charity drive can bring a burst of small donations. Two or three together, especially a decline spike plus related card numbers, usually means testing. During an attack you'll also see a lot of generic declines; our guide to the do not honor code explains the most common one.

Don't wait a day to find out. Ask your gateway whether it can alert you when declines in an hour pass a number you set. If it can't, check the transaction list first thing every morning until you've fixed that.

How do you stop card testing?

Make every attempt slow, costly, or pointless for the bot. Visa's guidance for merchants recommends a set of controls: velocity checks on low-amount and authorization-only transactions, velocity tracking by IP address, device, and email, caps on how many cards can be added per account and per session, CAPTCHA to tell people from bots, and a web application firewall (Visa). Here's how each one plays out, along with a few of our own:

Our starting limits for a small store, to adjust once you know your own traffic:

• Three declined attempts per card per hour.
• Three different cards per device or IP address per day.
• Two new cards per account in one session.
• A $5 minimum on donation and pay-what-you-want forms.
• An alert when declines in any hour reach three times your normal hourly count.

Clearo's online payments screen for fraud with velocity rules, AVS, and CVV checks. If you send payment links from a virtual terminal, set a fixed amount whenever you can, which takes away the tester's favorite trick. For expensive orders, 3D Secure adds a check with the card issuer on top of these controls.

What should you do during a card testing attack?

Act within the hour. Here's the order we'd follow:

1. Confirm it. Look for the signs above: small amounts, a decline spike, related card numbers, repeat sources.
2. Call your processor or gateway. Say you're under a card testing attack and ask what they can block on their side right away.
3. Close the door the bot is using. Turn on CAPTCHA, tighten velocity limits, or raise the minimum. If none of that can happen fast, take the targeted form or link offline for a few hours.
4. Block the sources. Add the IP addresses, devices, and email patterns you see to your block list, knowing the attacker may rotate them.
5. Clean up the approvals. Void approved test authorizations that haven't settled and refund any that have, so cardholders don't carry charges they never made. Check with your processor first, since some want to review the batch.
6. Hold anything that ships. Review every real-looking order placed during the attack window before you fulfill it.
7. Write it down. Note start and end times, attempt counts, and what you changed. Your processor may ask, and you'll want it when you review fees.
8. Check the bill. On your next statement, find the authorization fees from the attack and ask whether any can be credited.

Step 5 is the one people skip. An approved $1 test is a real charge on a real person's card. Reversing it quickly is kinder to the cardholder and cheaper for you than waiting for the dispute, and every dispute counts against your ratios. Our guide on how a chargeback works explains what happens if you wait.

How do you keep card testing from coming back?

Attackers return to checkouts that worked once. After an attack:

• Leave bot checks on permanently for any form that was hit.
• Make velocity limits your default settings, not an emergency switch.
• Remove open-amount forms you don't need, and give the rest a minimum.
• Require an account or a confirmed email before customers can save cards.
• Review declines weekly. A slow trickle can be a tester staying just under your limits.
• Ask your gateway what bot screening it runs at its own level, so attacks get stopped before they reach your account.

When is heavy bot protection not worth it?

If you sell a few high-priced items online, with shipping and an account login, you're a poor target and a CAPTCHA on every page mostly annoys real buyers. Start with velocity limits and alerts, which cost nothing at checkout, and add bot checks to the specific forms that get hit. Save the full set of controls for donation pages, cheap digital products, free trials, and open-amount links. Those are where testers go, and where a little friction is cheap insurance.

Your next step

If authorization fees, small refunds, or chargeback fees from an attack are on your statement, send us a recent one for a free statement review. We'll show you what the attack cost and which charges are worth questioning. If you're cleaning up after an attack right now, contact us and we'll help you set the limits above.