Card testing is one of the least visible forms of checkout fraud, because when it works the way the attacker wants, nothing looks wrong at first. A script runs a list of stolen card numbers through your checkout, usually against a low-priced item or a $0-$1 transaction, to find out which cards are still active before using them for larger fraud elsewhere.
What it looks like from the storefront side
A few patterns tend to show up together:
- A burst of checkout attempts in a short window, often against the same low-cost product
- Card numbers that differ but share a BIN (bank identification number) range, suggesting a generated or purchased list
- High decline rates mixed with occasional approvals, since the script isn’t trying to convert, it’s trying to validate
- Sessions with none of the normal shopping behavior: no browsing history, no time on page, straight to checkout
Why this matters even when the transaction is declined
Even a declined card-testing attempt costs you: payment processors charge per attempt, and a spike in declines can affect your merchant risk profile with your payment provider. Successful ones are worse: they lead to chargebacks once the real cardholder notices.
Catching it before the charge
Because card testing is scripted, it tends to fail the same behavioral and automation checks that catch checkout bots: abnormal click timing, missing interaction history, and automation fingerprints. Scoring checkout sessions in real time, before the payment is submitted, catches this pattern early enough to block it rather than dispute it after the fact.