Merchant card testing is the practice of pushing small authorization attempts through a payment page to learn which card numbers still work. The recommended defense is layered, and the criteria that decide whether it holds up are detection speed, false-positive rate on real shoppers, and how the controls behave during a live burst. Start with velocity and rate limiting at the checkout edge, add AVS and CVV enforcement, then layer fraud scoring and bot detection on top of whatever traffic survives.
What card testing looks like on a storefront
Attackers submit lists of card numbers. Each attempt is deliberately small: a low-dollar authorization, a digital item, or a near-zero verification hit. Most of the attempts fail, and the failures are noise. The successes are the payload, because a working card gets moved to a resale list or spent somewhere else.
Real shoppers do not generate dozens of declined authorizations across dozens of different card numbers from one host in a ten-minute window. That mismatch between human shopping behavior and machine behavior is the foundation of every detection method below.
Signals in your own transaction data
- Many declined authorizations per session, IP, or device fingerprint
- One card number attempted across several accounts, or many cards tried from one host
- AVS and CVV results that fail in a tight, repeating pattern
- Low-value orders with digital delivery and email domains that do not match the billing data
- Traffic spikes from a narrow set of hosting providers or data centers rather than consumer networks
- Rising declines while approved order volume stays flat
Why failed attempts still cost you
The common assumption is that a declined transaction is a free transaction. It is not. Every attempt consumes authorization traffic, and a burst of them can trip processor velocity thresholds that were written for normal merchant behavior. What follows is often a reserve requirement, a temporary hold on settlement, or a review of your account.
Then come the successful ones. Each fraudulent order that converts can turn into a chargeback, a dispute fee, and added weight on the dispute ratio that networks monitor. For a small merchant, a few weeks of card testing can do more damage to processing stability than a single large fraudulent order.
Controls that work, ordered by effort
1. Rate limiting and velocity rules
Cap authorization attempts per IP, per device, and per card number in a rolling window. This is the cheapest control and it eliminates the sloppiest attacks outright. Set the per-card limit low enough that a human retry after a typo still clears.
2. AVS and CVV enforcement
Decide in advance which mismatch combinations you decline automatically and which you send to review. Attackers often hold billing data that is stale, so consistent AVS failures on a fresh card number are a strong signal. Store no sensitive authentication data after authorization, per PCI DSS.
3. Fraud scoring from your processor
Most major processors offer a rules engine and a machine learning score. Rules catch known patterns; the model catches the ones you have not seen. Run both and review the score distribution monthly, because thresholds drift as your customer base changes.
4. Bot detection on the payment step
A challenge on the checkout or payment page raises the cost of automated testing. Place it at the payment step rather than site entry so you do not slow down browsing customers. Some merchants prefer a silent risk score over a visible challenge.
5. Selective blocking of data center and high-risk ranges
Use this last and with care. Blocking entire regions will cost you legitimate sales, and hosting-provider IP ranges change often enough that a hard block needs ongoing maintenance.
If you are being hit right now
- Pull the last 24 hours of declined authorizations and group them by IP, device fingerprint, and card BIN.
- Identify the small set of sources producing most of the volume.
- Temporarily block or challenge those sources, and lower your per-card attempt threshold.
- Contact your acquirer or payment processor and report the burst before their monitoring flags you first.
- Check whether any test transactions were captured and refund or void them.
- Watch for a return run 48 to 72 hours later against a different IP range.
Which setup fits your store
If you run a low-volume store with physical goods, rate limiting plus AVS and CVV rules is usually enough, with manual review for anything that scores high. If you sell digital goods, gift cards, or anything instantly delivered, testing attempts convert faster, so pair rate limiting with a fraud score and bot detection from day one. High-volume merchants should treat the fraud stack as a monitored system rather than a fixed configuration, with someone reviewing decline patterns on a schedule.