Card testing on Shopify rarely looks like a smash-and-grab. It looks like a burst of tiny orders — a $3 sticker, a $5 sample, a $1 digital add-on — with rotating emails, failed payments, and maybe one or two that actually authorize. The cheap item is the point. Card testing bots are not shopping. They are using your checkout to ask a payment processor a yes/no question about a stolen card, quietly enough that the real cardholder will not notice and cancel it.
Once they get a yes, they take that card somewhere else and buy what they actually want.
How often a bot checkout attempts payment is in How Many Shopify Bots Are Actually Testing Credit Cards?. In the 90 days ending 13 October 2026, on 149 stores where CartWatch scored every checkout but blocked no payments, 38,220 of 74,539 flagged checkouts attempted payment, about half. 33 became an order. The attempts were small and fast: a median cart of $4, submitted a median of 9 seconds after the checkout was created. The other half never attempted payment, and which pattern a store gets changes what the bots cost it. That split is in Many Shopify bots never attempt payment.
This guide covers how that attack works, why payment blocking is the layer that denies them the processor response, why that still takes time and does not always stop every attempt, and how CartWatch both refuses the payment and cleans up afterwards.
What is card testing on Shopify?
Card testing (also called carding) is when fraudsters run stolen card numbers through a live checkout to see which ones still work. They usually do this with bots: add a product, fill generated customer details, submit a card, log the decline or approval, move to the next number.
Shopify stores are a convenient test bench. Checkout is standardized, guest checkout is common, and a cheap SKU is easy to script against. Shopify Community threads about card testing bot attacks flooding abandoned checkouts describe the same pattern: new emails every attempt, a newly added low-price product, hundreds of checkouts a day.
Shopify Payments already intercepts a large share of this. Shopify’s own card-testing model blocks about 90% of attacks on guest credit-card checkouts and is meant to protect your authorization rate — the share of legitimate payments banks still approve after a wave of junk declines. That is a floor, not a finish. The attempts that get through still hit your processor, still create fake abandoned checkouts, and still tell the attacker which cards are live.
Why card testing bots target low-value products
A $400 order on a stolen card is a loud event. The cardholder sees it, calls the bank, the card gets cancelled, and the tester just burned a working number. A $4 charge is easy to miss on a statement — or to dismiss as a forgotten subscription, a tip, a sample.
So Shopify card testing campaigns pick the lowest-friction SKU they can find:
- Your cheapest product, a sample, or a newly published $5 item
- Digital goods or no-ship add-ons, when you have them
- Discount codes that pull the total near zero
Near zero, not zero. A $0 free sample never reaches a processor, so it is no use to a card tester. Shoppers who keep ordering the same free sample are a separate problem, covered in free sample abuse on Shopify.
The bot is not trying to steal your inventory. It is trying to get a payment processor response without waking the owner. Failed attempts still teach the attacker something (dead card, wrong CVV, insufficient funds). A successful low-value authorization is the prize: the card is live, the bank has not shut it off, and it can now be used for a high-value purchase — often on a different store, for goods the attacker actually wants.
That is why merchants sometimes see a run of tiny paid orders that look almost harmless, then chargebacks a few days later, or nothing on their own store at all while their decline rate and processor risk score quietly get worse.
What a payment processor response is worth to a bot
The checkout is not the product. The authorization is.
Every payment attempt that reaches your gateway asks the card network a question. Approve, decline, and even some error codes are useful. The attacker is compiling a list of working cards. Your store is the oracle.
That is expensive for you even when they never take a real item:
- Failed attempts still count against how banks see your store. Shopify’s card-testing write-up is explicit: failed transactions degrade merchant trust and can leave a lingering drop in authorization rates for real customers.
- Successful test charges can become chargebacks when the cardholder finally notices. Even a handful of those can push your dispute ratio up.
- Junk checkouts still create customer records, recovery emails, and bot profiles in Klaviyo if the email syncs.
If the bot never gets a processor response, the test was a waste of their list. That does not make your store invisible forever. It does make you a worse place to run the script than the next store that still answers.
Why payment blocking matters against card testing
Storefront IP blockers and country blockers help on the door. They do not decide whether Shopify will let a payment go through. A script that hits checkout directly never has to obey a theme overlay. That gap is why country and IP blocking and payment blocking are different jobs.
If the payment is refused, it never reaches your processor. The bot does not get an approve or a decline. No yes. No useful no. No cheap-item authorization to take elsewhere.
That can discourage card testers from using your store as a testing bench — they would rather hit a checkout that still answers. It is not instant, and it is not a guarantee. Some attempts still get through. And even when they are being blocked, some scripts just keep running. They do not all notice, and they do not all move on.
Refusing the payment is still the right place to fight card testing bots. Cleanup after the fact cannot un-send an authorization. You want both.
Shopify’s own filters also do not catch everything. In June 2026 Shopify announced it would stop writing some failed bot card tests into the abandoned checkout list. That filter covers one narrow pattern, and merchants kept reporting the same volume of bot-created checkouts afterwards.
How CartWatch refuses the payment and cleans up after
CartWatch is built for that two-part job.
At payment. On plans that include payment blocking, CartWatch can refuse a bot’s payment before it goes to your processor, so the order never completes. Shopify still creates the checkout, so the abandoned checkout stays in your list. Native Shopify protections still run; this is the extra gate for what they miss.
Afterwards. Every checkout is still scored. When CartWatch flags a bot, it auto-tags the Shopify customer, can mark related orders as high risk, and suppresses the contact in Klaviyo, Omnisend, and more so recovery flows do not email a stolen-card script. On Standard and above, it can optionally delete the Shopify customer record of a very-high-risk bot. That cleanup matters for the attempts that still get through, for the scripts that keep hitting checkout even while they are being blocked, and for the junk that would otherwise sit in your lists after the farm moves on.
You still want Shopify’s fraud analysis, manual capture during an active attack, and a review of your cheapest SKUs. Those are good habits. They do not replace a checkout that can say no and a pipeline that tags and suppresses what got through.
If card testing on Shopify is showing up as cheap-item checkouts, failed payments, or a processor that is getting pickier with real customers, install CartWatch from the Shopify App Store and turn on both layers — refuse the payment, clean up after.