Answer first: the fastest way to stop card testing is to put a rate limit and a bot challenge on the exact endpoint that authorizes payments, then verify CVV and AVS data on every attempt and route suspicious traffic through 3-D Secure. Card testing is an attacker running a large volume of small authorizations against stolen card numbers to learn which ones still work. It shows up in logs as bursts of low-value attempts, often $0.00 to $2.00, spread across many cards and IP addresses.

Card Testing Prevention Tools: A Buying Guide

The stack that works for most merchants combines endpoint throttling, verification checks, velocity rules, checkout hardening, and monitoring. The top pick for a small team is endpoint rate limiting plus a challenge, because it removes automated volume before it reaches the processor, costs little, and can deploy in a day.

more on this topic

Criteria used here: coverage against automated traffic, false-decline risk for real customers, implementation effort, and how fast each control starts working.

read more

1. Rate limiting and bot challenges at the payment endpoint

An endpoint that accepts unlimited attempts per minute is the biggest gift you can give an attacker. Throttle by IP, device fingerprint, card BIN, and session, and require a challenge when a client moves faster than a human can. Server-side throttling matters more than client-side, since scripts skip your JavaScript entirely.

How to Reduce Card Testing Attacks: A Comprehensive Guide

Pros

• Removes most automated volume before an authorization is even attempted
• Cheap to build and usually deployable without a processor change
• Invisible challenges keep conversion intact for normal buyers
• Blocked-attempt logs become evidence for your acquirer

Cons

• Shared IP addresses, such as offices and campuses, can trip aggressive limits
• Attackers rotate proxies, so IP-only rules leak traffic
• Thresholds need tuning after launch or real customers get declined

Best for: any merchant with a public checkout, especially those without a dedicated fraud team.

2. CVV and AVS verification with 3-D Secure escalation

CVV and AVS checks compare what the buyer typed against what the issuer holds. Treat them as scoring signals rather than absolute gates, and escalate to 3-D Secure when several signals look wrong at once. A CVV mismatch plus an AVS mismatch plus a new device is not a normal shopper.

Pros

• Catches tests where the attacker has a card number but not the full billing profile
• 3-D Secure shifts chargeback liability to the issuer in many cases
• Widely supported and needs no new vendor

Cons

• Strict rules decline legitimate customers who moved or just received a new card
• AVS is weak for some international cards and digital-only billing addresses
• 3-D Secure adds friction and can reduce completed orders

Best for: merchants shipping physical goods to domestic addresses, where AVS data is reliable.

3. Velocity rules and BIN attack monitoring

Velocity rules count attempts across dimensions over a time window: per card, per IP, per device, per email domain, per billing ZIP. BIN attack monitoring watches for many cards from one issuer range hitting your site in a short period.

Pros

• Surfaces patterns a single-transaction review can never show
• Catches distributed attacks that stay under per-IP limits
• Often configurable inside existing fraud tools with rules instead of code

Cons

• Needs attempt history storage and a queue for reviewing flagged orders
• Tight thresholds create false positives during sales and promotions
• Repeat customers can look like abuse if the window is too short

Best for: merchants with account-based or subscription checkouts, where repeat activity is expected.

4. Checkout hardening: email checks, delays, and account requirements

Raise the cost of each attempt. Block disposable email domains, require a verified email or phone before the first payment, add a short delay between failed attempts, and skip guest checkout for high-risk orders. Each step pushes attackers toward easier targets.

Pros

• Cuts automated signups and throwaway identities
• Verification creates a trail for investigation
• Delays slow scripted attempts to a human pace

Cons

• Extra steps reduce conversion for real buyers
• Some legitimate customers use alias addresses
• Determined attackers buy aged emails and phone numbers

Best for: digital goods, gift cards, and subscription sellers, where one successful test can lead to a large fraudulent order.

5. Alerting, logging, and processor communication

You cannot fix what you do not see. Alert on spikes in authorization attempts, declines, and card-verification failures, keep logs for the retention period your processor and PCI obligations require, and contact your acquirer early when an attack starts. Processors can block abusive traffic at the network level, but usually only after you report it.

Pros

• Shortens the window between attack start and containment
• Evidence helps dispute fees and protect your processing account
• Alerts double as an early warning for unrelated fraud

Cons

• Requires a person or tool to act on the alert
• Log volume grows and forces retention decisions
• No single control works alone; alerts are a layer, not a fix

Best for: everyone. Treat monitoring as required, not optional.

Putting it together: order of operations

1. Turn on rate limits and a bot challenge at the payment endpoint.
2. Enable CVV and AVS checks, and add a rule that requests 3-D Secure on high-risk attempts.
3. Add velocity rules for cards, IPs, devices, and email domains.
4. Harden checkout with email verification and short attempt delays.
5. Set alerts for attempt spikes and review blocked traffic weekly.
6. Report sustained attacks to your acquirer or processor.

Legal note

In the United States, buying, selling, or using stolen card numbers is a federal crime under 18 U.S.C. Section 1029, and card testing traffic is evidence of that crime rather than a gray area. The only useful place for this knowledge is defense: understanding how the attack works is what lets a merchant block it. Sellers who receive test traffic should keep records and report the activity instead of engaging with the source.