Buy monitoring that scores every authorization attempt in real time and links it to a device fingerprint and a network identity. Rate limits alone fail against distributed card testing, where a botnet spreads a few attempts across thousands of IP addresses. The product you choose should alert on decline-rate spikes within minutes, let you block by card BIN, IP, device, email domain, and customer ID at the same time, and offer a sandbox where you can replay a burst without touching live traffic. If a vendor cannot show you sub-hour alerting and a working test mode during the evaluation, stop there.

What card testing looks like from the merchant side

A card tester buys a list of card numbers and runs small authorization attempts, often $0 to $2, to learn which numbers are live. The valid ones get resold or used for larger purchases. On your end the pattern shows up as a jump in authorization attempts, a low average order value, a high decline rate, many cards per single IP or device, and a wave of small refunds or chargebacks weeks later. Because the attackers only need the authorization response, they often abandon checkout before shipment, which means fraud rules built around order fulfillment will miss them.

What to look for in a monitoring product

Detection signals

• Attempt-level scoring, not just order-level scoring, since many test attempts never become orders.
• Velocity counters that reset on a rolling window and combine card, IP, device, and account in one rule.
• BIN and issuer country checks with the ability to compare billing country against IP geolocation.
• Device fingerprinting that survives cookie clearing, plus proxy and hosting provider detection.
• Behavioral signals such as time between form fields, pasted card numbers, and headless browser markers.

Response and controls

• Blocking and allowlisting at the rule level with a documented change log.
• Step-up authentication triggers, such as 3D Secure challenges, for medium-risk attempts.
• Direct API access so your support team can release a false positive without opening a vendor ticket.
• Retry logic that does not penalize legitimate customers who mistype a card number.

Reporting and evidence

• Dashboards that show attempts, declines, and blocked volume side by side.
• Exportable logs with timestamps and request identifiers you can hand to your acquirer.
• Chargeback and dispute correlation so you can trace a loss back to the test run that caused it.

Parameter bands that hold up in practice

Treat these as starting points and tune them against your own baseline.

• Alert threshold: a decline rate two to three times your trailing 30-day average, sustained for 10 minutes.
• Attempt velocity: more than five authorization attempts from one IP in 60 seconds, or more than three cards from one device in an hour.
• Value floor: attempts under $2 with no shipping details warrant a second look.
• Review queue: cap automated blocks so you review at least a sample of every rule each week.

Pitfalls

• Buying only a rule engine. Detection without fast response gives you better documentation of the loss, nothing more.
• Setting thresholds once. Testers rotate infrastructure, so revisit limits monthly.
• Ignoring the acquirer side. Card network fraud programs watch your fraud-to-sales ratio, and a spike can change your processing costs.
• Blocking entire countries or hosting ranges. This hurts legitimate customers and pushes attackers into ranges you have not covered.
• Skipping logging. Without attempt-level logs you cannot prove a burst happened when a dispute arrives.

FAQ

Does 3D Secure stop card testing?

It reduces it. Testers usually prefer merchants without a challenge because it slows them down and adds cost. Applying 3D Secure to risky attempts only keeps conversion higher for good customers.

How fast should alerts arrive?

Minutes. A run can burn through thousands of attempts in under an hour, so a daily digest is too slow to change the outcome.

Should I block the whole IP range?

Rarely. Block the specific signals first, then widen only if the same range keeps returning after a block.

What evidence should I keep?

Attempt timestamps, card BIN, IP, device identifier, the rule that fired, and the outcome. Keep it for the period your acquirer and card network rules require.