If you are buying protection against card testing fraud, put authorization-time blocking and configurable velocity rules ahead of everything else in the evaluation. Card testing rarely hurts because one chargeback is large. It hurts because an automated script pushes thousands of small attempts through your checkout in a short window, which raises processing costs, pulls your approval ratios down, and hides genuine fraud inside the noise. The right vendor stops the attempt before the authorization request leaves your site and can show you the attack signature in your own traffic. A tool that reports the attack a day later is a reporting tool, not a defense.
What card testing fraud looks like in your data
Attackers buy lists of card numbers and need to learn which ones are live. They test in small amounts to avoid triggering issuer alerts, then resell or use the confirmed numbers. In merchant logs the pattern is recognizable once you know the shape of it.
- A spike in authorization attempts from a narrow set of IP addresses or ASNs.
- Clusters of low-value orders, often the same item, arriving within minutes.
- Many distinct card numbers used against a single customer account, email pattern, or device fingerprint.
- High decline rates on one payment page or one checkout endpoint while others stay normal.
- Sequential or patterned card numbers, including number generation that fails check-digit validation less often than random guesses.
What to look for in a vendor
Inline decisions, not batch review
The service should sit in the authorization path or in a pre-authorization call you control. Ask where the decision happens and what happens when the service is unavailable. A fail-open design lets the attack through during the exact moment it matters most.
Rules you can edit without a support ticket
You need to raise a threshold at 2 a.m. without waiting for an account manager. Look for a dashboard with self-service velocity rules, blocklists, and the ability to test a rule in shadow mode before it goes live.
Evidence you can hand to your acquirer
When your acquirer asks what happened, exportable logs with IP, device, card fingerprint, and timestamp carry weight. Vendors that keep only aggregate counts leave you explaining the spike with nothing concrete.
Coverage across channels
Card testing follows the weakest door. If you sell through a web store, a mobile app, and a phone channel, confirm the vendor covers each one rather than only the hosted checkout page.
Parameter bands that separate serious tools from basic ones
- Added decision latency: under 100 milliseconds is acceptable, under 50 milliseconds is strong. Above 250 milliseconds, expect cart abandonment during the attack window.
- Block rate during a confirmed attack: 90 percent or higher on the abusive traffic segment, measured against your own baseline, not a vendor-supplied average.
- False positive rate on legitimate orders: below 1 percent, and below 0.3 percent if your average order value is high or your customer base is small.
- Rule propagation time: under 5 minutes from edit to live enforcement. Anything measured in hours is too slow for a burst attack.
- Data retention: at least 90 days of searchable event logs, which matches typical chargeback and dispute windows.
Contract structures to expect
Pricing usually comes as a platform fee plus a per-event or per-transaction rate, and some providers fold the capability into existing gateway or risk tiers. Ask for the overage rate in writing, since attack traffic can multiply your event volume in a single day. Also ask whether blocked attempts are billable, whether the minimum term survives a downgrade, and what notice period applies. A month-to-month option costs more per unit but protects you while you validate the block rate against your own traffic.
Pitfalls
- Buying a chargeback alert service and calling it prevention. Alerts arrive after settlement and do nothing to slow an active attack.
- Setting a single global velocity cap. One threshold breaks high-volume legitimate customers before it catches a distributed attack.
- Ignoring the acquirer relationship. Repeated attacks can lead to monitoring programs or higher reserves even when your chargeback ratio stays inside limits.
- Trusting a vendor's published detection rate. Ask for a pilot on your traffic with a control group, then compare block rate and false positives yourself.
- Forgetting internal exposure. Stored payment data, test credentials, and staging environments are frequent entry points for the card lists used in testing.
FAQ
How fast does a card testing attack run?
A single burst can clear thousands of attempts in under 20 minutes. Response time matters more than reporting depth.
Can a CAPTCHA solve this alone?
No. It raises the cost of automation but does not stop scripted attacks against an API endpoint. Pair it with velocity and device signals.
Do I need a dedicated vendor if my gateway offers fraud tools?
Often not at first. Test the built-in rules with tighter thresholds. Move to a specialist when you need custom rules, faster propagation, or evidence exports your gateway does not provide.
What should I measure after 30 days?
Blocked attempts on the abusive segment, false positives on known-good orders, added latency at the 95th percentile, and the change in declined authorization volume.