Buy for the authorization decision, not the dashboard

Card testing mitigation is a control problem at the authorization request, not a reporting problem after the fact. The core buying advice: pick a stack that can score velocity, device, BIN, geography and issuer signals inside the same request that authorizes the payment, and that can return a decision (approve, step up to 3D Secure, or block) in a few hundred milliseconds. If a vendor's card testing story opens with a weekly report, you are buying evidence rather than prevention. Budget first for the rules engine and the data feeding it, and treat bolt-on alerting as a secondary line item.

What card testing looks like in your logs

Card testing is a burst of low-value authorization attempts used to find out which stolen numbers are still live. The tell is rarely one large order. It is many small ones: amounts clustered under a few dollars, dozens of card numbers hitting the same checkout from a narrow set of IPs or device fingerprints, and an authorization decline rate on that segment far above your normal baseline. On a healthy merchant account the decline rate sits somewhere between 5 and 12 percent. A segment running at 25 percent or higher inside a ten-minute window is not normal customer behavior, it is a probe. Attacks also show up as sequential card numbers sharing a BIN prefix, as repeated CVV or AVS mismatches, and as traffic that arrives outside your usual business hours.

What to look for in a mitigation stack

  • Inline scoring. The decision has to happen before the authorization is sent, not in a nightly batch. Ask for the median and 95th percentile latency of the risk call.
  • Shared velocity state. Counters must be keyed on card number, device fingerprint, IP, email and BIN at the same time. A stack that can only count per IP misses attacks that rotate addresses.
  • Configurable actions. You want block, step-up, hold for review and silent decline as separate levers, mapped to risk bands you control.
  • BIN and issuer awareness. Issuer decline codes matter. A cluster of do-not-honor responses from one BIN is a stronger signal than a generic failure.
  • Fast list updates. Confirmed fraud indicators should reach the blocklist in under a minute, not after an analyst review.
  • Audit trail. Every decision needs a reason code you can read six months later when an acquirer asks questions.

Parameter bands that hold up in production

These are starting ranges, not universal constants. Tune against your own authorization history before you enforce them.

  • Per-card velocity: more than 2 attempts on one card number within 10 minutes, or more than 5 in an hour, is almost never a real customer retrying a payment.
  • Per-device card count: more than 5 distinct card numbers from one device fingerprint in 10 minutes should trigger a hold.
  • Segment decline rate: raise an alert when a BIN, IP range or device cluster crosses 20 percent declines inside a 10-minute window.
  • Amount clustering: if more than 10 percent of daily authorization volume lands in the zero to two dollar band while your average ticket is far higher, you have an attack.
  • CVV and AVS: hard decline on CVV mismatch. Soft declines invite retries, and retries are the attack.
  • Step-up threshold: trigger 3D Secure at the 60th to 70th percentile of your own historical risk scores rather than a vendor default.
  • Blocklist windows: 60 seconds to 5 minutes for IP and device, 24 hours to 7 days for confirmed fraud clusters.

Pitfalls

  • Blocking on IP alone. Carrier-grade NAT and mobile networks will punish legitimate buyers.
  • Chasing card testing with chargeback data. The cost lands first in authorization fees, refund fees and processor risk holds, long before a chargeback arrives.
  • Leaning on CAPTCHA as the whole answer. Solvers are cheap and the widget does nothing for a scripted attack against your API.
  • Enforcing vendor default thresholds. Defaults are tuned for a generic merchant and will either over-block or under-block yours.
  • Forgetting the acquirer. Sustained attack traffic pushes your fraud-to-sales ratio past the monitoring thresholds set by Visa and Mastercard, which can put your processing account under review.
  • No rollback plan. Every new rule should ship with a kill switch and a measured false-positive rate.

FAQ

Does 3D Secure stop card testing?

It shifts liability and adds friction on the challenged attempts, but a determined attacker will still find unprotected paths. Use it as one layer with velocity limits, not as the whole program.

How fast should a block take effect?

Under a minute from detection to enforcement. A five-minute gap is enough for an attacker to burn through hundreds of attempts.

Do I need a dedicated fraud vendor?

At low volume, native velocity rules plus hard CVV decline plus decline-rate monitoring on BIN segments cover most of the exposure. Above roughly a few thousand daily authorizations, the data network of a dedicated provider usually pays for itself.

What is the cheapest first fix?

Hard decline on CVV mismatch, a per-card attempt cap, and a decline-rate alert on the top twenty BINs. Those three controls stop the common scripted attack without new spend.