Card testing does not arrive once. It arrives as a run.
Someone has a list of card numbers and no way of knowing which are still live, and a tiny order is the cheapest possible test. If a $2 charge clears, the card works. So the attempts come in minutes apart, from addresses that look almost the same as each other, and by the time anyone has looked at the first one the fourth has already been made.
One merchant reported 225 or more fraudulent $2 orders in a month, all on addresses shaped like
firstname.lastname###@gmail.com, costing around $85 a month in fees they could not recover. The
goods were never the point. The fees, the chargeback admin and the dispute rate were.
That rhythm decides the shape of the answer. You are not trying to judge one order perfectly. You are trying to make the second attempt cheaper to refuse than it is to make.
How far Shopify's own tools get you
Further than people assume, and it is worth knowing exactly where they stop.
Shopify's built-in Fraud Control assesses an order after it is placed and can flag or cancel one
that looks risky. It is genuinely useful and you should have it on. What it cannot do is match a
shape: there is no way to tell it "refuse anything that looks like firstname.lastname###@gmail.com",
because a pattern is not one of the signals it reasons about.
Shopify Flow can act on patterns, and it is the obvious next thought. The catch is timing — Flow runs on events, and the event here is order created. By then the payment has been attempted and the fee has been charged. Flow can tag the customer, cancel the order, email you; it cannot stop the charge, because the charge is what woke it up.
That leaves one place where the answer is still cheap: checkout, before the order exists.
The rule that closes the gap
Ruleproof's Stop card-testing orders preset asks two questions and blocks checkout when both are true:
- Does the email address match a pattern you supplied?
- Is the order below a value you set?
Both are readable at checkout, which is the only reason this can run there at all.
Writing the pattern
Two wildcards, and no regular expressions to learn:
*matches any run of characters#matches a single digit
So *.*###@gmail.com matches firstname.lastname123@gmail.com and jane.doe456@gmail.com, and does
not match jane@gmail.com or jane.doe@gmail.com.
Build the pattern from what you actually saw in your own orders, not from what card testing looks
like in general. The run in your store had a specific shape — a dot, a digit count, one domain — and a
pattern that specific is both more effective and far safer than a loose one. *###* would catch every
customer with a number in their address.
Why the value ceiling matters
It is what keeps a mistake cheap.
Card testing uses tiny amounts by definition — the goal is a cleared authorisation, not the product. Pairing the pattern with "only below $10" targets the behaviour precisely, and means the worst case for a real customer who happens to match your pattern is that a small order is refused. They can still buy anything of real value from you.
Set it a little above the largest test order you have actually seen, in the currency your store presents prices in.
The message
The preset lets you write what a blocked shopper sees, and it is worth a minute's thought. Something like "We could not complete this order — please contact us and we will help" gives a real customer caught by your pattern a way through, and costs a card tester nothing they care about. A bare failure produces support email from exactly the people you did not mean to stop.
How to check it before it is live
Two different checks, and they answer different questions.
Preview it against a test shopper. Construct the case you are worried about — an address matching your pattern, a small cart — and confirm the rule refuses it. Then construct a case you are not worried about, a real-looking customer with a normal order, and confirm it does not. The second test is the one people skip, and it is the one that catches a pattern that matches too much. Our guide on previewing a checkout rule before it goes live covers this in detail.
Then leave it in monitor mode. A rule in monitor evaluates every real checkout exactly as the live version would, and changes nothing — so you get a record of what it would have refused, on your own traffic, before it refuses anyone. Read that for a week. If it only ever names the run you already knew about, switch it on. If it names customers you recognise, your pattern is too loose. See testing a checkout rule without affecting real orders.
What a pattern cannot do
Be clear-eyed about the limit: this is a blocklist you control, not a fraud score. It does not evaluate a card, see an IP address, or know anything about intent. It stops a shape you have identified in your own orders, which is exactly the case where automation beats a human — the second, third and fourth attempt arrive faster than anyone can review the first.
What it does not close is the same buyer returning with a different-looking address. For that, the signal has to be attached to the customer rather than to the shape of their email: something flags them once, and checkout refuses anyone carrying that flag afterwards, whatever address they use next. That is detection and blocking as two jobs joined by a tag: the tagging half is covered in auto-tagging high-risk orders, and a checkout rule can then refuse anyone carrying the tag it writes.