Card testing is an attack where someone submits many stolen card numbers through a merchant's payment form in small batches to learn which numbers still authorize. The merchant absorbs the damage: authorization fees on thousands of tiny attempts, chargebacks when the live cards are later used for real purchases, and risk-program fines if the volume gets bad enough. Detection is a data problem and containment is a configuration problem. Neither requires new infrastructure.

How Merchant Card Testing Works with CVV

Prerequisites

  • Access to gateway and processor transaction logs with timestamps, BIN, response codes, and IP.
  • Permission to change checkout rules, velocity limits, and CAPTCHA settings.
  • A named owner for fraud review during business hours and an escalation path after hours.

What a card testing run looks like

Testers rarely target a single large order. They spread attempts across many cards with small amounts, often under a dollar, and they favor endpoints that return a fast approve or decline without friction: guest checkout, saved-card update forms, free-trial signups, and gift card balance checks. A single run can produce hundreds of attempts in minutes from a rotating pool of IPs and device fingerprints. The tell is not one bad order. It is a shape in the aggregate data that does not match your normal customer behavior.

Synonym Merchant Card Assessment Process

Signals worth alerting on

  • Decline rate jumping well above your trailing baseline within a short window.
  • Clusters of orders under a low dollar threshold, especially with sequential or recycled email patterns.
  • Many distinct cards attempted from one IP, subnet, or device fingerprint.
  • Many distinct cards attempted against one customer account or one shipping address.
  • Card BIN country mismatched against IP country and billing address at scale.
  • Spike in card_declined, do_not_honor, or incorrect_number response codes in a short interval.
  • Disposable email domains concentrated in new-account signups.

Contain an active attack

  1. Confirm the pattern in gateway logs. Compare the last hour against the same hour on prior days.
  2. Rate-limit the exposed endpoint by IP, card fingerprint, and account, whichever dimension shows the cluster.
  3. Turn on CAPTCHA or a challenge step for the affected flow. Keep it on the checkout path, not the whole site.
  4. Block the source IPs and ASNs that account for the bulk of the attempts. Treat this as temporary.
  5. Require CVV and AVS on all card-not-present transactions if either is currently optional.
  6. Void and refund any test charges that authorized. Do not ship.
  7. Notify your acquirer or payment processor's fraud team the same day. Early notice protects you in a risk review.

Prevent the next run

  1. Set velocity limits per IP, per card fingerprint, and per account on every endpoint that accepts a card number.
  2. Add a minimum order amount or a challenge step for carts below your cost threshold.
  3. Require account creation or email verification before a card can be saved or a trial started.
  4. Enable 3-D Secure on high-risk segments. It shifts liability and adds friction the tester cannot script past.
  5. Fingerprint devices and block known bad signals at the edge, not in application code.
  6. Review your decline response text. Generic messages deny testers the confirmation they are paying for.
  7. Log every attempt, including declines, with IP, fingerprint, and BIN. Retain long enough to spot slow, low-volume runs.
  8. Run a monthly review of the rules. Testers adapt within weeks of any change.

Tune rules without blocking buyers

Aggressive blocking converts fraud losses into lost revenue. Start limits tight, watch false-positive volume for a week, then loosen one dimension at a time. Prioritize challenges over hard blocks on the checkout path, and reserve outright blocks for signals that almost never appear in legitimate traffic, such as dozens of distinct cards against one account in an hour. Document each rule with the date, the signal it targets, and the false-positive rate observed, so the next reviewer can tell a deliberate control from an accident.

related article