A card testing alert is a warning from your payment processor, gateway, or fraud vendor that your checkout is handling a burst of authorization attempts with stolen card numbers. The attacker runs many small charges to learn which cards still work. The alert fires when your decline rate, attempt velocity, or BIN diversity crosses a threshold your provider set.

What Triggers a Card Testing Alert

Providers watch several signals at the same time, and an alert usually means two or more moved together.

  • Velocity: many authorization attempts in a short window from a small set of IP addresses or devices.
  • Amount pattern: clusters of authorizations between $0.00 and $1.00.
  • Decline ratio: a spike in issuer declines, do-not-honor codes, or soft errors.
  • BIN spread: hundreds of card prefixes hitting one checkout form.
  • Geography mismatch: billing country and IP country differ on most attempts.
  • Cardholder name and address fields filled with junk or repeated values.

Prerequisites

  • Access to gateway transaction logs with IP, device, and BIN fields visible.
  • Admin rights in your fraud rules engine or payment orchestration layer.
  • Phone and email contacts for your acquirer fraud desk.
  • A saved baseline of your decline rate for the prior 30 days.

How to Respond to a Card Testing Alert

  1. Pull the last 24 hours of authorization records and sort them by timestamp.
  2. Compare the current decline rate to the 30 day baseline to confirm the spike is real.
  3. Group the attempts by IP address, device fingerprint, and card BIN.
  4. Block the top offending IP ranges and autonomous system numbers at your edge firewall or WAF.
  5. Set a velocity cap on the payment endpoint, such as five attempts per ten minutes per IP.
  6. Require CVV and AVS on every transaction submitted through the affected form.
  7. Enable 3-D Secure for high-risk BIN ranges and for any order under one dollar.
  8. File a fraud report with your acquirer and attach the source IP list.
  9. Export and archive the raw logs before your retention window closes.
  10. Recheck the blocked traffic after 48 hours and remove any rule that caught real customers.

What to Send Your Acquirer

Give the fraud desk a compact package: the time range of the attack, the count of attempts, the top 20 source IPs, the BIN ranges used, and the total value of any authorizations that settled. Note which rules you added and when. This record supports chargeback representment later if stolen cards processed before you blocked the source.

Prevention After the First Alert

  • Keep a minimum order value above the typical test amount.
  • Rate limit the checkout API separately from the storefront.
  • Alert on decline rate change daily instead of weekly.
  • Review your reCAPTCHA or bot defense coverage on the payment page.
  • Recheck fraud rules each quarter against new traffic patterns.