Card testing is a type of payment fraud in which someone uses automated scripts to push many small transactions through a checkout page with stolen card numbers, then watches which authorizations succeed. Each approved charge confirms a live card; each decline removes a dead one from the list. The goal is not the small purchase itself but the information the issuer's response reveals.

For merchants, card testing shows up as a sudden burst of failed authorizations, tiny order totals, and a jump in chargebacks weeks later. It is one of the more common automated attacks against online stores, and it can be detected and blocked with a combination of rate limiting, verification checks, and monitoring.

How card testing works

Stolen card data rarely arrives as a single number. Attackers work from lists of hundreds or thousands of records, often bought in bulk and of unknown quality. Running each one through a real payment form is the cheapest way to sort the list into working and non-working cards.

Because they need volume, attackers favor merchants with weak friction: guest checkout, no CAPTCHA, no card verification value (CVV) requirement, and no limit on attempts per session. They spread requests across many IP addresses, proxies, or residential networks so no single source looks unusual, and they often target low-value items, donations, or digital goods that need no shipping address.

Why the response matters more than the sale

An approval means the card is open and has funds available. A decline can still be informative, since issuers return different reasons for an expired card, a wrong CVV, or an insufficient balance. Attackers use those differences to refine the data they hold before selling it on or using it for larger purchases. That is why even a 100% decline rate can be a successful card testing run from the attacker's point of view.

Warning signs a store is being tested

  • A sharp rise in declined authorizations that is not matched by a rise in real orders.
  • Many orders at the same small amount, or amounts just under a fraud rule threshold.
  • Multiple card numbers used from one account, email address, or device fingerprint.
  • A high share of CVV or address verification (AVS) mismatches.
  • Traffic arriving from hosting providers, virtual private servers, or proxy networks instead of normal consumer connections.
  • Long strings of failed payment attempts followed by abandoned carts from the same session.
  • Order volume concentrated in a short window, often overnight relative to your usual customer base.

What card testing costs a business

Every authorization attempt has a price. Processors charge per transaction, and a high ratio of declines to approvals can push a merchant into monitoring programs or raise interchange costs. When fraudulent orders do go through, the merchant absorbs chargeback fees, loses the goods if they were digital or already shipped, and risks losing the payment account entirely after repeated violations. Repeated attacks also distort analytics, which makes inventory and marketing decisions less reliable.

Controls that reduce card testing

  • Rate limiting: cap payment attempts per IP address, device, session, and card, and slow down or block clients that exceed the cap.
  • Bot management: add a challenge such as CAPTCHA on checkout, or deploy a bot-detection layer that scores requests before they reach the payment form.
  • Require CVV and AVS: decline transactions when the verification value or billing address does not match, and make those fields mandatory rather than optional.
  • Strong customer authentication: apply 3-D Secure or an equivalent step-up challenge to transactions that score as risky.
  • Velocity rules: flag patterns such as many cards on one account, many accounts on one device, or repeated attempts on the same card.
  • Network filtering: block or challenge traffic from known proxy, VPN, and data center ranges where your customer base does not use them.
  • Monitoring: track authorization failure ratios and decline reasons daily so an attack is visible within hours rather than weeks.

Responding to an active attack

When the pattern is already underway, raise friction first and investigate second. Tighten attempt limits, turn on the checkout challenge, and temporarily require verification for all new customers. Contact your payment processor or acquirer so the activity is on record before chargebacks arrive, and preserve logs of the affected sessions. Review any orders that did get through, cancel shipments that have not left, and refund where appropriate. After the traffic subsides, keep the stricter rules in place for a while and review whether the attack exposed a gap in your checkout design.

What cardholders should do

Consumers usually learn about card testing through unfamiliar small charges or a fraud alert from their issuer. Review statements for charges you do not recognize, report them to the card issuer promptly, and request a replacement card number if unauthorized activity appears. Ignoring a small charge is risky, because a validated card is often used again for larger purchases.