What Is Card Testing Fraud? How to Detect and Stop It

What is card testing fraud?#

Card testing fraud uses a merchant's checkout or payment form to find out whether stolen payment-card details still work. The attacker submits a small authorization or a low-value order. An approval confirms that the card is active; a decline helps the attacker discard it or adjust the next attempt.

The merchant is being used as a validation service. The purchase itself may have little value, while the confirmed card details can support fraud elsewhere. hCaptcha's card-testing guidance describes the resulting disputes, chargeback fees, and authorization costs that merchants can face.

Card testing attacks usually rely on automation. Scripts can change card details, amounts, devices, or network routes faster than a person at a checkout form. A small number of attempts may resemble ordinary payment failures. A coordinated pattern is different: the traffic is designed to learn which stolen cards remain usable.

Card testing and PAN enumeration are different attacks#

Card testing begins with card details that an attacker believes may already be valid. The attacker sends those details to a merchant to confirm their current status.

Primary Account Number (PAN) enumeration has a different starting point. The attacker generates or guesses payment-card values, then combines possible account numbers with expiration dates and verification values until a transaction succeeds. Both attacks can produce a stream of low-value authorizations, but the underlying data and the attacker's goal differ.

That distinction matters during an investigation. A card-testing campaign can indicate that stolen credentials have reached the merchant's payment flow. Enumeration can reveal attempts to construct valid details through repeated guesses. Detection needs the transaction fields, request behavior, and authorization outcomes together.

What card testing looks like in payment traffic#

Card testing fraud leaves patterns in the checkout flow and the authorization response. Watch for rapid, low-value attempts; a burst of identical requests; repeated changes to one payment field; and a sharp rise in declines or specific decline codes. Issuer or payment-brand authorization mismatches can add another signal.

The same request pattern can appear through one IP address or be spread across proxies, devices, and accounts. A basic threshold may catch a noisy script, while a slower campaign stays below a single limit. Compare the payment attempt with the account, session, device, network, basket, and earlier checkout activity.

Fraud teams should also examine what happens after an authorization. Repeated cancellations, address changes, new accounts, unusual promotion use, and chargebacks can show that the payment attempt belongs to a wider fraud operation.

How credit card fraud affects businesses#

Card testing creates costs before a fraudulent order is fulfilled. Each authorization can consume payment-processing capacity and produce fees. Large volumes of declines can also distort payment metrics, trigger processor scrutiny, and make it harder for teams to recognize legitimate checkout problems.

When a tested card is later used successfully, the merchant may face the order loss, a dispute, a chargeback, and investigation work. Customer trust can also suffer when a payment account was used at a merchant that did not stop the testing traffic early enough.

How to stop card testing attacks#

Start with the payment flow itself. Protect checkout, payment-method updates, saved-card checks, gift-card balance queries, and any endpoint that can reveal whether payment data is valid. Apply appropriate request controls before the payment processor receives a large volume of attempts.

Rate limits remain useful, especially when they account for more than one key. Review limits across device, account, session, payment instrument, request shape, and network. Add bot detection so a valid-looking request is evaluated for automation and intent before it reaches a sensitive payment action.

Use payment-specific rules for amount, authorization velocity, decline pattern, country, merchant category, retry behavior, and changes to the checkout journey. The response can slow an uncertain pattern, request verification, hold an order, block the request, or send it for review. Keep the reasons and outcomes with the transaction so analysts can tune the rule after the incident.

Recovery matters too. When card testing is confirmed, preserve the affected requests and payment outcomes, review related orders or accounts, and work with the payment processor and issuer through the appropriate incident process. The goal is to close the attack path while avoiding a broad rule that rejects normal customers.

How hCaptcha supports card testing fraud prevention#

hCaptcha Bot Detection evaluates behavior, device signals, network context, and intent across checkout and other sensitive actions. Its Rules Engine can allow, challenge, re-score, or deny activity in real time, so teams can add friction when evidence supports it.

hCaptcha Fraud Protection adds transaction-specific risk scoring, fraud-focused models, tailored rules, and transaction review. It supports blinded transaction data, which lets an organization send relevant payment context without giving hCaptcha raw personal data. Together, the bot and fraud layers can connect checkout traffic with the payment signals that identify card testing.

The hCaptcha Transaction Fraud page explains how those signals and controls extend across the transaction journey.

Frequently asked questions#

What is card testing?

Card testing is an attempt to validate stolen payment-card details through a merchant's payment flow. Small authorizations or low-value orders reveal whether a card is still active.

Is card testing the same as credit card testing fraud?

Yes. Credit card testing fraud and card testing describe the use of merchant payment systems to check stolen card details. The wording varies, but the merchant-side risk is the same.

How do credit card companies detect fraud from card testing?

Issuers, payment networks, processors, and merchants can each see part of the pattern. They look at authorization attempts, decline results, amount, location, account and device context, timing, and later disputes or chargebacks.

What does suspected fraud mean on a card?

The meaning depends on the issuer, processor, or merchant that applied the label. It usually means the payment or account activity matched a risk signal that needs review, verification, or a restriction before the transaction proceeds.

Can rate limiting stop card testing attacks?

Rate limits can slow repeated requests, especially noisy attacks. Broader controls are needed when a campaign rotates devices, accounts, networks, or payment details to remain below one threshold.