Card testing is a fraud pattern where someone runs stolen card numbers through a payment page or API to find out which ones still work. The attacker usually starts with small charges or authorization-only checks. Mitigation means making that testing expensive, slow, and easy to spot. You do not need a massive fraud stack to reduce it. Rate limits, CAPTCHA, velocity rules, and a habit of watching decline patterns cover most of the risk.

card testing mitigation v6

What card testing looks like in practice

You might see a burst of failed authorizations from one IP range, many card numbers tried against a single account, or dozens of tiny orders placed minutes apart. Attackers often target gift card pages, donation forms, and subscription sign-up flows because those endpoints authorize cards without much friction. A successful test charge may be followed by a larger fraudulent purchase or a resale of the validated card data.

Card Testing Mitigation: A Practical Guide for Merchants

Immediate controls you can turn on today

• Add rate limits per IP, per session, and per card BIN. A hard cap on authorization attempts per minute stops brute force runs.
• Put CAPTCHA or a similar challenge in front of any form that accepts card data, especially guest checkout.
• Require CVV and AVS checks for every transaction. Do not let a failed CVV slide because the amount is small.
• Block disposable email domains and known proxy or VPN ranges at checkout if your customer base allows it.
• Use device fingerprinting to flag many cards tried from one browser or device.

Detection signals worth watching

Look at the ratio of declines to approvals by hour, by BIN, and by country. A spike in do not honor or invalid account responses from one source is a strong signal. Also watch for many cards with the same BIN prefix hitting you in a short window. That pattern often means someone is testing a batch of cards from the same issuer. Set alerts for more than a few failed auth attempts from one IP in five minutes.

more on this topic

Hardening the payment flow over time

Tokenization helps because repeat customers never send raw card data. 3-D Secure adds an issuer challenge that most testers cannot pass. If you run your own authorization endpoint, return generic error messages so attackers cannot tell a dead card from a blocked one. Keep logs of every attempt with timestamps, IP, and device ID. That data is what lets you tune rules later.

card testing mitigation v8

Response steps when an attack hits

1. Raise rate limits temporarily and block the worst offending IPs or ASNs.
2. Force CAPTCHA on all card entry forms, not just guest checkout.
3. Contact your payment processor's fraud team. They can see patterns across merchants.
4. Review recent small transactions for signs of successful tests, then refund and close those accounts.
5. Document what happened and adjust your velocity rules so the same pattern triggers faster next time.

None of this is exotic. Most card testing dies when you make each attempt cost time and attention. Start with rate limits and CAPTCHA, then layer in monitoring. The goal is not zero fraud. It is making your checkout a bad target compared with the next site.