Card testing is a fraud pattern in which someone runs low-value authorization attempts against a list of stolen card numbers to learn which ones still work. The disputes that follow arrive as chargebacks, usually weeks later and usually in a cluster. The single most effective control is real-time velocity and BIN-attack rules that catch the burst before it settles, backed by issuer authentication on whatever traffic survives the first filter. Each option below is judged on four criteria: how early it catches an attack, how much manual review it adds, how it treats legitimate repeat customers, and how well it holds up at volume.

What card testing looks like in your transaction log

Attacks are not subtle once you know the shape of them. A fraudster takes a purchased or leaked list of card numbers and pushes them through your checkout, one small charge at a time, to sort live cards from dead ones. The approvals get resold. The declines get discarded. Your gateway sees the whole thing.

  • Many orders in a short window from a small set of IP addresses or device fingerprints
  • Low order values, often the cheapest item on the site or a donated amount
  • Sequential or near-sequential card numbers, which is the signature of a BIN attack
  • Email addresses built from random strings, or one mailbox with hundreds of plus-addressed variants
  • Billing and shipping details that do not match the card's issuing country
  • A spike in authorization attempts with a collapse in the approval rate, since most tested cards are dead

Zero-value and one-dollar authorizations are the cheapest version of the attack, because a fraudster can validate a card without moving real money. Watch for those as closely as you watch for sales.

Why card testing turns into chargebacks

An authorization approval is not a cardholder approval. It only means the issuer placed a hold on available funds at that moment. Nothing in the authorization message proves the person typing the number is the account holder. The real cardholder finds an unfamiliar charge on a statement, does not recognize it, and files a dispute. The issuer rules in their favor because the merchant cannot show a signed authorization or a delivered product.

In card-not-present cases these disputes land in the standard fraud categories, such as Visa reason code 10.4 for fraud in a card-absent environment and Mastercard reason code 4837 for no cardholder authorization. Volume matters as much as the individual cases. A merchant that processes a large run of tested transactions can also draw attention from the card networks' fraud monitoring programs, which brings fees and remediation requirements on top of the disputed amounts.

Option 1: Velocity and BIN-attack rules

These are the rules you write in your payment gateway or fraud tool. They count attempts per card, per IP, per device, and per email over rolling windows, and they block when the count crosses a threshold. BIN-level rules catch the pattern where dozens of cards from the same issuing range hit the site within minutes.

Pros

  • Fires on the first few attempts, before most of the stolen cards are validated
  • Runs in milliseconds and does not add friction to normal checkout
  • Catches zero-value authorizations, which never reach a sales-based fraud review

Cons

  • Thresholds need tuning, and a promotional spike can look like an attack
  • Shared IP addresses, such as corporate networks or mobile carriers, create false positives
  • Sophisticated attackers rotate proxies and slow the rate to stay under the limit

Best for: every merchant that accepts cards online, as the first layer. It is the cheapest control per blocked attempt.

Option 2: Issuer authentication

Issuer authentication, commonly delivered as 3-D Secure, redirects the cardholder to the issuing bank for a verification step during checkout. The bank returns an authentication result that shifts liability for most fraud chargebacks to the issuer in covered cases.

Pros

  • Liability shift removes a large share of card-not-present fraud disputes from your ledger
  • Fraudsters with stolen numbers usually cannot pass the bank's check
  • Exemptions and risk-based rules let low-risk traffic skip the challenge

Cons

  • Added checkout steps cost conversions, and the loss is hard to measure precisely
  • Integration work and rule configuration are ongoing, not one-time
  • Coverage varies by region and by issuer, so it is not a complete shield

Best for: merchants with a high average order value or a rising fraud dispute ratio, where the liability shift outweighs the checkout friction.

Option 3: CVV and address verification

These are the data checks inside the authorization request. The CVV result tells you whether the three or four digit code matched. Address verification compares the billing street and postal code against what the issuer holds.

Pros

  • Free or near-free, since the results ride along with the authorization message
  • Rejects bulk-tested card numbers, which rarely come with a matching code
  • Useful as a scoring input rather than a hard block

Cons

  • Some legitimate customers mistype the code, especially on mobile
  • Some issuers do not return full results, so the fields can come back blank
  • Rule-based rejection on a single mismatch drops real sales

Best for: merchants who want a low-cost signal folded into a broader risk score, not used as the only gate.

Option 4: Dispute deflection programs

Deflection services intercept a dispute before it becomes a chargeback and either refund it automatically or let you contest it inside the network's alert system.

Pros

  • Removes the chargeback fee and keeps the case out of your dispute ratio
  • Handles the long tail of individual disputes that detection rules miss
  • Reduces manual evidence collection for obvious refund cases

Cons

  • Costs a fee per resolved case on top of the refund itself
  • Does not stop the attack, only softens the fallout
  • Coverage depends on the networks and processors you work with

Best for: merchants already absorbing steady dispute volume who want to protect their ratio while fixing the root cause.

Recommended stack by use case

Small store, first attack

Start with velocity and BIN-attack rules, add CVV and address verification as scoring inputs, and review the blocked list daily for a week.

Growing store, rising dispute ratio

Add issuer authentication with risk-based challenges so low-risk buyers skip the step, then layer dispute deflection on the residual cases.

High-volume store with a dedicated risk team

Run all four. Use issuer authentication for liability shift, rules for speed, data checks for scoring, and deflection to cap the damage while you close the gap.

The first hour of an active attack

  1. Pull the last 24 hours of authorization attempts and group them by IP, device, and card BIN.
  2. Block the offending ranges and fingerprints at the gateway, not just in the review queue.
  3. Disable guest checkout temporarily if the attack is using it as the entry point.
  4. Void or refund unsettled approvals tied to the attack so the goods never ship.
  5. Log the pattern, then write a rule that would have caught it at attempt number three.

Card testing costs you twice: once in the goods or refunds, and again in the disputes that arrive a month later. Detection decides the first cost. Your dispute process decides the second.