Card testing mitigation is the set of controls a merchant uses to stop attackers from pushing small transactions through a checkout to learn which stolen card numbers still work. The core of it is velocity limiting plus risk scoring: detect and block rapid, low-value attempts that share a device, IP range, email pattern, or card range before they reach your acquirer. Done well, mitigation keeps authorization traffic clean without adding friction for real customers.

related article

What card testing looks like on a checkout page

An attacker buys a list of card numbers and needs to know which ones are live. Your payment form is the cheapest testing tool available, so the attack arrives as a burst of traffic rather than a single fraud attempt. Common signals include:

Card Testing Mitigation: A Practical Guide for Merchants

• Many orders in a short window, each for a small amount near your minimum.
• Repeated declines across sequential or same-BIN card numbers.
• New accounts or guest checkouts with no browsing history before purchase.
• Identical billing details with mismatched cardholder names.
• Requests arriving from a narrow set of IPs, proxies, or data center ranges.
• A spike in failed CVV or AVS checks that never converts to a valid order.

Single-authorization patterns are easy to miss. The volume and repetition are what separate card testing from ordinary decline noise.

Card Testing Mitigation V8: A Comprehensive Guide

Why mitigation matters beyond the test charges

The test transactions themselves are usually small, so the direct loss looks minor. The real cost sits elsewhere: authorization fees on every attempt, chargebacks that follow once the validated cards are used elsewhere or resold, higher processing costs after a fraud spike, and monitoring programs that issuers apply when a merchant's decline ratios look abusive. A payment page that answers questions for attackers also damages conversion, because the same throttling that stops fraud often catches legitimate shoppers if it is applied without tuning.

Card Testing Mitigation v7: A Practical Guide

Mitigation tactics that work together

No single control stops card testing. Stack several so an attacker has to solve multiple problems at once.

• Velocity limits. Cap attempts per card, per IP, per device fingerprint, and per email address across rolling windows. Set limits low enough to catch bursts and high enough for repeat customers.
• Risk scoring at authorization. Use the fraud tools from your payment processor to score each attempt, then decline, challenge, or review based on the score.
• CAPTCHA or challenge on suspicious sessions. Trigger a challenge when behavior looks automated instead of showing it to everyone.
• Address and CVV verification. Require both, and treat repeated mismatches as a block signal rather than a simple decline.
• Minimum order value and purchase limits. A floor on order totals removes the cheapest testing ground, though it will not stop attackers willing to spend more.
• Bot detection and rate limiting at the edge. Filter automated traffic before it reaches your checkout application.
• Blocklists for known-bad ranges. Maintain lists of abusive IPs, ASNs, and card BINs, and review them on a schedule.
• Manual review queue. Route borderline orders to a human instead of auto-approving them.

Configuration checklist by channel

Controls differ depending on where the card data is entered.

• Online checkout: hosted payment fields, tokenization, bot filtering, and per-session attempt caps.
• Mobile app: device attestation, integrity checks, and limits tied to the app install rather than the IP.
• Phone and mail order: agent scripts that flag rapid repeat callers and a rule against running multiple cards for one customer in a short window.
• Subscriptions and stored cards: separate limits for card-on-file retries so dunning logic does not look like testing.

What to do during an active attack

1. Confirm the pattern from authorization logs before changing rules, so you do not break normal traffic.
2. Tighten velocity limits and enable challenges for the affected segments.
3. Temporarily block the worst offending IP ranges, ASNs, and BINs.
4. Turn off guest checkout or guest card entry if the attack continues.
5. Notify your payment processor and acquirer so they can watch your account.
6. Refund or void test transactions and document the incident.
7. Review logs after the spike ends and make the temporary rules permanent where they held up.

Measuring whether mitigation is working

Track decline rates, authorization attempts per session, chargeback ratios, and false-positive rates side by side. If declines fall but chargebacks and attempts per session stay flat, the attack simply moved. If false positives climb, your thresholds are too tight and legitimate revenue is paying for the defense. Review the numbers monthly and after every incident.

Frequently asked questions

Does a CAPTCHA alone stop card testing?

No. Automated tools can solve or outsource challenges, and human testers bypass them entirely. Use a challenge as one layer alongside velocity limits and risk scoring.

How fast should limits trigger?

Fast enough to catch a burst inside a single session, which usually means counting attempts over minutes rather than days. Tune the window with real traffic data from your own checkout.