Card testing fraud is the practice of pushing stolen card numbers through a live checkout in small batches to learn which ones still authorize. The top pick for catching it is authorization velocity monitoring: count failed and approved attempts per card, per IP, per device, and per email address inside short time windows, then block or step up authentication when the pattern departs from your own baseline. That one control catches most automated attacks, because an attacker has to try many numbers to find a single live card. The sections below cover the mechanics, the supporting signals, and a defense stack you can build in stages.

How card testing fraud works

Fraudsters acquire bulk card data from breaches, phishing kits, and underground marketplaces. The lists are dirty. Some numbers are cancelled, some are expired, and many never existed. To sort live cards from dead ones, the attacker needs a working payment page. Each authorization attempt returns an approval or decline code, and that code tells the attacker whether the card is worth keeping, reselling, or cashing out.

Common traits of an attack: many attempts from a small set of rotating IPs, low dollar amounts, digital goods or donation pages with instant delivery, accounts created minutes before the first order, and bursts that run for minutes to a few hours before the operator moves to another target.

Top pick: authorization velocity and pattern monitoring

Velocity rules look at how often a card, device, IP, or email shows up in authorization traffic, not at whether any single order looks suspicious. That shift in framing is what makes them effective against card testing, where individual orders are designed to look ordinary.

• Pros: catches attacks no matter which card numbers are used; runs on data you already have in your gateway and web logs; stays invisible to legitimate shoppers when thresholds are tuned against your own traffic.
• Cons: needs tuning, since tight thresholds will decline real customers during promotions and holidays; requires joining payment data with application and network data to be useful; determined attackers rotate infrastructure to stay under per-IP limits.

Best for: any merchant with card-not-present volume, and the first control to deploy if you can only build one.

Supporting signals worth wiring into your rules

1. CVV and AVS mismatch rates concentrated on one account, device, or email domain.
2. BIN clustering, where many attempts share an issuer range that is not typical for your customer base.
3. Repeated use of the same shipping address or email with different card numbers.
4. Attempts arriving at odd hours relative to your normal sales curve.
5. Zero-dollar or one-dollar authorization attempts, often used to check a card before a larger purchase.
6. A spike in declines across the board, which often means someone is running a list against you.

Building a defense stack: three options and their trade-offs

Rate limiting and CAPTCHA at checkout

• Pros: cheap, fast to ship, and it breaks the economics of automated testing by making each attempt expensive.
• Cons: adds friction for real buyers, and residential proxy networks can partially defeat IP-based limits.

Best for: small merchants who need relief this week and can accept a small conversion cost.

Step-up authentication on risky attempts

• Pros: shifts liability for many card-not-present transactions and lets genuine customers through while stopping bulk attempts.
• Cons: introduces an extra screen that some shoppers abandon, and not every issuer participates.

Best for: merchants with meaningful order volume who want to keep approvals high while filtering tests.

Manual review queues and blocklists

• Pros: good for pattern recognition, and blocklists stop repeat offenders at no cost per order.
• Cons: does not scale during a burst, and manual review adds hours to fulfillment.

Best for: high-ticket catalogs where a single fraudulent order outweighs the cost of review.

If your card was caught in a test

Small unauthorized charges are the usual first sign, and they sometimes appear alongside a change of address or a password reset you did not request. Contact your issuer, dispute the charge, and ask for a replacement number. If the card was saved with an online merchant, remove it from that account and change the password. Reporting the activity matters even when the amount is trivial, because issuers use those reports to spot merchant-level attack patterns.

Reporting and reference points

Consumer complaints go to the FTC, which tracks card fraud trends and publishes alerts. Merchants can pull mitigation guidance from their card network and acquirer, and the PCI framework covers monitoring expectations for card-not-present environments. Security reporting on large carding campaigns is also useful for understanding how quickly these attacks evolve.