Card Testing Attack Defense: What to Buy First

Buy detection where the attack happens: at the authorization layer, not in the dispute queue. A card testing attack is a burst of automated authorization attempts with stolen card numbers, usually for small amounts, and it shows up first as a shift in your approval rate and decline mix. When you compare tools, prioritize a gateway or fraud platform that gives you per-card, per-IP, per-device, and per-email velocity rules plus real-time authorization rate alerting. Chargeback alerts and dispute automation are a second line of defense, and they arrive weeks after the test run has already mapped which numbers work.

What to look for in a fraud stack

  • Velocity controls at the card BIN, card number, IP, device, email, and shipping address level, with rules you can edit without a support ticket.
  • Real-time decline monitoring that separates issuer declines from your own risk rules, so you can tell a bot run from a bad gateway configuration.
  • Bot defense at the edge: TLS fingerprinting, JavaScript challenges, and rate limits on checkout and account lookup endpoints.
  • Verification you can turn on per market: CVV and AVS checks, plus 3D Secure step-up for high-risk traffic instead of blocking everything.
  • Alert latency and webhook support, so your team can react in minutes and your own systems can auto-throttle.
  • Sandbox access on your own traffic volume before a contract, because a tool that works on a demo store may not hold up on a real catalog.

Parameter bands worth using in your evaluation

  • Per-card attempt limits: single digits within a 10 minute window. Test runs are automated and repeat fast, so tight windows catch them earlier.
  • Ticket size watch band: flag orders under $5 on digital goods, where test charges tend to land.
  • Authorization rate shift: track your own baseline for a week. A drop of 15 percent or more inside a short window is a signal, while normal daily swings often sit in the 3 to 8 percent range.
  • Alert latency: under 5 minutes for authorization anomalies, within an hour for order pattern changes.
  • False positive ceiling: keep blocked legitimate orders under about 1 percent of approved volume, or you will trade fraud losses for lost revenue.
  • Step-up share: aim to keep 3D Secure friction on a minority of traffic and tune from there.

Pitfalls that cost merchants money

  • Buying only chargeback alerts. They confirm the attack weeks late and do not stop the enumeration.
  • Leaning on CAPTCHA alone. Scripted tools solve or outsource it, and the rest of your checkout stays open.
  • Ignoring free trials, gift card purchases, and account balance lookups. These endpoints get tested too.
  • Assuming PCI compliance equals fraud protection. Compliance governs how you store card data, not who is hammering your form.
  • Signing an annual contract before running a trial on live traffic with your own decline data.
  • Skipping internal logging. Without request logs tied to order IDs, you cannot tell a test run from a marketing spike.

FAQ

What is a card testing attack?

It is an automated run of small authorization attempts against stolen card numbers. The attacker watches which attempts approve, then uses or resells the working numbers. Merchants see it as a spike in declines, extra gateway fees, and later chargebacks.

Why do the charges stay small?

Low ticket sizes often slip under issuer and merchant review thresholds. That is why order value alone will not flag the attack, and why velocity and decline pattern matter more.

How fast does it happen?

Often within minutes. Bots distribute attempts across many IP addresses, so a per-IP limit by itself rarely stops the run.

Is card testing the same as account takeover?

No, but they overlap. Account takeover targets logins and stored payment methods, while card testing targets the payment form. A stack that covers both should share device and velocity signals.

What is the fastest low-cost improvement?

Require CVV and AVS, add edge rate limits on checkout, and set up an alert on authorization rate change. Those three steps catch most automated runs before chargebacks start.