What card testing defense means

Card testing defense is the set of controls that stop an attacker from running many small authorization attempts against a payment page to find live card numbers. The stack has four parts: rate limits on the request path, friction on high-risk endpoints, issuer checks such as CVV and AVS, and velocity rules that block bursts. The aim is to raise the cost of each attempt and cut the volume before the processor sees it. Card testing shows up as declines, not as sales, so teams that watch revenue alone miss it.

How an attack looks in the data

  • Hundreds of authorization attempts in minutes from one IP or a proxy pool.
  • Amounts from $0.50 to $5.00, or a zero-dollar authorization to verify a card.
  • Many BINs on one device, one email, or one session cookie.
  • Decline rate above 90% on the checkout endpoint.
  • A drop in average order value with a rise in attempt count.
  • Orders for gift cards, digital codes, or items with no shipping address.

Cost to a merchant

Every attempt can carry an authorization fee. Processors quote fees from a few cents to about $0.30 per authorization, and the attacker pays nothing. Networks then count the fraud and disputes against the merchant. Visa's Acquirer Monitoring Program (VAMP), effective April 1, 2025, tracks a combined fraud and dispute ratio and a monthly count of fraud and dispute transactions. Merchants and acquirers above the threshold pay fees and face review. Chargebacks add a fee per case, in the range of $15 to $25, plus the lost goods.

Controls to deploy

  1. Rate limit by IP, device fingerprint, email, and card BIN. Set a low ceiling per minute and per hour.
  2. Require CVV and run AVS on every card-not-present order. Reject a CVV mismatch.
  3. Trigger 3-D Secure on high-risk orders or on all orders during an active attack. Liability shifts to the issuer when authentication succeeds.
  4. Set a minimum order value on the checkout page. Most testers use small amounts.
  5. Add a CAPTCHA or a challenge on the payment step, not just on the login page.
  6. Block known proxy ranges, datacenter ASNs, and repeat device IDs.
  7. Review rules after each attack. Attackers rotate proxies and user agents.

Signals to log

Keep the fields that separate a buyer from a tester: IP, ASN, device fingerprint, email domain age, BIN, card country, billing country, time between attempts, and user agent. A rule that fires on three decline outcomes from one device in ten minutes catches most low-effort attempts. A rule on BIN diversity catches the rest.

What to do during an attack

Block the source at the edge, raise friction on the payment endpoint, and call the processor. Ask for the decline codes tied to the burst. Then check the rule set against the log fields. No single control is complete. Attackers use residential proxies and CAPTCHA-solving services. Layered controls add cost, delay, and risk to the attacker, which is the point.