The top pick for stopping a card testing attack is a layered velocity control placed directly on the payment endpoint, paired with CVV and AVS verification and a 3-D Secure step-up for risky attempts. I rank the options below on four criteria: how fast a control catches a burst of attempts, how many legitimate customers it blocks, how much engineering work it takes to deploy, and how well it covers card-not-present channels such as web checkout, mobile apps, and phone orders.

What a card testing attack actually is

Card testing is the practice of pushing a large number of card numbers through a merchant's payment form to learn which ones are live. The attacker needs a yes or no from the issuer, and your checkout is the cheapest place to get it. Each approval confirms a card is valid; declines tell the attacker to discard the number. The confirmed cards then get used for resale or for larger purchases elsewhere.

The damage to a merchant shows up in several places: authorization fees on every attempt, chargebacks on the orders that go through, fraud ratios that rise against network thresholds, and a payment processor that starts asking questions.

Signals that separate card testing from normal traffic

• A burst of authorization attempts from one IP address or a small IP range inside a short window.
• Many distinct card numbers tied to a single account, device fingerprint, or session.
• Small-ticket orders, often under a dollar, that exist only to confirm a card is live.
• A high decline ratio with a few approvals mixed in, which is the pattern a working list produces.
• Sequential or patterned card numbers, a sign of a generated list rather than real shoppers.
• Sessions that skip browsing and go straight to the payment step.
• Mismatched billing details that change with every attempt on the same account.

Option 1: Velocity limits and threshold rules (top pick)

Velocity rules count attempts per IP, per card fingerprint, per email, per device, and per account, then block or challenge when a threshold is crossed. They sit in front of the processor, so a blocked attempt never reaches the issuer.

• Pros: catches bursts at the first few attempts, cheap to run, tunable per channel, and effective against scripted traffic that reuses infrastructure.
• Cons: needs tuning against your own traffic, shared IPs at offices and schools can trip limits, and attackers who rotate proxies spread attempts thin.

Use it when: you run any public card-not-present checkout. This is the baseline layer, and everything else builds on top of it.

Option 2: CVV and AVS verification

Card verification value checks confirm the printed code on the card, and address verification compares the billing street number and ZIP code against issuer records. A mismatch on either field is one of the strongest single signals that a number was obtained without the cardholder.

• Pros: available on most processors with a configuration change, filters data that a card-only leak cannot supply, and gives you a rule input that costs nothing per check.
• Cons: address verification is far weaker outside the US, Canada, and the UK, virtual and prepaid cards often fail it for legitimate reasons, and stored credentials bypass both checks.

Use it when: you can afford a modest false decline rate in exchange for a large drop in approved fraud. Set mismatch handling by order value: decline high-value mismatches, hold mid-value ones for review. Never store the CVV after authorization; PCI rules forbid retaining it, and a stored code is a liability, not an asset.

Option 3: 3-D Secure step-up authentication

3-D Secure pushes the cardholder into an issuer-hosted challenge for selected transactions. A script cannot answer the challenge, so attempted test transactions fail before authorization.

• Pros: blocks automated testing outright, can shift fraud liability to the issuer on eligible transactions, and applies to new accounts and unusual order patterns without touching normal traffic.
• Cons: adds friction and lowers conversion when applied broadly, coverage varies by issuer and region, and the challenge flow is not available for every card type.

Use it when: a transaction scores as risky, the account is new, the order value is high, or the shipping address differs from billing. Keep it off for known returning customers so the challenge rate stays low.

Option 4: Bot detection and CAPTCHA at checkout

Bot detection scores the client behind the request using device signals, mouse and touch behavior, and reputation data. A challenge appears only when the score is poor.

• Pros: stops scripted attempts before they reach the payment form, costs little per request, and invisible challenges do not affect most shoppers.
• Cons: determined attackers run headless browsers through residential proxies, accessibility and privacy complaints follow hard challenges, and the tool needs ongoing tuning.

Use it when: your checkout is open to guests. Pair it with a server-side velocity rule, since client-side signals can be spoofed.

Option 5: Manual review and chargeback monitoring

Manual review catches the patterns that automated rules miss, and chargeback data tells you which rules are leaking.

• Pros: finds coordinated activity that single-transaction scoring ignores, produces labeled examples for rule tuning, and limits losses on high-value orders.
• Cons: slow, labor intensive, and useless as a real-time block on its own.

Use it when: your automated layers are in place and you need to catch the residual cases and feed the model.

Putting the layers together

1. Rate-limit the payment endpoint per IP, device, and card fingerprint, and return a generic error so attackers learn nothing from the response.
2. Require CVV and AVS on every card-not-present order and route mismatches by order value.
3. Trigger 3-D Secure for new accounts, high values, and mismatched billing data.
4. Run bot detection on guest checkout, and log every attempt with IP, device, and card fingerprint for pattern review.
5. Review your decline and chargeback reports each week and tighten thresholds where test traffic still gets through.

Log aggressively but store card data sparingly: keep fingerprints and outcome codes, drop the full number, and keep the CVV out of your systems entirely. Most card testing campaigns are stopped by the first two layers, and the rest exist to keep the cost of a retry high enough that attackers move to an easier target.