Card testing is a fraud pattern in which an attacker tries many card numbers against a payment system to find out which ones are valid. For merchants, the practical answer is detection plus prevention: rate limits, CAPTCHA, address verification, CVV checks, 3-D Secure, and monitoring for bursts of small failed authorizations. Card testing is not a victimless nuisance; it creates fees, chargebacks, service disruptions, and lost customer trust.

What card testing looks like

Card testing attacks often look like a sudden run of payment attempts that do not match normal customer behavior. The attacker may use one merchant account, many accounts, or a mix of stolen card data and automated tools. The goal is to learn which card numbers still work before using them for larger purchases or resale.

Common signs include:

• Many small authorization attempts in a short period.
• A high rate of declined transactions from the same device, IP range, or email pattern.
• Repeated checkout attempts with changed card numbers but similar billing details.
• Orders that use free email domains, mismatched billing and shipping data, or unusual order sizes.
• Traffic spikes on the payment page without matching traffic on product or account pages.

Some card testing is easy to spot. Other attacks blend in with normal traffic and show up only in decline reports, processor alerts, or chargeback data.

Why card testers target merchants

Card testers look for payment forms that allow repeated attempts with little friction. A weak checkout flow gives them fast feedback. If the payment page does not limit attempts, require authentication, or check cardholder details, it can become a testing ground.

Small and mid-sized merchants can be targets because their fraud controls may be simple. High-volume merchants can be targets because attackers can hide a small number of test transactions inside a large stream of real orders. In both cases, the damage goes beyond the test transactions themselves. Processors may add fees, hold funds, or require a fraud review. Chargebacks can follow if stolen cards are used later.

How merchants can detect card testing

Detection starts with watching authorization data and checkout behavior together. A single declined payment is normal. A pattern of declines tied to one device, one IP range, or one payment page session is worth review.

• Set velocity rules. Limit the number of payment attempts per account, card, device, IP address, and time window.
• Watch decline rates. Review spikes in declined authorizations, especially small amounts.
• Track device and network signals. Flag repeated attempts from the same browser fingerprint, proxy range, or unusual location.
• Review order details. Check for mismatched billing data, repeated email patterns, and shipping details that do not fit the customer profile.
• Use processor alerts. Payment providers and acquirers may send notices about fraud patterns tied to your account.

Keep logs long enough to investigate a pattern. Logs should show the time, result, device data, and order context without storing sensitive authentication data.

How to prevent card testing

Prevention should make testing slow, costly, and easy to detect. No single control stops every attack, so use several layers that fit your checkout flow and customer base.

• Rate limit payment attempts. Apply limits by session, account, card, and network signal.
• Add bot controls. Use CAPTCHA or similar challenges when behavior looks automated.
• Require card verification. Use CVV and address verification system checks for card-not-present transactions where supported.
• Use 3-D Secure. Strong customer authentication can reduce risk when it is available for your market and payment mix.
• Block high-risk signals. Review proxies, disposable email domains, and repeated failed attempts before they reach authorization.
• Do not store CVV data. Follow PCI DSS requirements and keep sensitive authentication data out of your systems after authorization.
• Monitor chargebacks. A rise in low-value disputes can point to earlier card testing.

Test each control before you enforce it. Overly strict rules can block real customers, so review false positives and adjust thresholds with care.

What to do after a suspected attack

If you suspect card testing, act on the pattern first. Stop the source if you can, preserve logs, and contact your payment processor or acquirer. Review affected orders, refund or void test transactions under your provider's guidance, and check for chargeback exposure.

Then review the checkout flow. Look for gaps in rate limits, bot controls, authentication, and address verification. Document what happened and what changed. If customer data may have been exposed, follow your incident response plan and applicable breach notification rules.

Legal and compliance notes

Card testing relies on stolen payment data. Merchants should treat it as fraud and follow card network rules, processor requirements, and applicable law. PCI DSS requires protections for stored, processed, and transmitted cardholder data. Using stolen card data is illegal, and the guidance here focuses on merchant defense and customer protection.