What is card testing?

Card testing is fraudulent activity used to learn whether stolen, guessed, or incomplete payment-card details are valid. Attackers commonly submit payment or card-setup attempts through an online checkout, donation form, payment page, or another card-not-present flow, then use the responses to identify credentials that may work elsewhere.

The term is often used broadly. Stripe lists carding, account testing, enumeration, and card checking as related names, while Visa distinguishes systematic enumeration of card values from account testing that checks whether particular accounts are active. The labels may vary across providers, but the merchant-facing concern is the same: a legitimate payment path is being abused to validate card data.

How card testing typically works

An attacker first obtains payment data from a source outside the targeted merchant, guesses missing values, or generates possible values. Automated scripts can then submit many attempts more quickly than a person could enter them. The attacker observes whether the checkout, gateway, issuer, authentication step, or card-setup flow returns a response that helps separate usable credentials from invalid ones.

Some tests use small payment amounts because they may attract less attention. Others use a card-verification or setup path that does not create an ordinary purchase. A successful response does not establish that the person is the legitimate cardholder; it can merely tell an attacker that a credential combination is active or accepted by that particular flow.

Related terms describe different patterns

Card testing or carding

These are common umbrella terms for attempts to validate stolen payment-card data. OWASP describes carding as multiple authorization attempts used to verify bulk stolen card information.

Enumeration

Visa describes enumeration as systematically varying values such as account number, expiration date, security code, or postal code to derive valid payment details. It is often called a brute-force attack.

Account testing

Visa uses this term for attempts that check whether an illicitly obtained account is active, often through one or two low-amount transactions. That is narrower than guessing many combinations of missing values.

What a merchant may notice

Possible signals include an unusual burst of attempts, many declines followed by occasional approvals, many card references associated with one device or network signal, repeated use of similar contact details, or activity concentrated on a low-friction form. A merchant might also see a sudden change in authorization volume that does not match real orders, donations, appointments, or account activity.

No single pattern proves card testing. Legitimate customers retry payments, shared networks can connect unrelated buyers, and promotions or events can produce sudden traffic. Exact signals also depend on which data the payment provider collects and exposes. Merchants should compare activity with their own normal patterns and current provider documentation instead of treating a universal transaction count or amount as definitive.

Why card testing matters to a business

Testing traffic can distort order and customer data, increase authorization activity, consume staff time, and lead to fraudulent transactions that later require investigation. It can also create friction for legitimate customers if a merchant reacts with overly broad blocking. The impact may extend beyond successful orders because repeated attempts can burden checkout services and complicate ordinary fraud review.

The merchant whose form is abused is not necessarily the place where the card information was originally obtained. Stripe and OWASP both describe attackers bringing stolen data to another payment process for validation. That distinction matters when investigating an event: the immediate job is to contain abuse of the merchant's flow, preserve useful records, and involve the responsible payment and security providers without making unsupported assumptions about the source of the data.

A practical first-response path

Confirm the pattern

Compare the activity with normal traffic, recent campaigns, staff testing, retry behavior, and provider alerts. Use redacted references rather than copying full payment data into notes or messages.

Protect the affected flow

Use provider-supported controls to slow or stop suspicious automation while preserving access for legitimate customers. Avoid inventing an untested threshold or changing several controls at once.

Contact the responsible providers

Escalate through verified gateway, processor, ecommerce-platform, hosting, or security-support channels. Ask what activity they can see, what controls are available, and what evidence they need.

Review and tune

After containment, document the affected endpoint, timing, signals, action taken, and customer impact. Test changes through approved methods and continue monitoring for shifted attack patterns.

Map the payment flow before changing controls

Document every public form that can submit or save payment credentials, the providers responsible for each step, expected traffic patterns, available alerts, and the person authorized to respond. Payments Max can help organize these workflow questions for a payment-processing discussion without promising a particular fraud outcome.

Do not submit cardholder data, complete account numbers, security codes, payment tokens, passwords, bank credentials, one-time codes, or secret API keys through a general inquiry form.

Discuss an online payment workflow

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.