Card testing is the use of your checkout to find out which stolen cards still work. Someone buys a list of card numbers, then tries them in bulk, with small payments or by saving a card, and keeps the ones your payment provider accepts. Stripe lists its other names as carding, account testing, enumeration and card checking; OWASP calls it carding, "multiple payment authorisation attempts to verify the validity of bulk stolen payment card data". It is done by script, because a list is only worth testing at volume.
What card testing costs you
- Disputes. Some of the test payments succeed, the cardholders see them and report fraud, and each one can become a dispute with its fee.
- Your real customers' payments. Thousands of declines tied to your business make issuers see every payment of yours as riskier, and Stripe warns that legitimate payments can be declined more often, even after the testing stops.
- Fees and load. Authorisation fees on some pricing plans, and a wave of requests your servers and your provider must answer.
- The card networks' attention. Visa counts it: since June 2025, its acquirer monitoring program flags a merchant whose enumerated authorisations reach 20% of all its authorisations, with at least 300,000 of them in a month.
- Your numbers. The tester's small payments look like new customers in your data.
How it shows in your payments
Stripe names the usual symptoms:
- a spike of failed or blocked payments;
- a spike of declined requests, many with a generic decline;
- more small payments, often with nonsense names and email addresses.
Watch the card set-up too, not only the payment. Stripe notes that testers prefer it, because a card saved to an account does not usually show on the cardholder's statement, so nobody reports it.
Why one control is not enough
Testers rotate cards, addresses and sessions, so a filter on a single signal, such as the IP address, is usually not enough on its own, in Stripe's words. Its advice is a set of controls on the routes that save a card or take a payment: a CAPTCHA checked on the server, a login before the payment, rate limits, and a combination of them. Each one adds a step, and the step falls on your buyers as well as on the script.
Ask before you charge
A testing script usually posts straight to your payment route and never loads your checkout page. Bot Protection judges the request before your server calls the payment provider, and on that route you can ask for proof that the page was really visited: an action that needs the tag. Put it on the post that charges the card, the one that saves a card and the one that redeems a gift card. Then act on the class:
bot_high: refuse with the same message a declined card shows, or a decoy answer, so the script learns nothing about its cards.bot: ask for your own check first, such as 3-D Secure, or send the buyer through the challenge page.unknown,human,human_high: the normal payment.
Start in monitor mode: nobody is stopped, and each answer says what block mode would have done, so you see how many of your checkout's requests are scripts before you turn it on. The full set-up, route by route and language by language, is in protecting a checkout.
After the payment
Refund the small payments that got through before their cardholders dispute them, as Stripe advises. Then send the payment's outcome back as feedback: a chargeback or a confirmed fraud weighs on the next decisions about the same browser, and a good customer lifts them.
Keep it fail-open
The check sits in your checkout, so it must never stop it. Use a short timeout and let the buyer through on any error: a few test payments during an outage cost less than a checkout that does not answer. More in why a bot check must fail open.
Sources
Checked on 28 October 2026.