Card testing is a fraud technique where criminals use a merchant's checkout to verify stolen card numbers, placing many small transactions to see which cards are still valid. The charges are small, often $1 or less, and the pattern is unmistakable once you know it: a sudden spike in authorization attempts, many of them declined, from a small number of IP addresses or device fingerprints, at a velocity no real customer would produce. The store that spots the pattern early can block it. The store that does not will see the small charges turn into large fraudulent orders on the cards that passed, followed by chargebacks that cost the store the goods, the revenue, and the fees.
What a card-testing attack looks like from the inside
The attack starts with a list of stolen card numbers, bought in bulk or harvested from a breach, and a script that runs them through the checkout. The script does not buy anything. It places the smallest possible charge, often a $1 authorization, and watches the response. An approval means the card is live. A decline means it is dead. The attacker keeps the live cards and discards the dead ones, and the store's checkout is the testing ground.
The signs are visible in the authorization data before they are visible in the revenue. A spike in authorization attempts that does not match a spike in orders. A high decline rate concentrated in a short window. Many attempts from the same IP address, the same device fingerprint, or the same ASN. Attempts that use the same email pattern, a plus-tagged address or a disposable domain, or that jump straight to the highest-value product. And attempts that happen at odd hours, when the store's real customers are asleep. Any one of these is a signal. Three of them together is an attack.
The cost is not the small charges. It is what follows. The live cards get used for large fraudulent orders, often shipped to a reshipping address, and the store ships the goods before the chargeback arrives. The chargeback costs the store the product, the revenue, and a fee, and a chargeback rate above 0.6 percent puts the store's account at risk. A store that processes a card-testing attack without noticing it is not just losing the small authorizations. It is financing the fraud that follows.
How to stop the probe without blocking real customers
The first defense is velocity. A real customer places one or two authorization attempts in a session. A card-testing script places dozens or hundreds. A velocity limit on authorization attempts per IP, per device, and per account, with a threshold that triggers a challenge or a block, stops the attack at the point where it is cheapest to stop: before the authorizations are processed. The threshold has to be set carefully, because a real customer who mistypes a card number and retries is not an attacker, and a velocity rule that blocks them is a false positive that costs a sale.
The second defense is a challenge that a script cannot pass. A CAPTCHA, a 3-D Secure challenge, or a device fingerprint check that requires a real browser will stop most automated testing, because the attacker's script is built for speed, not for solving challenges. The challenge should appear only when the velocity or the pattern triggers it, not on every checkout, because a challenge on every order costs conversion. The goal is to make the checkout expensive for the attacker and invisible to the customer.
The third defense is the payment processor's own tools. Most processors offer velocity controls, fraud rules, and card-testing detection, and the store should use them, not build its own. Stripe, for example, publishes guidance on card testing and offers Radar rules that can block the pattern. The store that relies on the processor's tools and adds its own velocity limits has two layers, and the attacker has to beat both.
What to do after the attack is spotted
First, block the source. The IP addresses, the device fingerprints, and the email patterns that carried the attack should be blocked at the gateway, not just at the checkout, because the attacker will try again from a different entry point. Second, review the authorizations that were approved. The cards that passed are the ones that will be used next, and the store should watch for large orders on those cards, especially orders shipped to a new address or a reshipping service. Third, report the attack to the processor, because the processor's fraud team can see the pattern across merchants and can block the cards at the network level.
And review the checkout itself. A checkout that allows unlimited authorization attempts with no velocity limit and no challenge is a checkout that invites card testing, and the fix is not a one-time block. It is a permanent velocity rule, a challenge that triggers on the pattern, and a monitoring alert that fires when the authorization rate spikes. A store that treats a card-testing attack as a one-off incident will see it again. A store that treats it as a design flaw in the checkout will not.
Frequently asked questions
What is card testing?
A fraud technique where criminals use a merchant's checkout to verify stolen card numbers, placing many small transactions, often $1 or less, to see which cards are still valid. The live cards are then used for large fraudulent orders, followed by chargebacks.
How do I spot a card-testing attack?
A spike in authorization attempts that does not match a spike in orders, a high decline rate in a short window, many attempts from the same IP address or device fingerprint, and attempts at odd hours. Any one is a signal; three together is an attack.
What chargeback rate puts my account at risk?
Shopify considers a chargeback rate under 0.4 percent good standing, and a rate above 0.6 percent elevated, which puts the store's account at risk. Card testing that goes unnoticed drives the rate up through the fraudulent orders that follow.
How do I stop card testing without blocking real customers?
Use velocity limits on authorization attempts per IP, per device, and per account, with a challenge that triggers only when the pattern appears, and use the payment processor's own fraud tools. A real customer who mistypes a card and retries is not an attacker, so the threshold has to allow for that.