Card testing fraud, what an attack looks like and how to stop it

Card testing is when a fraudster uses your checkout to find out which stolen card numbers still work. They run a stream of tiny authorizations through your store, usually with a bot, and watch which ones approve. Your checkout becomes their validation tool, and you pay in gateway fees, a wrecked authorization rate, and, days later, chargebacks.

The other names describe the same thing from different angles: carding is the general term, card cracking and enumeration cover guessing card details across a range, and a BIN attack walks sequential numbers inside one issuer's bank identification number.

What is card testing fraud?

Card testing is a form of card-not-present fraud where the goal is not the purchase, it is the answer. A criminal buys a list of stolen or partial card numbers and needs to know which are live before cashing them out or reselling them. Your checkout gives that answer for free, one approval or decline at a time. It sits inside card-not-present fraud, where the card is never physically present.

The transactions are small or zero on purpose. Stripe's card testing guidance, checked August 7, 2026, describes two methods: card setup, a validation that runs without a charge showing on a statement, and small-amount payments a cardholder is unlikely to notice. Both keep the owner from spotting the activity while the tester confirms the card.

It runs at machine speed. A person testing cards by hand is not the threat. Scripts firing hundreds or thousands of attempts against a guest checkout are, and they rotate IPs, user agents, and card numbers to slip past any single filter. Stripe's own guidance says filters based on one heuristic, such as blocking an IP, are usually not enough.

What does a card testing attack look like?

You will see it in your dashboard before anyone tells you, and the shape is distinctive once you know it.

A spike in failed and blocked payments. Stripe lists this as the primary symptom: a sudden climb in declined authorizations and 402 errors on the payments list and developers log. On Shopify the order feed fills with attempts that never became orders.

A cluster of tiny amounts with nonsense details. Sub-$2 or $0 values, customer names that read as keyboard mash, disposable emails, shipping details that do not resolve, and, in a BIN attack, sequential-looking card numbers.

A burst pattern. The attempts arrive in a tight window, often at an odd hour, from a narrow set of IPs or devices, against one or a few BINs.

Then a run of small successes. Once the tester finds live cards, a handful of the tiny charges approve. Those come back to bite you.

Managed platforms absorb a lot of this. Shopify says its platform machine learning model blocks approximately 90 percent of card testing attacks on guest credit card checkouts, with a 13 percent authorization-rate improvement for legitimate sales (Shopify enterprise blog, checked August 7, 2026). That is a floor to build on, not a reason to ignore the traffic that gets through.

Do card testing attacks cause chargebacks?

Yes, and this is the part operators underestimate. The small charges that succeed sit on real people's cards. When those cardholders see a charge they do not recognize, they dispute it with their bank as fraud. On Visa that arrives as reason code 10.4, Other Fraud, Card-Absent Environment, the same third-party fraud code a stolen-card purchase uses.

So a card testing wave produces two waves of damage. The first is immediate: authorization fees on every attempt, and an elevated decline rate that drags your approval rate down even after the attack stops. The second lands days later as a batch of 10.4 disputes, each carrying a fee of roughly $15 to $25, whether you fight or not.

That is why the numerator matters more than any single lost case. A cluster of 10.4 disputes lands in your chargeback ratio at once, and Visa counts a dispute whether or not you win it. Under VAMP the excessive-merchant threshold is 150 bps in the US, Canada, EU, AP, and LAC as of April 1, 2026, with CEMEA at 220 bps. Check Visa's current fact sheet, because the figures have moved. A quiet month at 40 bps becomes a threshold breach fast when thirty fraud disputes hit at once.

The disputes that do land are genuine third-party fraud, so representment is a triage job, not a reflex. Where a delivery address, prior order history, or verification data gives you an answer, you file. Where the charge was a $1.20 test on a card the real owner never used with you, there is nothing to defend and a fast refund is cheaper. Handing that filing work to Reclaim means the winnable cases get built and filed ahead of the deadline while you focus on stopping the attack.

How do you stop card testing?

No single control stops it. The defense is a stack, most of it at checkout, upstream of the dispute layer. These disputes are genuine fraud, not the avoidable-confusion kind that preventing avoidable disputes is built for, so the work here is hardening the door, not arguing cases after the fact.

Attack stage	What you see in the dashboard	What to do
Probing / BIN attack	Burst of authorizations, mostly declined, sequential-looking numbers, one or few BINs, sub-$2 or $0 amounts, odd hours, repeat IP or device	Turn on checkout CAPTCHA and bot protection; add velocity rate limits per IP; require CVV and AVS match
Breakthrough	A run of small successful charges, nonsense names and emails, express or wallet checkout used	Disable express and wallet checkout for the window; enforce 3DS; refund and cancel the test orders before anything ships
Fallout	Authorization rate drops, decline rate stays high, 10.4 disputes arrive days later, dispute ratio climbs	File representment where evidence exists, call your processor to flag it as card testing, keep controls on until traffic normalizes

The individual levers, in the order I reach for them:

CAPTCHA and bot protection. A challenge that scripts cannot pass ends most attacks. Stripe reports that adding its managed CAPTCHA for all Checkout users reduced card testing by 80 percent with under 2 bps impact on authorization rates (Stripe docs, checked August 7, 2026). Shopify offers checkout CAPTCHA in admin.

AVS and CVV enforcement. Require a CVV match and decline on AVS mismatch. A tester holding bare card numbers fails both, cutting a whole class of attempts.

Velocity and rate limits. Cap attempts per IP, per device, and per BIN inside a short window. Stripe's guidance suggests limiting new customers or payment attempts from a single IP over a day, and building velocity rules in Radar on paid plans. This turns a fast attack into an impractical one.

Turn off express checkout during a wave. Wallet and express buttons remove the friction you want back under attack. Disabling them for the window closes the endpoint testers are hitting.

Fraud analysis and refund fast. Shopify's fraud analysis and Stripe Radar flag the suspect orders. Refund and cancel the successful test charges before they ship, limiting the goods you lose and the dispute fees when the 10.4 claims arrive.

The honest limits

Every control here trades against legitimate conversion. Crank CAPTCHA and verification too hard and you decline real buyers, a revenue leak of its own. The platforms already run heavy defenses, so most stores never see a large attack, but a leaked publishable key or an unprotected custom checkout can draw thousands of attempts in an hour.

The authorization-rate damage is the part that lingers. Issuers harden their stance against a business flooding them with declines, so legitimate payments keep getting rejected after the attack is over, and that recovery takes time you cannot shortcut.

And chargeback protection does not save you here the way it might elsewhere. The disputes card testing generates are real third-party fraud, so many protection products either exclude them or the coverage is beside the point: the ratio and reputation damage is already done regardless of who eats the case. The only durable fix is keeping the attempts from succeeding in the first place.

Frequently asked questions

What is the difference between card testing and a BIN attack?

They overlap. Card testing, or carding, is the general practice of running transactions to validate stolen card numbers. A BIN attack is one method within it, where a script generates and tests sequential card numbers inside a single issuer's bank identification number range to find which combinations are live. A BIN attack is essentially the reconnaissance phase, and carding is deploying the validated cards.

Do card testing charges become chargebacks?

The successful ones do. Small test charges that approve sit on real cardholders' accounts, and when the owner sees a charge they do not recognize they dispute it with their bank as fraud. On Visa that arrives as reason code 10.4, card-absent fraud, and each dispute carries a fee of roughly $15 to $25 and counts toward your monitoring ratio whether you win or lose.

Can Shopify or Stripe stop card testing on their own?

They stop most of it. Shopify says its platform machine learning model blocks around 90 percent of card testing on guest credit card checkouts, and Stripe's recommended integrations apply rate limiters, AI models, and CAPTCHA triggers automatically. Neither is complete, especially on custom or unprotected checkouts, so you still add your own controls: CAPTCHA, AVS and CVV enforcement, velocity limits, and refunding test orders fast.

How do I know if I am under a card testing attack right now?

Check for a sudden spike in failed or blocked payments and 402 errors, a cluster of very small or zero-dollar attempts, nonsense customer names and emails, and a tight burst from a narrow set of IPs or BINs. Both the Shopify order feed and the Stripe payments and logs views show this pattern clearly once you look at the timestamp density and the amounts.

What to check this week

Open your payments data and look at two things. First, your authorization rate over the last 90 days: a step-down that never recovered is the fingerprint of a past card testing wave, and a sign your controls need work. Second, pull every order under $5 and sort by hour and IP. If clusters of tiny charges arrive in bursts from the same handful of sources, you are being tested now, and the table above is where to start before the 10.4 disputes show up on next month's ratio.