Card testing is a fraud attack where someone runs small charges against stolen card numbers to find out which cards still work. Detection rests on spotting bursts of low-value authorization attempts, high decline rates, and repeated card or IP patterns in your payment logs. Prevention means rate limiting, bot checks, address and CVV verification, and velocity rules that stop an automated script before it validates a single card.

card testing fraud prevention

What is card testing?

Card testing is the practice of validating stolen card numbers with tiny charges before using them for larger fraud. Attackers buy card data in bulk from dark web markets, then push thousands of numbers through a store's checkout in minutes. Cards that authorize get marked as live and resold at a higher price.

Preventing Card Testing on Payment Forms: A Practical Guide

The test amount is small, often between $0.01 and $1.00. Low values clear without a review and may sit unnoticed on a real cardholder's statement. For the attacker, one working card is worth more than the sum of the test charges.

read more

How a card testing attack runs

• Bulk card data is loaded into a script or a botnet.
• The bot hits a checkout page, a subscription form, or a payment API endpoint.
• Requests rotate through proxies, residential IPs, and fresh device fingerprints.
• Card numbers are tried against one merchant, or spread across many merchants at once.
• Results are sorted: live cards kept, dead cards dropped.

A BIN attack is a variant. Instead of stolen numbers, the attacker generates guesses from a bank identification number and tests them the same way.

strategies to stop card testing

Warning signs: how to detect card testing

Signals in payment logs

• A spike in authorization attempts that does not match your normal traffic.
• Decline rates jumping from a few percent to 30 percent or more.
• Many different card numbers from one IP, or one card used from many IPs.
• The same card BIN repeated across hundreds of attempts.
• AVS or CVV mismatches on almost every order in the burst.

Signals in web traffic

• Requests to checkout or payment endpoints far above your session count.
• Traffic from hosting providers, VPN ranges, and data center IPs.
• Requests with no referrer, no cookies, and a scripted timing pattern.
• Signups with random strings in the email field.

Signals in order data

• Orders for $1 or less, or the same low amount repeated.
• Billing and shipping details that change between attempts.
• Several orders within seconds from different customers.

How to prevent card testing

1. Rate limit your payment endpoints. Cap attempts per IP, per device, and per card per minute. Reject bursts above the cap instead of queueing them.
2. Add bot detection at checkout. CAPTCHA, JavaScript challenges, and fingerprinting raise the cost of an automated run.
3. Require CVV and AVS checks. Decline mismatches on card-not-present orders by default, and make CVV mandatory for small orders too.
4. Turn on 3-D Secure for risky traffic. Step-up authentication blocks most test attempts because the attacker cannot pass the bank challenge.
5. Set velocity rules. Limit attempts per card, per BIN, per email, per IP, and per device across a rolling window.
6. Block bad infrastructure. Deny traffic from known proxy ranges, hosting providers, and IPs on your processor's fraud list.
7. Set a minimum order value. If your business model allows it, block transactions under $1.00 or under $0.50.
8. Watch dispute alerts. Early fraud warnings from card networks give you room to refund before a chargeback lands.

What to do during an active attack

1. Find the pattern: common IPs, BINs, emails, or device IDs in the burst.
2. Block the pattern at the WAF, the payment gateway, or both.
3. Tighten rate limits until the traffic stops.
4. Void or refund test charges before cardholders dispute them.
5. Call your payment processor and report the attack. They can filter at their level.
6. Review logs after 24 hours to confirm the traffic stopped and no real customers were blocked.

Metrics that show whether prevention works

• Authorization attempt volume per hour, compared with completed orders.
• Decline rate by BIN and by IP range.
• Fraud-to-sales ratio, the figure card networks use for monitoring programs.
• Chargeback rate, kept under the threshold your network publishes for merchants.
• False decline rate, so you do not turn away real buyers while chasing bots.

FAQ

Does a $0 authorization stop card testing?

No. A zero-dollar auth still tells the attacker whether a card is live, so it feeds the same validation loop. Blocking or rate limiting zero-dollar attempts does more good than allowing them.

Can 3-D Secure stop card testing on its own?

It blocks a large share of attempts because the attacker cannot complete the bank challenge. An operator may still push through cards that pass, so pair 3-D Secure with velocity limits and bot detection.

How fast does a card testing attack hit?

Most bursts run for minutes, not days. Some attackers pace attempts over hours to stay under simple thresholds, which is why rolling velocity windows beat fixed hourly caps.

Do small merchants get targeted?

Yes. Attackers scan for stores with weak checkout controls, and a small shop with no rate limiting is an easy mark. Volume matters less than the fact that the endpoint accepts card numbers at all.

Is chargeback monitoring the only network risk?

No. Card networks also track authorization and fraud rates and can require remediation plans. Processors can raise fees, hold funds, or close an account.