A card testing attack is a burst of low-value payment attempts that checks which stolen card numbers are live. The attacker sends many authorizations, keeps the approvals, and discards the declines. Each approved card is then sold or charged for a larger amount. The merchant pays the fees, the chargebacks, and the risk of losing the account.

How the attempt works

Most attempts follow a fixed pattern. The attacker holds a list of card numbers, often from a breach. Card numbers carry a check digit, so a script can keep only the strings that pass the Luhn check. The attacker then needs a live authorization response.

  • Card numbers are sent to a checkout page, a donation form, or a subscription trial.
  • Each attempt uses a small amount, often $0 to $2, to lower the chance of a fraud flag.
  • Approved cards are logged. Declined cards are dropped.
  • The list of live cards is sold or used for high-value orders.

Signals in your transaction data

Card testing has a distinct shape. It shows up as volume with a low approval rate, not as a few large orders.

  • Decline rate above 30 percent on one endpoint in one hour.
  • Several card numbers tried from one IP address or one device.
  • Card numbers that run in sequence or share the first six digits.
  • Billing and shipping data that do not match the card country.
  • Orders placed between midnight and 4 a.m. local time for the cardholder.
  • Many failed CVV or address checks on the same visitor session.

Pull the ratio of authorizations to settled transactions per hour. A sudden gap between the two is the clearest early warning.

Card testing and a BIN attack

The two terms overlap but are not the same. Card testing uses a list of full card numbers and asks which ones work. A BIN attack generates candidate numbers inside one bank identification number range and tests them in bulk. A BIN attack does not need a breach. It needs a payment endpoint and a script.

What the attack costs the merchant

Each approved test charge can become a chargeback. Card network rules hold merchants to a chargeback ratio threshold, and a spike can trigger monitoring programs and fees. Processors add their own penalties. A sustained spike can end in account termination, which is the largest cost for most sellers.

Card networks and acquirers also watch authorization-to-settlement ratios. A merchant with high authorizations and few settlements looks like a test bed, even when the merchant is the victim.

Controls that reduce exposure

  1. Rate limits. Cap attempts per IP, per device, and per card per hour. Apply the cap to the authorization call, not only to the page load.
  2. Velocity rules. Block a card that fails three times in 10 minutes. Block a device that touches more than five card numbers in a day.
  3. Address and CVV checks. Require a match on both for first-time buyers. Reject on mismatch for low-value orders.
  4. 3-D Secure. Send first-time and high-risk orders to the issuer challenge. Test scripts cannot complete it.
  5. CAPTCHA and bot signals. Add a challenge to the payment step when the session shows no mouse movement or a headless browser.
  6. Minimum order value. Set a floor of $1 or higher on card-not-present checkouts. Free trials and $0 authorizations are common test targets.
  7. Monitoring. Alert on decline rate and on the authorization-to-settlement gap. Route alerts to a person, not a dashboard.

Response steps after a spike

  1. Block the source IPs and device fingerprints for the window of the attack.
  2. Void authorizations that have not settled. Refund settled test charges before the cardholder files a dispute.
  3. Add the affected card ranges to a temporary blocklist if the pattern repeats.
  4. Contact the acquirer with the timeline and the volume. Early notice can keep the account out of a monitoring program.
  5. Review the endpoint that was hit and tighten its limits before restoring traffic.

Open questions

Numbers vary by processor and by card network. Published thresholds for chargeback programs change, and the exact ratio that triggers action is set in contracts, not in public documents. Check the current rules with your acquirer.