Card testing fraud is the practice of pushing stolen card numbers through a live payment endpoint in small batches to find out which ones still authorize. The top defense is a layered stack that combines per-IP and per-card velocity limits, real-time monitoring of issuer response codes, and a 3-D Secure step-up for sessions that score as risky. The criteria that decide whether a control earns its place are coverage against automated traffic, false-decline rate on genuine buyers, implementation effort, and cost per screened transaction.
What card testing looks like in the authorization stream
A tester does not care about the goods. The goal is information: a yes or no from the issuer. That is why the traffic pattern is distinctive. You see a burst of low-value orders, often against digital goods, donations, or any cart that delivers instantly. Many attempts share a device fingerprint, a shipping address, or an email domain, while the card numbers rotate. Decline rates spike, then normalize when the batch moves to another merchant. In a successful run, the attacker walks away with a list of live numbers and resells it, which is why card testing sits upstream of the chargebacks you see weeks later.
The economics explain the volume. Each attempt costs the attacker almost nothing, and a hit rate in the single digits still turns a profit. Merchants absorb the opposite side: interchange on declined attempts, gateway fees on every authorization, fraud tooling charges, and dispute fees on the orders that ship.
Top pick: layered velocity limits with issuer response monitoring
Start here. Set counters on card number, IP address, device ID, email, and billing ZIP, then act on the combination rather than any single value. Pair those counters with rules that read the issuer's response code: a run of do not honor or pick up card replies from one session is a stronger signal than any single decline.
Pros
- Catches the attack during the batch, before goods leave the warehouse
- Runs on data you already receive in the authorization response
- Tunable thresholds keep friction away from repeat customers
- Works across card, wallet, and stored-credential traffic
Cons
- Requires a review cycle, since thresholds drift as your order mix changes
- Shared IP ranges such as corporate proxies and mobile carriers can trip limits
- Does nothing about a slow, distributed attack spread across thousands of IPs
Use this as the baseline if you process more than a few hundred orders a day and already log authorization responses with a session identifier.
Option: bot management and challenge pages
Rate limiting is a numbers game. Bot management is a behavior game. Device fingerprinting, JavaScript challenges, and a challenge page on suspicious sessions raise the cost of each attempt and cut the volume before it reaches your processor.
Pros
- Blocks scripted traffic before it consumes authorization attempts
- Fingerprints persist across IP rotation, which blunts distributed runs
- Reduces load on the checkout endpoint during a spike
Cons
- Needs front-end integration and testing across browsers
- Accessibility and privacy review adds lead time
- Attackers using real browsers with human solving services can slip past
Reach for this when your logs show the same cart or endpoint hammered from many addresses in a short window.
Option: address verification and security code enforcement
Requiring the card security code and matching the billing address filters a large share of tested numbers, because a stolen number rarely arrives with the correct code. Note the compliance boundary: the code may be verified but never stored after authorization.
Pros
- Cheap to enable and available in most gateway rule sets
- Shifts some dispute liability when paired with a step-up challenge
- Declines are explainable to genuine customers
Cons
- Raises friction on legitimate first-time buyers
- Weak against card-not-present markets where issuers do not support the check
- Does not stop an attacker who validates numbers elsewhere and resells only confirmed ones
Best as a default for physical goods, and as a soft rule for subscriptions where you can retry rather than decline outright.
Option: manual review queue
A human still catches patterns that rules miss, especially mixed baskets and mismatched geolocation. The tradeoff is latency and analyst cost.
Pros
- Adapts to new attack shapes within hours
- Recovers orders that automated rules would wrongly decline
- Builds a labeled dataset you can feed back into rules
Cons
- Does not scale past a few hundred flagged orders a day
- Adds handling time that frustrates legitimate buyers
- Judgment varies between reviewers without a written rubric
Keep a small queue for high-value orders and for any session that trips three or more independent rules.
Signals that separate testing from ordinary declines
- Order value clusters at the low end of your catalog, repeated across many cards
- Several card numbers tried against one account, email, or device
- Decline rate for a single endpoint jumps well above its trailing baseline
- Billing and shipping details change between attempts on the same session
- Traffic arrives outside your normal buying hours for that region
Track these as a daily dashboard. A single spike is noise. Three signals together, sustained over an hour, is an attack in progress.
Legal context
Card testing depends on a supply of stolen account data. Trafficking in that data is a federal offense in the United States under 18 U.S.C. section 1029, and merchants who knowingly process validated numbers face liability of their own. The defensive posture described above is also the safer commercial one: fewer disputed transactions, lower processor scrutiny, and a lower chance of landing in a chargeback monitoring program.