What is credit card testing?

Credit card testing is a fraud tactic in which someone runs a stolen card number through an online checkout to find out whether the card is still open. A small charge is enough. If the payment is approved, the attacker knows the number works and can use it for larger purchases before the cardholder or the bank notices.

The term has a second, harmless meaning. Developers also call it credit card testing when they run their own payment integration against sandbox card numbers that no bank backs.

How card testing attacks work

Attackers do not type card numbers by hand. They buy or steal lists of thousands of numbers, then use scripts to fire them at checkout pages in bulk. Each attempt costs the merchant an authorization request, even when the payment fails.

Card networks call this an enumeration attack or a BIN attack, because the attacker works through card numbers in bulk instead of picking targets.

Step 1: a small first charge

Testers pick a low amount, often under a dollar, or a donation field they can fill with any value. A one-dollar authorization tells them the card is live without drawing much attention.

Step 2: reading the response codes

Many gateways return separate response codes for the card number, the CVV, and the billing address. Attackers read those codes to learn which piece of data they have wrong. That is why a CVV mismatch is still useful to a fraudster.

Step 3: scale and resale

Working numbers get separated from dead ones and resold. Bots spread attempts across many IP addresses and merchants so that no single store sees an obvious pattern.

How merchants spot card testing

Card testing looks different from ordinary fraud. The stolen card is not the target of the purchase; the merchant's payment gateway is. That leaves fingerprints.

• A burst of small authorizations in a short window, many from the same IP range.
• High decline rates, especially declines that all return the same reason code.
• Checkout attempts from disposable email domains and free proxy services.
• Cards from a wide spread of banks and countries hitting one product page.
• Many failed payment form submissions with no other browsing activity on the site.

Small stores see this less as a flood and more as a trickle. That is why threshold alerts beat watching a dashboard by hand.

How to prevent card testing on your store

No single control stops card testing. Layered checks work because they raise the cost of each attempt. Most payment providers ship some of these as built-in tools.

1. Turn on fraud scoring. Stripe Radar, Adyen RevenueProtect, and similar tools score each payment on card, device, and behavior signals.
2. Require the CVV and the billing address to match. This will not stop every attack, but it kills the cheap ones.
3. Add 3D Secure for risky transactions. The extra authentication step shifts liability and blocks cards that cannot pass it.
4. Rate limit your checkout. Cap payment attempts per IP, per session, and per card in a rolling window.
5. Put a CAPTCHA or bot check on the payment step, not just the login page.
6. Block known proxy and data center IP ranges, and reject disposable email domains.
7. Set a minimum order amount, or flag orders under a threshold for review.
8. Read your authorization logs. A spike in declines is the earliest warning you get.

Test the controls yourself with a sandbox card and a known bad card to confirm each rule fires.

What legitimate credit card testing looks like

Payment providers publish sandbox card numbers for developers. Stripe's test cards, for example, produce specific outcomes such as a successful charge, a decline, or an authentication failure. These numbers belong to no cardholder and move no real money.

Decline codes in a sandbox let a developer check error handling without touching real accounts. That work happens in a test mode with separate API keys.

PCI DSS rules apply here. You must not copy production card data into a test environment. Keep sandbox and live credentials apart.

What to do if your site gets hit

1. Pull the gateway logs for the time window and the decline reason codes.
2. Block the IP ranges and card fingerprints behind the burst.
3. Contact your payment processor. They can raise risk thresholds on your account and have likely seen the same attack elsewhere.
4. Void or refund any captured test charges, and answer chargebacks with the evidence you have.
5. Add the missing controls before the next wave, because testers come back to stores that fall over.

Why card testing hurts the merchant more than the cardholder

The cardholder gets the charge reversed. The merchant pays. Each test charge that succeeds becomes a possible chargeback, and chargebacks carry fees on top of the lost sale.

Card networks track fraud ratios per merchant account. A high ratio can put you in a monitoring program, raise your processing rates, or end your ability to accept cards at all. That is the real cost of a card testing wave.

Frequently asked questions

Is credit card testing illegal?

Running someone else's card number through a checkout without permission is fraud and is a crime in the United States. Testing your own payment integration with sandbox numbers is normal developer work.

Does a small charge mean my card was stolen?

A tiny authorization you do not recognize is a common sign of card testing. Report it to your bank and check your statement for other charges.

Does CVV verification stop card testing?

It helps, but it is not a wall. Attackers who hold the full card data, including the CVV, pass that check. Velocity limits and fraud scoring catch what CVV checks miss.