Buy detection at the authorization layer, not only at the checkout page. The signal that separates card testing from ordinary fraud is shape: many low-value authorizations, spread across many card numbers, arriving from a small pool of devices, IPs, or accounts in a short window. Choose a tool that ships with velocity, BIN diversity, and decline-rate rules you can edit yourself, because the attack pattern shifts and you cannot wait on a vendor ticket every time it does.

What to look for before you commit

A detection tool earns its place when it catches enumeration traffic without flagging your repeat customers. Score every candidate against the same checklist.

• Real-time decisioning. The check must run inside the payment request, typically under 200ms, or the run finishes before your rule fires.
• Device and network fingerprinting. Card numbers rotate; devices, fingerprints, and ASNs repeat. Detection built only on card data ages out fast.
• Rules you can edit. Look for a visual rule builder or a documented API, plus a sandbox that replays rules against past traffic.
• Decline-rate monitoring by segment. A spike in declines on one BIN range or one checkout endpoint is the earliest usable alarm.
• Chargeback feedback. The system should learn from disputes you mark as fraud, not just from blocks you set manually.
• Audit logs. You need a record of who changed a rule and when, for dispute evidence and compliance reviews.

Parameter bands that work in practice

Treat these as starting points, then tune against your own order history.

• Ticket size watch: flag attempts between $0.00 and $2.00, where authorization-only probes and small-dollar tests cluster.
• Card velocity: 5 to 10 attempts per card per hour triggers review; more than that is rarely a real shopper.
• Device diversity: more than 20 distinct card numbers from one device or fingerprint in 24 hours.
• Decline window: a decline rate above 30 percent across a 10-minute window on a single endpoint.
• False positive budget: keep blocks under 0.5 percent of approved orders and measure that number weekly.

Pitfalls that waste money

• Blocking by IP alone. Proxy pools rotate fast, so a static IP list goes stale within hours.
• Trusting AVS and CVV as your main filter. Testers use valid card data, so those checks return clean.
• Country blocking. It stops some attack traffic and costs you legitimate orders from the same region.
• Ignoring free trials and account creation. Enumeration often starts there before it reaches checkout.
• Buying on price per decision without reading what counts as a decision. Some vendors meter every page view as a call.

FAQ

How fast does a card testing attack run?

A single automated run can push hundreds of attempts in minutes. Detection has to be real time. Batch review the next morning is reporting, not prevention.

Do I need a dedicated tool if my gateway already has fraud rules?

Start with the gateway rules and measure your decline rate, block accuracy, and manual review load for a month. Add a dedicated layer when the built-in rules cannot express the velocity and device logic you need, or when you sell across several gateways and want one policy.

What evidence should I keep for disputes?

Save request metadata: timestamp, device fingerprint, IP, ASN, user agent, order value, and the rule that fired. Issuers and processors ask for this when you contest fraud claims.