Buy mitigation that acts on the authorization request, not just on the checkout form. The packages worth your budget combine issuer-level velocity rules, a challenge step that fires only on suspicious traffic, and a backtesting mode that replays your own historical transactions so you can see what would have been blocked before you sign. Ask every vendor for two numbers against your own data: how many card testing attempts they catch, and how many good customers they turn away to catch them. A vendor that cannot produce both is selling you a CAPTCHA with a dashboard.

How card testing shows up in your logs

Card testing is the practice of running stolen card numbers through a live payment page in small batches to learn which ones still authorize. The value to the attacker is the answer, not the goods, so the pattern looks unusual: many attempts per session, clustered amounts near zero, rapid retries across different cards from one device, and a sudden rise in declines that never reach your fulfillment queue. Because each attempt is a real authorization, your processor sees the traffic and your decline rate climbs before your fraud team notices anything on the order side.

What to look for in a mitigation package

• Authorization-level rules. Blocking at the form misses scripted clients that post directly to your payment endpoint. The tool should evaluate the authorization request itself.
• Multi-key velocity. Per card, per IP, per device fingerprint, per email, per BIN, and per shipping address, with the ability to combine keys in one rule.
• Issuer response awareness. Decline reason codes tell you whether a card is stolen, unfunded, or simply blocked. Rules that ignore those codes generate noise.
• Challenge escalation. A visible challenge for everything kills conversion. Look for a tiered path: silent risk score, then soft challenge, then hard block.
• Coverage of every card-accepting endpoint. Card-on-file updates, subscription retries, gift card balance lookups, account recovery flows, and any public API that touches a PAN.
• Backtesting and shadow mode. The tool must run alongside your live traffic in observe-only mode and produce a decision log you can export.
• Feedback loops. Chargeback and refund data should feed back into the rules automatically, not through a quarterly spreadsheet exercise.

Parameter bands worth asking about

Vendors will quote defaults. Use these bands as a sanity check, then tune against your own traffic.

• Card velocity: block or challenge after 2 to 3 declines on the same card number within 24 hours.
• IP velocity: challenge after 5 to 10 checkout attempts per hour from one address, lower for addresses with no order history.
• BIN concentration: alert when a single BIN exceeds 3 to 5 times its normal share of attempts inside a one-hour window.
• Decline rate drift: investigate when a traffic segment moves 3 to 5 percentage points above its 30-day baseline.
• Amount clustering: flag repeated authorizations under a few dollars, especially in round numbers.
• Challenge budget: aim to challenge under 2 to 5 percent of legitimate checkouts. Above that, your rules are too broad.
• Review turnaround: escalations from automated rules should reach a human within 15 minutes during business hours.

Pitfalls that let attacks through

• Buying a challenge widget and calling it mitigation. Automated tooling clears many challenge types, and challenge farms exist for the rest.
• Rules that live only in the storefront. Attackers do not use your storefront.
• Country or IP blocking as the primary control. It generates false declines and attackers route around it cheaply.
• No coverage for the account area. Saved-card verification and address-change flows are favorite testing surfaces.
• No observe-only period. Switching on strict rules without a shadow run is how merchants discover their best customers were blocked.
• Decision logs you cannot export. Without them you cannot prove the tool works, and you cannot leave.
• Ignoring recovery. A blocked good customer costs more than a stopped test attempt, so pair rules with a fast appeal path.

Frequently asked questions

How quickly can an attack hit?

Small bursts can complete within minutes, and distributed attacks can run for days below per-IP thresholds. Detection has to work at the aggregate level, not per visitor.

Does 3-D Secure stop card testing?

It raises the cost substantially because the attacker no longer learns whether the card is live. It also adds friction, so most teams step it up conditionally rather than applying it to every transaction.

Which metrics prove the tool is working?

Track attempts blocked per thousand authorizations, decline rate for new-card traffic, challenge rate on known-good customers, false positive rate from the review queue, and the time from first suspicious attempt to first block.

How is pricing structured?

Common models are a platform fee plus per-transaction or per-decline pricing, sometimes with a separate charge for challenge volume. Model the cost against your peak attack month, not your average one.