The short answer

Card testing mitigation works when three layers run at the same time: kill the automation, add friction a script cannot satisfy, and cap how many attempts the same card, IP, device, or BIN range can make in a short window. Miss one and the attacker finds the gap. Traffic controls alone fall apart the moment the operator moves to residential proxies. Payment rules alone do nothing if your gateway happily processes 60 authorizations a minute.

card testing prevention and mitigation

I start with visibility, because you cannot cap what you are not measuring.

more on this topic

What card testing looks like in your own data

Card testing rarely hides well once you know the pattern. It is a burst of authorization attempts against stolen numbers, run at scale until a few come back approved. On a merchant dashboard it shows up as:

best practices for card testing mitigation

  • Authorization volume that spikes overnight while actual orders stay flat.
  • Decline rates three to ten times your normal baseline.
  • Hundreds of different BINs arriving from one IP, or one BIN hit from hundreds of IPs.
  • Attempts for the cheapest item in the catalog, or a sub-dollar amount, from emails that look machine generated.
  • AVS and CVV results that mismatch on nearly every attempt, with billing addresses that do not exist.
  • Traffic at 3 a.m. from countries where you have no customers.

Each of those signals is weak on its own. Together they are close to a fingerprint.

read more

Layer one: traffic and bot controls

Rate limiting belongs at the edge, not inside your checkout controller. Cap requests per IP, per session, and per device fingerprint, and apply the same ceiling to the payment endpoint itself. Attackers who skip your storefront and post straight to the auth API are common, and a checkout-only limit does not touch them.

Beyond raw rate limits, I look for:

  • Blocking or challenging datacenter ASNs and known proxy ranges. Most test traffic originates from hosting providers, not consumer ISPs.
  • Device fingerprinting and a signed session token that must be present for an authorization to be accepted.
  • Browser checks that require JavaScript execution, which drops most headless scripts.
  • A CAPTCHA or challenge that only appears when risk signals stack up, so legitimate buyers never see it.
  • Honeypot fields in the form that a human never fills and a bot always does.

Rotate and tune these rules. A static blocklist ages badly.

Layer two: payment-side friction

This is where most merchants leave money and reputation on the table. Require CVV and enforce AVS. Run 3-D Secure on anything that looks risky, since the authentication step breaks scripted testing outright while shifting liability on approved transactions.

Then add ceilings that are cheap to build and hard to work around:

  • A maximum number of authorization attempts per card number per day, and per IP per hour.
  • A ceiling on attempts per BIN range, which catches an attacker cycling through one bank's numbers.
  • Blocks on prepaid and virtual BINs for new accounts, or for any account without order history.
  • A minimum order value, or a review queue for anything under a threshold you set.
  • Country mismatch rules between IP, billing address, and issuing bank.

Work with your processor's fraud tooling here too. Stripe Radar, Adyen, and similar systems expose velocity rules you would otherwise have to build yourself.

Layer three: monitoring, alerts, and a response plan

Rules decay. What saved you last quarter may be noise now, so review thresholds monthly and after every incident. I build alerts on three numbers: authorization attempt rate, decline rate, and the ratio of attempts to completed orders. When any of them crosses a line, someone gets paged.

Have a kill switch ready. The ability to pause card-not-present authorizations for fifteen minutes while you investigate beats an hour of debate. Log the IP, device fingerprint, and request headers for every attempt so you can block the source instead of guessing.

Card networks also run their own programs. Visa and Mastercard both monitor enumeration activity and can alert acquirers when a merchant's terminal or BIN range is being probed. Your acquirer is a useful ally here, so tell them early. Watching your chargeback ratio climb into a monitoring program threshold is a far more expensive conversation than a heads-up email.

A working checklist

  1. Turn on rate limits at the edge and on the payment endpoint.
  2. Require CVV and AVS, and enable 3-D Secure for high-risk attempts.
  3. Set per-card, per-IP, and per-BIN attempt ceilings.
  4. Drop datacenter traffic and unresolved proxy ranges.
  5. Add a device fingerprint plus a signed session token.
  6. Alert on decline rate and attempt-to-order ratio.
  7. Write down who pauses payments, and how.

None of this is exotic. It is basic hygiene applied with some discipline, and it turns card testing from a free playground into an expensive, noisy failure for whoever is running the script.