Answer

Card testing is a fraud pattern where someone sends many small authorization requests to learn which card numbers are live. Merchant rules for detecting it use velocity limits, amount limits, BIN ranges, CVV and AVS results, and 3-D Secure. Card networks add monitoring programs with numeric fraud and dispute thresholds.

Signals in the transaction log

  • Hundreds of authorization requests from one IP address or device in a few minutes.
  • Amounts from $0.00 to $1.00, or one amount repeated across many cards.
  • Decline rates above 70% on one merchant account.
  • Sequential BIN numbers and sequential last-four digits.
  • CVV and AVS mismatches on most attempts.
  • Cardholder names that do not match AVS data.
  • One email domain with random local parts, such as a1234@ and a1235@.

Merchant rules that block testing

Velocity

Count authorization attempts per IP, per device fingerprint, per card BIN, per email, and per shipping address inside a rolling window. Set a hard cap. Common caps: 5 attempts per card per hour, 20 attempts per IP per hour, 3 attempts per card per day. Block at the cap instead of declining.

Amount rules

Testing uses small amounts because a decline costs the attacker nothing and a small approval costs little. Set a floor for card-not-present orders. Reject or hold any authorization below $1.00 unless the merchant sells items at that price.

BIN and card number rules

Block BINs that do not match your customer base. Flag multiple cards from the same BIN on one account in one day. Reject card numbers that fail the Luhn check.

CVV and AVS

Reject on CVV mismatch. Reject on full AVS mismatch. Do not allow retries with the same card after a CVV failure. Each retry is a new test.

3-D Secure

3-D Secure moves liability to the issuer for authenticated transactions. Attackers cannot pass the challenge in most cases, so the test fails at the issuer instead of at your checkout. Apply 3DS to high-risk segments first if friction is a concern.

Network programs and thresholds

Visa and Mastercard run separate monitoring programs. The figures below are published figures and change over time. Confirm the current numbers in the program guides.

  • Mastercard Excessive Chargeback Program: 100 chargebacks and a 1.5% chargeback-to-transaction ratio in one month.
  • Visa Dispute Monitoring Program: 100 disputes and a 0.9% dispute ratio in one month, or 1,000 disputes.
  • Visa Fraud Monitoring Program: a fraud-to-sales ratio above a set percentage plus a fraud dollar amount above a floor. Both tests must be met for a merchant to enter the program.

Steps after a testing attack

  1. Pull all authorizations in the window and list the IPs, devices, BINs, and emails.
  2. Block the confirmed identifiers and the card numbers used.
  3. Void or refund approvals that came from the test.
  4. Report the card numbers to the acquirer and the issuer.
  5. File a complaint with the FTC if you have losses.
  6. Add the pattern to the rule set and re-test.

Limits of rule-based detection

Rules need maintenance. Attackers rotate IPs and use residential proxies, so an IP block list ages fast. A rule set with no review window misses new patterns. Review the rule set each week at minimum. Tight rules also cause false declines on real customers, so track the decline rate for good traffic next to the block rate for bad traffic.