Stripe Card Testing Attack: Signs, Costs, and How to Stop It

A card testing attack is a fraud pattern in which someone runs many small charges through a payment page to learn which stolen card numbers still work. On Stripe, the signs are a burst of declined payments, hundreds of tiny authorization attempts, and a jump in dispute volume on an account that had none before. This guide covers what merchants see, how to detect the pattern, and how to shut it down. It is written for store owners defending their own Stripe account and does not explain how to buy, validate, or trade card data.

Why do card testing attacks target Stripe checkout pages?

Stripe hosts payment forms for millions of merchants, so one script can hit thousands of unrelated checkout pages in a single day without owning any of them. Most of those pages accept a card number, an expiry, and a CVC, then return a clear approved or declined message in about a second. That fast, readable answer is what a script needs to sort live cards from dead ones.

Hosted checkout pages and payment links draw extra attention because the merchant carries the processing fee and the chargeback risk. The real cardholder often learns about an attempt only when the statement arrives.

What does a card testing attack look like in the Stripe Dashboard?

• Hundreds or thousands of payment attempts in minutes, often at hours that do not match your normal traffic.
• Most charges are small, between $0.50 and $3, because a tester wants to confirm a card without risking a large decline.
• Authorization rates fall while total attempt volume climbs.
• One email domain, IP range, or card BIN repeats across dozens of orders.
• Decline codes cluster around insufficient funds, do not honor, and stolen card.
• Radar risk scores bunch at the highest band, or at exactly the same score.

Why is card testing expensive for merchants?

Every attempt carries a fixed authorization fee even when the charge is declined, so 10,000 attempts can produce a bill with no revenue behind it. Card networks also run fraud monitoring programs that fine acquirers and merchants once dispute and fraud ratios pass program thresholds.

Stripe may add a reserve, raise your effective rate, or pause payouts while it reviews the account. Losing payout access for a week usually costs more than the fees.

How do you detect a card testing attack early?

Signals inside Stripe

• A spike in payment attempts with a matching spike in declines.
• Many orders from the same IP address or the same device fingerprint.
• Billing country that does not match the card's issuing country.
• The same customer email with small variations (name+1@, name+2@).
• Radar rules firing far more often than your baseline.

Signals in your own logs

• Checkout sessions that start and fail in under two seconds.
• A user agent string that repeats across unrelated sessions.
• Traffic from data center IP ranges instead of residential or mobile networks.
• Traffic to the payment element page without a matching visit to your product page.

How do you stop card testing on Stripe?

1. Turn on Radar rules. Block when the CVC check fails, block when the postal code check fails, and block when the risk score sits in your highest band.
2. Require CVC and postal code on every charge. Scripts that hold only a card number and expiry will fail.
3. Add a CAPTCHA such as Turnstile or hCaptcha to the checkout page and to the payment form itself. This stops most automated floods at the door.
4. Apply 3D Secure to risky transactions. A challenge step breaks scripts that cannot complete bank authentication.
5. Rate limit by IP and by card fingerprint. Five attempts from one address in ten minutes is not normal shopping.
6. Set a minimum order value of $1 or more, which raises the cost of running thousands of probes.
7. Block disposable email domains and known proxy or VPN ranges at the checkout stage.
8. Use Stripe block lists for the IP addresses, emails, and card fingerprints you have already seen.
9. Alert on webhooks. Send a message to your team when the decline rate crosses a threshold you set, so you hear about an attack in minutes rather than days.

What should you do once an attack starts?

1. Switch Radar to its strictest setting for the next few hours.
2. Turn on CAPTCHA and 3D Secure for all new checkout sessions.
3. Contact Stripe support and say the words "card testing" so the activity is flagged on your account record.
4. Save raw logs: IPs, user agents, timestamps, and card BINs. You will need them if a dispute or a network inquiry follows.
5. Do not ship any order that came from the burst, even if the charge authorized.
6. Review your dispute queue over the following weeks. Test charges rarely turn into disputes, but the same attackers often return with a larger probe.

Frequently asked questions

Is card testing illegal?

Yes. In the United States, using card numbers you do not own falls under access device fraud (18 U.S.C. § 1029) and wire fraud statutes. A single test charge is enough to trigger those provisions.

Does Stripe block card testing for me?

Radar scores and blocks many suspicious payments by default, but no filter catches every pattern. Merchants still absorb the authorization fees and any disputes that follow.

What is the difference between card testing and carding?

Carding is the wider trade in stolen payment data. Card testing is the validation step that checks whether those numbers still work, which is why it shows up as traffic on merchant checkout pages.

Can I reverse chargebacks caused by card testing?

Attempts that never captured produce no chargeback. Captured charges that the real cardholder disputes follow the standard dispute process, and win rates are low when the cardholder never bought anything from you.

How long does an attack last?

Most bursts run for a few hours until the target hardens its defenses or the attacker moves to a softer site. Repeat waves over several weeks are common.