A card testing procedure is a run of many small, rapid authorization attempts made against a payment gateway to learn which stolen card numbers are still active. The attacker is not trying to buy anything. They are reading the response codes. That is why the damage rarely shows up as one large fraudulent order and instead appears as hundreds of tiny ones.
Why card testing happens at all
Stolen card data loses value quickly. Issuers close compromised accounts, and a list that was valid last month may be dead today. Anyone holding a batch of numbers has a reason to sort the live ones from the dead ones before selling or using them.
- Separating valid numbers from invalid ones so a list can be sold at a higher price
- Confirming that a specific bank identification number range is still issuing active accounts
- Preparing a smaller, verified set of cards for a later cash-out attempt
Automation makes this cheap. Scripts can push thousands of attempts through a checkout page in minutes, and the merchant absorbs the authorization fees.
What card testing looks like on a merchant dashboard
Risk teams usually notice the pattern before they notice the money. Common signals include:
- A sharp jump in authorization attempts with no matching jump in completed orders
- Very low order values, often a few cents or a single inexpensive item
- Decline rates that spike far above the normal baseline for that gateway
- Many different card numbers arriving from one IP address or device
- One card number spread across many IP addresses, devices, or email addresses
- Billing details that do not match the card, with address verification and CVV checks failing repeatedly
- Traffic concentrated in hours when the merchant's real customers are asleep
- Checkout form fill times that are impossibly fast for a human
How detection actually works
Detection is a layered process rather than a single rule. Most processors combine several of these signals into one risk score:
- Velocity rules track how many attempts a card, device, email, or IP makes in a rolling window.
- Device fingerprinting links attempts that share hardware or browser characteristics even when the IP changes.
- AVS and CVV results are grouped and reviewed. A cluster of mismatches is a strong indicator.
- BIN analysis looks for attempts concentrated in a narrow set of issuer ranges.
- Behavioral signals measure typing speed, mouse movement, and time on page.
- Machine learning models compare live traffic against historical fraud patterns for that merchant.
Prevention controls that reduce loss
No single control stops card testing. Stacking a few of them raises the cost enough that attackers move on.
- Apply rate limits per IP, device, and card, and throttle rather than only block.
- Add a challenge such as a CAPTCHA to the payment step when risk scores are elevated.
- Enable 3-D Secure so the issuer, not the merchant, authenticates the cardholder.
- Require CVV and address verification on all card-not-present orders.
- Review or block authorization attempts below a minimum order value for new or unverified visitors.
- Maintain a blocklist of abusive IPs, devices, and email domains, and refresh it regularly.
- Monitor authorization logs daily so a spike is caught in hours, not weeks.
- Keep your payment processor's risk team informed so they can adjust rules on their side.
If you think you are being tested right now
Move quickly and in this order: confirm the spike in your gateway's authorization log, identify the shared attributes across the attempts, tighten velocity limits, turn on an additional challenge at checkout, and notify your processor. Then review whether any of the attempts resulted in a shipped order and stop fulfillment on those. Documenting the timeline helps if the activity later triggers a dispute review.
Why speed matters beyond the immediate loss
Card networks monitor merchants for excessive fraud and dispute activity. A sustained testing attack can push a business into a monitoring program, and the resulting fees and reserves often cost more than the fraudulent orders themselves. A card testing procedure is cheap for the attacker and expensive for everyone downstream, which is why preventive controls pay for themselves even when they occasionally flag a legitimate customer for review.