For most card-not-present merchants the top pick is a layered set of authorization controls: velocity limits on card numbers and IP addresses, CVV and AVS verification at authorization, and a hard rule that blocks a card after a failed verification attempt. That combination catches the small-value probe charges card testers depend on while keeping the false-positive rate low enough that normal customers still check out. The criteria behind the pick are coverage of every sales channel you run, detection measured in seconds instead of settlement cycles, friction low enough to protect conversion, and alignment with your PCI DSS obligations.

What credit card testing actually is

Someone holding a long list of card numbers does not know which ones are still open. So they run a tiny authorization, often under a dollar, against a merchant checkout page or a payment API endpoint, then read the response. An approval marks the card as live. Declines get discarded. The pattern shows up as volume, not as a single odd order: hundreds or thousands of attempts against many different card numbers inside a short window, frequently from a narrow set of IP addresses, device fingerprints, or email patterns. It is one of the cheapest forms of payment fraud to run and one of the most expensive to ignore, because each attempt carries an authorization cost and each approval tends to come back later as a chargeback.

Why card-not-present merchants are the target

Card testing needs an endpoint that will answer without a human in the loop. Subscription signups, guest checkout, donation forms, gift card purchases, and any payment API that returns a clear approve or decline response all qualify. Attackers favor merchants with weak bot defenses and loose velocity rules because a single working gateway can absorb thousands of probes before anyone notices. Damage arrives in layers: authorization fees, chargebacks, dispute ratio problems, possible placement in a card brand monitoring program, and the engineering time spent cleaning up.

Top pick: layered authorization controls

This is the default for good reason. You set rules on the number of authorization attempts allowed per card, per IP, per device, and per email within a rolling window, then require CVV and AVS matches before an order is accepted. Any card that fails verification is blocked rather than retried.

• Pros: stops the probe pattern at the gateway, adds almost no friction to real buyers, works across web, mobile, and API channels, and can be tuned in days.
• Cons: needs ongoing tuning as your traffic changes, can flag legitimate low-value or foreign orders, and does not stop an attacker who already holds valid card data and mimics normal browser behavior.

Alternative: 3-D Secure and strong customer authentication

Pushing authentication to the issuer removes the simple approve-or-decline feedback loop that card testers rely on. A stolen number with no matching authentication rarely completes.

• Pros: shifts fraud liability on covered transactions, blocks raw card numbers that cannot authenticate, and satisfies regional strong authentication rules.
• Cons: adds a step that some shoppers abandon, exemption logic takes work to get right, and determined attackers have adapted with automated one-time-passcode interception in some markets.

Alternative: bot defense and rate limiting at the edge

Rate limits, CAPTCHA challenges, and device fingerprinting cut automated volume before it reaches the payment page.

• Pros: fast to deploy, cheap relative to fraud losses, and effective against scripted tools that do not rotate infrastructure.
• Cons: residential proxy networks defeat simple IP rules, aggressive CAPTCHA hurts conversion, and determined operators rotate device signatures to look unique.

Alternative: machine learning fraud scoring

Scoring models weigh hundreds of signals per order and rank risk before authorization.

• Pros: adapts to new attack shapes, catches patterns rules miss, and reduces manual review load on large catalogs.
• Cons: needs transaction volume and labeled outcomes to train, behavior is hard for support staff to explain to a frustrated customer, and bad feedback loops can quietly train the model the wrong way.

Legitimate payment testing for merchants

Merchants also test credit card flows, and that work belongs in a sandbox. Use your gateway test mode with published test card numbers to verify approvals, declines, 3-D Secure challenges, refunds, partial captures, and webhook delivery. Never run a live transaction against a production card number you do not own or have written permission to charge. Test mode exists precisely so integration checks never touch real cardholder data, which keeps the activity inside your PCI DSS scope instead of outside it.

Use-case recommendation

If you run a small storefront with a single gateway, start with velocity limits plus CVV and AVS enforcement, because it covers the common attack at low cost. If you sell digital goods or subscriptions where a working card is worth more to an attacker, add 3-D Secure on top. If you already process meaningful volume and see constant low-level probing, put bot defense in front of the payment page and let a scoring model handle the rest. Large merchants typically run all four layers together.

What this guide does not cover

Nothing here explains how to check whether a stolen card number works, and it will not. Buying, selling, or validating card numbers you do not own is card fraud under federal law and carries real criminal exposure. If your own card was used in a testing attack, dispute the charge with your issuer and review your statements for small unfamiliar amounts, because those often come before a larger unauthorized purchase.