Card testing is a fraud attack that sends stolen card numbers through a live payment form to learn which ones still authorize. On Stripe it shows up as a burst of small charges, a jump in declines, and many different cards hitting one checkout page in minutes. Every attempt returns a signal to the attacker: approved, declined, or a request for bank authentication.
The merchant is the test lab. Attackers pick checkouts that accept low amounts, skip 3D Secure, and do not limit how many times one IP or one card can try. Your Stripe account absorbs the fees, the disputes, and the fraud rate that follows.
The pattern is loud once you know the shape of it. Open the Payments list, filter to declined charges, and sort by time.
Radar shows the same signals as risk scores and rule matches. If 60 declines land in five minutes from one IP block, someone is testing your form.
Stripe's API answers fast and returns clear decline codes, which is what a card tester wants. A public checkout form needs no account, no approval, and no relationship with the merchant. Attackers also know that many small stores run the default Radar settings and stop there.
The math favors volume. A tester with 10,000 card numbers needs a handful of live ones to profit, and a few hundred blocked attempts cost almost nothing. A merchant who takes hours to react gives away a working batch.
Costs start with Stripe's per-charge fee on every authorization that goes through, plus a dispute fee (Stripe charges $15 per chargeback) when cardholders file. Then come the indirect costs.
Visa and Mastercard both run programs that flag merchants above set fraud thresholds. Merchants that stay above the line can face fines or lose the ability to accept certain card types.
You stop it by raising the cost of each attempt and cutting the attacker's feedback loop. No single control does the job. A stack of four or five does.
Set a webhook or a Sigma query that alerts when declines pass a threshold in a 10-minute window. Track the ratio of declines to successful charges, the count of distinct cards per IP, and new-customer volume that does not match your normal week.
Review the block list once a week. Attackers rotate IP addresses, so rules tied to one address go stale. Rules tied to card fingerprint velocity hold up longer.
Yes. Running stolen card numbers through a payment form is fraud and identity theft. In the US it falls under wire fraud and access device statutes, and it breaks Stripe's services agreement, which is why accounts tied to testing get closed.
This guide covers the defense side only: how merchants spot the attack and shut it down.
No. Stripe does not charge for authorizations that fail. Failed attempts still count toward your fraud metrics and your decline rate, which card networks watch.
No control stops it for good. 3D Secure removes most automated attempts because the tester cannot pass the bank challenge, but an attacker who also phished the one-time codes can still get through.
Hours to days for a public form. Scrapers and botnets scan for charge endpoints all day, so a new checkout with no rate limit often sees its first probe inside 24 hours.
Carding is the broader crime of using stolen card data to buy goods or move money. Card testing is the step that checks which numbers still work before the cash-out.
Turn on 3D Secure for payments above your average order value, then add one Radar rule that blocks more than five card attempts per IP per hour. That pair stops most scripted testing, and both settings take minutes to switch on in the Stripe Dashboard.
You will receive the digital voucher immediately.
All your data is transmitted with unbreakable SSL-RSA encryption.
You can give away, resell or keep the vouchers.
We are available for you 24 hours a day.
Be informed as soon as new vouchers are added or when there are discounts.