Answer first

Buy card testing prevention as a layered control, not a single product. The layer that pays for itself first is velocity limiting on your own authorization traffic, which most payment gateways let you configure at no extra cost. The layer worth paying a vendor for is shared network data about card numbers, devices, and IP addresses already seen in attacks at other merchants, because your own logs stay quiet until an attack is well underway. If your decline data shows a narrow pattern, start with gateway rules. If it shows a wide one, start with a network-based vendor.

What to look for

  • Authorization-level visibility. The tool should read decline codes and attempt counts, not only order outcomes. Order-level analytics miss attacks that never complete a checkout.
  • Velocity controls you can tune by card fingerprint, IP address, device, email domain, and shipping address, with separate windows for minutes and hours.
  • Shared network signals. Ask how many merchants contribute data and how often the network refreshes. A small network gives you little that your own gateway does not already show.
  • Step-up options. Three-Domain Secure challenges, CAPTCHA, and email verification should be assignable by rule so you can challenge risky traffic without adding friction to normal buyers.
  • A stated latency budget for the decision call. Anything that adds delay inside the authorization path costs conversions.
  • Reporting that separates blocked attempts from converted orders, so you can see whether the tool is stopping attacks or turning away customers.

Parameter bands that hold up in practice

Treat these as starting points and tune against your own data.

  • Block or challenge after three or more authorization attempts from the same card fingerprint inside ten minutes.
  • Cap failed attempts per IP address at five to ten per hour for a typical retail catalog.
  • Flag orders under two dollars that use a new email domain and a device fingerprint with no history.
  • Require a challenge when the device and the card are both new to you and the order is the first from that account.
  • Keep any added decision latency under roughly 200 milliseconds when the check runs during authorization.
  • Review thresholds monthly. Attackers adapt to whatever you set and leave it alone.

Pitfalls

  • Assuming a CVV check is protection. Attackers testing cards already hold full card data, including the security code, which is why these attempts pass basic verification.
  • Blocking whole countries or free email providers. You lose real revenue and the attack moves to a different range within a day.
  • Ignoring the cost side. Chargeback fees, network dispute programs, and processing penalties often exceed the value of the fraudulent orders themselves.
  • Buying a tool with no test mode or sandbox. You cannot tune thresholds safely without one.
  • Setting rules once at launch and never revisiting them when traffic mix changes.
  • Choosing on price alone. A cheap vendor without network coverage leaves you doing the detection work yourself.

FAQ

Does card testing actually hurt a small store?

Yes. The immediate loss is usually small, but the aftermath is not. High decline ratios can raise your processing costs, and repeated fraud can lead to a merchant account review or termination.

Can a CAPTCHA alone stop it?

No. A CAPTCHA raises the cost of automation and helps against simple scripts, but attackers rent solving services and rotate proxies. Use it as one layer alongside velocity limits and network data.

How quickly should a block take effect?

Within the same hour, and ideally on the first attempt from a known-bad fingerprint. Delayed enforcement gives attackers a window to validate a batch of cards before you react.

Do I need a vendor if my gateway already has rules?

Only if your traffic is broad enough that in-house signals look normal until late in an attack. Run gateway rules first, measure what still gets through, then decide.