What a card test is

A card test is a transaction run for the purpose of confirming that a card number is live and has available funds. The attacker is not buying the product. They are buying information: a yes or no from the payment network. Once a number is confirmed, it is sold or used for a larger purchase.

Card testing is a merchant-side problem, not a shopper-side one. The charge lands on your store, your processor, and eventually your chargeback ratio. In 2026, most tests arrive through automated scripts against checkout pages, payment APIs, subscription sign-up forms, and donation widgets rather than through a browser a human is watching.

Why 2026 attacks look different

Three shifts matter. First, bots now spread attempts across many IP addresses and many card numbers at once, so no single card or device stands out. Second, attackers reuse legitimate-looking email domains and residential proxies, which weakens old geo-blocking rules. Third, low-value authorizations of a few cents to a few dollars clear fraud screens that only look at order size.

Signals that a card test is in progress

• Authorization attempts jump while completed orders stay flat.
• Decline rates climb inside a narrow window, often at night.
• One IP address or device fingerprint touches many different card numbers.
• One card number appears across many IP addresses or many email addresses.
• Billing address and cardholder name data repeat with small variations.
• Order values cluster at the minimum your gateway allows.

How to stop a card test attack

1. Pull authorization logs for the last 72 hours and group them by IP address, device fingerprint, email address, and card fingerprint.
2. Flag any group that shows more than five attempts in an hour from a single source.
3. Enable a bot challenge on checkout and on every form that reaches your payment endpoint.
4. Require the card verification value on all transactions, including card-not-present renewals.
5. Turn on 3-D Secure for high-risk regions and for any customer with no purchase history.
6. Add a block rule for repeat declines from the same device or IP range.
7. Rate limit the payment endpoint by IP, session, and device token.
8. Set an alert that fires when your decline rate moves more than two points in an hour.
9. Void or refund the small unauthorized charges and send the card fingerprints to your processor's fraud team.

What to check afterward

Confirm that you never store the card verification value after authorization. Confirm that your refunds and voids are logged with the reason code so the processor can see the pattern. Confirm that the blocked source list is reviewed weekly, because a hard block that stays in place for months will turn away real customers.

Small authorization probes are cheap for the attacker and expensive for you. The response is not a single setting. It is velocity limits, bot detection, and a review loop that runs every day the store is open.