Card testing attacks shrink when every attempt costs the attacker something. The controls that remove the most volume fastest are velocity limits per IP and per card, CVV and AVS requirements, a bot challenge on the checkout endpoint, BIN and proxy blocklists, and authorization rules tuned so obvious probes never reach the issuer. Most merchants stack all five and see the flood of small-dollar declines fall within a day or two of going live.

related article

What card testing looks like in your data

Card testing is the practice of running stolen card numbers through a live checkout to learn which ones still work. The attacker wants a yes or no answer, so the attempts share a shape: many authorizations in a short window, small amounts, the same few products, and a wide spread of card numbers against a narrow set of IPs, devices, or email addresses.

card testing fraud prevention

• Dozens or hundreds of declines per hour from one IP range.
• Amounts near the minimum, often under a few dollars.
• Repeated orders for one cheap item or a digital download.
• Many card numbers tried on one account, or one card tried on many accounts.
• Email addresses built from random strings, or a burst from one free mail provider.

Those patterns feed every control below. If your logs do not show them, the traffic is spread thin across many addresses, which pushes you toward device and behavioral signals instead of simple counters.

card testing fraud prevention

1. Velocity limits and rate limiting

Count attempts and stop the count from growing. Set thresholds per source IP, per card number, per card BIN, per email address, per device fingerprint, and per account. A common starting point is a handful of authorization attempts per IP per hour and one attempt per card number per day, then loosen or tighten from the decline data you collect.

Ecommerce Card Testing Prevention: Stop Fraud at Checkout

• Pro: Immediate effect, no vendor required, and the rules are easy to explain to a processor or acquirer.
• Pro: Catches the blunt attacks that make up most of the volume.
• Con: Shared addresses such as offices, hotels, and mobile carriers can trip limits placed on real customers.
• Con: Attackers rotate IPs, so IP limits alone leak traffic over time.

Best for: any merchant seeing bursts of small authorizations from one address range, one account, or one email domain.

2. CVV, AVS, and 3-D Secure step-up

Require the security code and the billing address match on every transaction, and route risky attempts through an authentication challenge rather than a straight approval. A failed CVV or a mismatched address is one of the clearest signals that the number came from a list rather than from the cardholder.

• Pro: Raises the cost per attempt because the attacker needs more than a card number.
• Pro: Authentication can shift fraud liability on covered transactions.
• Con: Strict address rules reject legitimate customers with mismatched billing details.
• Con: An added challenge step costs conversions, so apply it to risky traffic rather than to everyone.

Best for: digital goods, gift cards, and subscriptions where there is no physical delivery to confirm.

3. Bot detection and challenges at checkout

Card testing runs on scripts. Device fingerprinting, behavioral signals, and a challenge on the payment endpoint break the automation before an authorization is ever sent, which also avoids the fees attached to each attempt.

• Pro: Blocks the tooling itself, not just the card numbers, so the same source cannot retry with new data.
• Pro: Reduces authorization traffic and the associated per-attempt costs.
• Con: False positives land on VPN users, privacy tools, and some international shoppers.
• Con: Signals add latency and need tuning against real order data.

Best for: high-volume storefronts hit in short, sharp bursts that appear and vanish within minutes.

4. Blocklists, BIN rules, and proxy screening

Keep lists of source addresses, devices, and card BINs tied to confirmed fraud, and screen incoming traffic against proxy and hosting ranges. This is the cheapest control to run and the easiest to get wrong, because a list that never expires slowly blocks your real customers.

• Pro: Low cost, fast to deploy, and effective against repeat offenders.
• Pro: BIN rules let you require extra checks for card ranges you have never seen legitimately.
• Con: Blocklists age, and attackers move to fresh ranges and BINs.
• Con: Broad country or region blocks cut valid revenue along with the fraud.

Best for: merchants with a narrow, well-understood customer geography and a short list of high-risk card ranges.

5. Authorization tuning and monitoring

Work with your processor on how authorization requests are structured, what amount floor applies, and which decline codes you receive. Watching reason codes separates a card testing wave from ordinary decline noise, and it tells you when to tighten a rule and when to relax it.

• Pro: Reveals the shape of the attack and shows whether your other controls are working.
• Pro: Alerting on spikes gives you a chance to react while the wave is still running.
• Con: Requires analyst attention and a place to store and query logs.
• Con: Aggressive thresholds suppress approvals that would have been fine.

Best for: teams with a risk owner or a processor that offers rule tooling and decline reporting.

How to order the work

1. Pull a week of authorization logs and count attempts by IP, card, BIN, email, and device.
2. Apply velocity limits on the two or three dimensions with the clearest spikes.
3. Require CVV and address match, then add a challenge step for risky traffic only.
4. Load known-bad ranges and BINs into a blocklist with an expiry date on every entry.
5. Set alerts for decline spikes so the next wave is caught in the first hour.

Review the rules each month against new orders. A control that blocks real customers costs more than the fraud it stops, so measure approval rates next to decline rates and adjust from there. Keep card data handling inside your PCI obligations, and confirm any authorization setting change with your processor before you ship it.