Card Testing Fraud and How to Stop It
Someone is running stolen card numbers through your checkout in bulk. Here is what they are doing, what it costs you, and how to shut it down.
Your store has an ordinary sales day. Then a flood of small payments comes through. Most fail. A few go through. You did not suddenly gain a crowd of new customers. Someone is using your checkout as a testing lab.
What is card testing fraud?
Card testing fraud is a type of fraud where someone checks whether stolen card information is valid. They are not buying your product. They are asking your payment system one question about each card number: does it work?
The same crime answers to several names. Carding, account testing, enumeration, and card checking are all labels for one activity. Attackers hold a big pile of stolen card numbers. They need to find out which ones are valid. Your checkout is where they do the sorting.
This is one form of card not present fraud, since the attacker never shows a physical card. If you want a fuller walkthrough, our card testing guide covers the whole attack from start to finish.
The steps of an attack
Scripts let card testers run a large amount of card information through in bulk. A script does the typing, not a person. It is software hitting your payment form over and over, fast.
They keep the amounts small. Card testers make small payments. Cardholders are less likely to spot and report them. A tiny charge slips past a cardholder who skims a statement.
They also like card setup flows, where a card is saved for later use instead of charged right away. Card testers like card setup. Those checks do not usually show up on the cardholder's statement. If your checkout lets customers save a card without paying, that flow is a target.
Why they pick your checkout
Not every store gets hit the same way. Sites with free text fields, such as donation sites, are the main targets of card testing.
The other way in is through your keys. Your publishable key lets card testers fire off a large number of payment attempts against your website. That key is public by design, so it is not a leak on its own. But if your secret key gets out, the problem is worse. If your credentials leak or get stolen, card testers can use your secret key to create payments and set up cards. Guard your keys, and never post your secret key anywhere public.
What it costs you
An attack can move through your store and leave you poorer for it.
Card testing pushes your decline rate up. Your standing with card issuers and card networks can take a hit as well. A flood of failed charges from your account makes you look like a risky merchant, even though you were the victim.
It can also overload your servers and get in the way of real shoppers. Your servers spend their night answering the script instead of serving shoppers.
The worst case is when a test charge succeeds. Successful card testing payments can be reported as fraud and turn into disputes. The cardholder sees the charge, reports it, and that fraudulent sale comes back to you. Cardholders who notice these charges flag them as fraud. That can bring Early Fraud Warnings or fraudulent disputes.
Signs to watch for
For most stores, card testing first appears as a sharp climb in failed authorizations and payments. A normal day has some declines. A sudden spike well above that level is the warning sign.
Watch for odd traffic with the Dashboard, webhooks, or Stripe Sigma or Data Pipelines. Set up alerts so you find out while it is happening, not when the dispute arrives.
One caution on reading your own data. Excessive retries of payments can look like card testing if they come in extreme spikes with low success rate. Before you panic, check whether a retry setting of yours is hammering the same cards.
How to stop it
There is no single fix. You stack several small walls, and each one makes the script's job harder.
A CAPTCHA or a rate limit on charges can help stop card testing. You can use both together. After that, any further attempts from the same IP address must pass a CAPTCHA. Stripe suggests its own automated CAPTCHA protection for spotting card testing. If attacks keep going, try a different CAPTCHA tool.
Ask for a login or a session check before payment. That cuts your risk from card testers. A script can fill in a payment form. Creating a real session first is more work. Safeguards like CSRF tokens also work against some types of card testing.
Custom rules in Radar can limit or stop card testing. Stripe's recommended integrations include rate limiters, AI models, and CAPTCHA triggers to mitigate card testing. Its Payment Element and Checkout tools also have auto and manual controls for this. Send more data through your integration. Your card testing prevention works better with it.
Adding a delay or a CAPTCHA during checkout can slow down someone testing cards on your website. A real shopper barely notices the wait. A script testing card after card is slowed down.
What happens to blocked payments
When Stripe's controls stop a charge during an attack, it is marked as Blocked by Stripe.
After a card testing attack, Smart Retries already avoids retrying cards set up on fraudulent customers. So Smart Retries will not keep retrying those cards.
One last thing on scope. The controls for card testing sit apart from Radar's protection against fraudulent disputes. But they draw on the same risk factors. Card testing controls do not replace Radar's protection against fraudulent disputes. You still need both.
Whose job is it?
Stopping card testing is a shared job. Merchants, card networks, and Stripe all have a part. You are not expected to solve it alone. But your checkout is the door being used, so your defenses matter most. On a store with no defenses, a card testing attack can go unnoticed until the declines pile up.
Check your settings today. Look back over your recent failed authorizations. If there is a spike in there you cannot explain, you already have your answer.