Home / Knowledge hub / Card testing
Knowledge hub
Card testing
Using your checkout to check which stolen card numbers still work.
What it means
Card testing, also called carding, is when criminals run lists of stolen card numbers through a merchant's checkout or donation form to see which ones are accepted. Small payments are usually enough. A card that goes through is then used for larger fraud elsewhere.
You are not the intended victim of the big purchase. You are the free testing tool. A script makes hundreds or thousands of attempts through your own payment page or API, and your payment provider sees each one as your business's activity.
Why it matters
You pay for it. There are per-attempt fees, fees for failed payments, refund costs for the small charges that did succeed, and dispute costs later. Your approval rate drops, and your provider may add restrictions or freeze your account.
It is one of the quickest ways for a quiet site to end up in trouble with its payment provider. A donation page or a low-price digital product with no limits on attempts is an ideal target because the attackers want small amounts that go unnoticed.
How it shows up
It shows up as bursts of failed payments, many different cards from one device or network, tiny order amounts, and traffic to checkout or card-add endpoints with no browsing before it. Endpoints that check a card without taking a payment, such as a save-card step, are targeted too.
Defences stack. Limit attempts per session, address and device, add a challenge that bots struggle with, require sign-in before payment, and set alerts on failure rates. Test whether the limits really hold, including against automated traffic on the API, since rate limits are often applied to the page but not to the API behind it.
Questions people ask
Card testing, answered
Why would criminals test cards on my site?
They need to know which stolen numbers are live before selling or using them. Small sites with weak limits are easy to use for that, so they are picked even when they have no valuable data.
Is card testing a breach of my systems?
No. Your systems are working as designed. The abuse is of a feature that has no limit. That is why it is a logic and design flaw rather than a classic vulnerability.
How do I spot it early?
Watch for a jump in declined payments, many tiny orders, and a high number of cards per address or device. An alert on payment failure rate is the cheapest early warning.
Does a CAPTCHA stop it?
It raises the cost and removes simple scripts, but determined attackers use services that solve challenges. Combine it with attempt limits, sign-in requirements and monitoring.
How do we test our own checkout?
Send repeated payment attempts through the page and the underlying API, with different card values, and see where the limit stops. An API with no limit is the common finding.
Sources
Where this comes from
Related
Terms that sit next to this one
Payment fraud
Using stolen or fake payment details to buy from your business.
Bot traffic
Automated visitors that scrape, stuff credentials or buy stock before real customers.
Rate limiting
Capping how often something can be attempted, per user or per address.
API rate limiting
Capping how many calls a client can make so abuse and cost stay bounded.
Fake account creation
Mass sign-ups by bots to abuse offers, spam users or farm rewards.
Where does your checkout stop counting?
We test whether limits on payment and card-add endpoints hold when called directly, not only through the page. A finding shows the requests and how far the limit let them go. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.