Category: Fraud Typologies

Card Testing

Also known as: Card Testing Attack, Carding

Simply put

Card testing is a type of fraud where someone uses stolen card numbers to check whether those cards are still active and usable, often before attempting larger purchases. The attacker typically submits many small or low-value transactions to see which cards are approved. Cards that succeed are then used or sold for further fraudulent activity.

Formal definition

Card testing is a fraudulent activity in which an actor submits stolen or acquired card credentials, frequently in high-volume automated attempts, to validate which cards are active and can be authorized. Validation is often performed via small-value or authorization-only transactions against a merchant's payment flow, with the goal of confirming a card is 'live' before the actor uses or sells the validated data. Because the objective is to reach the acquirer for authorization, mitigation is generally aimed at detecting and blocking testing patterns at the merchant layer before requests are forwarded for authorization. Detection controls such as velocity checks and anomaly monitoring may help reduce card testing but involve false-positive and false-negative trade-offs, and specifics depend on implementation. This term describes an attack technique and should not be confused with legitimate 'test card numbers' used in a sandbox environment to simulate transactions during development.

Why it matters

Card testing is often an early stage in a broader fraud lifecycle rather than the endpoint of an attack. By confirming which stolen card numbers are still active and usable, an actor produces validated data that can then be used for larger fraudulent purchases or sold to others. This means a successful wave of card testing against one merchant can seed downstream fraud that surfaces across many other merchants, making the technique a shared concern across the payments ecosystem rather than an isolated merchant problem.

For the merchant that is used as the testing ground, the impact goes beyond any individual fraudulent charge. High volumes of authorization attempts can generate processing costs, trigger disputes and chargebacks on transactions that were approved, and draw scrutiny from acquirers and card networks whose rules govern chargeback handling and merchant risk. Because the objective of the attacker is simply to reach the acquirer for an authorization decision, the merchant's payment flow becomes the vehicle for validating stolen data even when the merchant itself was never the source of that data.

The practical significance for defenders is that card testing is best addressed before requests are forwarded for authorization. Detection and blocking at the merchant layer is where the technique can be interrupted, but the controls used to do so carry trade-offs. Velocity checks and anomaly monitoring may help reduce card testing, yet they can produce both false positives that block legitimate customers and false negatives that let testing patterns through, and their effectiveness depends heavily on how they are implemented and tuned.

Who it's relevant to

Merchants and e-commerce operators

Merchant payment flows are the environment where card testing takes place, since attackers use them to obtain authorization responses on stolen cards. Merchants are positioned to detect and block testing patterns before requests are forwarded to the acquirer, and they bear the direct consequences of high attempt volumes, including processing costs, disputes, and network scrutiny.

Fraud analysts and risk teams

These teams design and tune the detection controls, such as velocity checks and anomaly monitoring, used to identify card testing. They must manage the trade-off between false positives that block legitimate customers and false negatives that let testing through, calibrating controls to the merchant's specific transaction patterns.

Acquirers and payment processors

Because the goal of card testing is to reach the acquirer for authorization, acquirers and processors see the authorization traffic these attacks generate. Card brand and network rules that govern chargebacks and merchant risk shape how acquirers respond to merchants experiencing sustained testing activity.

Payment developers and integrators

Those building payment integrations need to distinguish card testing as an attack technique from the legitimate use of test card numbers in sandbox environments during development. Understanding how testing traffic reaches the payment flow helps inform where detection and blocking logic should be placed.

Inside Card Testing

Card testing (carding)

A fraud technique in which an attacker validates stolen or guessed payment card details by submitting many low-value or zero-value authorization attempts to determine which cards are active and usable before committing higher-value fraud.

Automated attack tooling

Scripts, bots, and distributed request generators used to submit high volumes of authorization or account-verification requests, often rotating IP addresses, user agents, and card values to evade simple detection.

Card-not-present (CNP) targeting

Card testing is predominantly a CNP phenomenon that abuses e-commerce checkout flows, payment APIs, and account-verification endpoints where the physical card and EMV chip authentication are not present.

Authorization and verification requests

Attackers exploit authorization messages, and sometimes account-verification or zero-amount checks, to test whether a PAN, expiration date, and where applicable a CVV2/CVC2/CAV2 value are valid. Note that sensitive authentication data such as CVV2 must not be stored after authorization even when encrypted.

Indicators and signals

Observable patterns that may indicate card testing, such as spikes in declined transactions, elevated authorization-to-capture ratios, many small or zero-value attempts, repeated attempts across sequential card numbers, and concentrated activity from single sources or shared device fingerprints.

Downstream fraud outcomes

Cards confirmed valid through testing may subsequently be used for card-not-present fraud, account takeover, or resale, and merchants may face increased declines, processing costs, and potential chargebacks governed by card brand and network rules.

Common questions

Answers to the questions practitioners most commonly ask about Card Testing.

Is card testing the same as a data breach where card numbers are stolen?

No. Card testing is the activity of validating whether card credentials are usable, typically by submitting many low-value or authorization-only transactions against a merchant's payment flow. The credentials being tested are often obtained elsewhere, so card testing is generally a downstream use of already-exposed data rather than the breach event that exposed it. A merchant can be abused as a card testing platform without its own systems being the source of the compromised card data.

Does a declined transaction mean the card testing attempt failed and caused no harm?

Not necessarily. Attackers often use card testing specifically to learn which cards are valid, and the approve-or-decline response itself can be the information they seek. Even declined attempts may generate authorization fees, contribute to elevated decline ratios, and create operational noise. A high volume of declines can therefore signal an active card testing campaign rather than an absence of impact.

Which payment flows are most commonly targeted for card testing?

Card-not-present flows that accept automated submissions are frequently targeted, including checkout pages, stored-value or donation forms, account signup flows that add a card, and any endpoint that performs an authorization or account verification. Flows that expose detailed decline reasons or lack rate limiting and bot controls tend to be more attractive to attackers, though specifics vary by implementation.

What signals can help detect card testing activity?

Common signals include spikes in authorization or verification attempts, elevated decline ratios, many attempts from a narrow set of IPs or device fingerprints, sequential or patterned card numbers, unusually small or zero-value amounts, and rapid succession of attempts. These are indicators rather than proof; each can produce false positives, so correlating multiple signals generally improves detection accuracy over relying on any single one.

What controls can help reduce card testing abuse?

Controls that may mitigate card testing include rate limiting, velocity checks, bot detection and challenge mechanisms such as CAPTCHA, device fingerprinting, minimizing the detail returned in decline responses, and monitoring for the signals noted above. Authentication measures applied to card-not-present flows may also raise the cost of automated abuse. No single control eliminates the activity, and each involves trade-offs between friction for legitimate customers and effectiveness against attackers.

How does card testing relate to PCI DSS scope and requirements?

Card testing is a fraud and abuse pattern rather than a defined term within PCI DSS, so it is not governed by a specific numbered requirement. That said, general PCI DSS themes such as monitoring, logging, and detecting anomalous activity can support identifying such abuse. Because requirement wording and numbering differ between versions, confirm any specific control against the current published standard rather than assuming a fixed reference.

Common misconceptions

Card testing only matters to large merchants or those that store card data.

Card testing abuses live authorization and verification endpoints, so any merchant or platform accepting card-not-present transactions can be targeted regardless of size or whether cardholder data is stored. The attack exploits the transaction flow itself, not stored data.

Requiring a CVV2/CVC2/CAV2 at checkout stops card testing.

Requesting the card verification value can help reduce some attempts, but it does not eliminate card testing because attackers may already possess or brute-force these values, and CVV2 checks address only one signal. It is intended to mitigate, not prevent, and it should not be relied upon in isolation.

A high decline rate alone confirms card testing is occurring.

Elevated declines are a common indicator but are not definitive; legitimate causes such as expired cards, insufficient funds, or checkout errors also raise declines. Detection controls carry false-positive and false-negative trade-offs and should correlate multiple signals rather than acting on a single metric.

Best practices

Apply rate limiting, velocity checks, and throttling on authorization, payment, and account-verification endpoints to slow high-volume automated attempts, accepting that thresholds must be tuned to balance false positives against detection coverage.

Deploy bot mitigation and challenge mechanisms (such as CAPTCHA or device fingerprinting) at checkout and API layers, recognizing these help reduce automated abuse but may be evaded by sophisticated tooling.

Monitor for card-testing indicators such as spikes in declines, elevated authorization-to-capture ratios, sequential card attempts, and concentrated activity from shared sources, and correlate multiple signals before taking action.

Ensure sensitive authentication data, including CVV2/CVC2/CAV2 and any full track data, is never stored after authorization even when encrypted, in line with the applicable PCI DSS requirements, confirming exact requirement wording against the current published standard.

Consider layered authentication such as 3-D Secure for card-not-present flows where appropriate, understanding it addresses a different risk point than velocity or bot controls and does not by itself eliminate card testing.

Coordinate with your acquirer, payment processor, and card brands on suspected card-testing activity and applicable network rules, since chargeback and liability outcomes are governed by card brand and network rules that vary by region and change over time.