Card testing attacks: how to spot one and stop it at checkout

Card testing is when someone uses your checkout to find out which stolen card numbers still work. The usual signature is a sudden burst of small payment attempts, most of them declined, spread across many different cards. You stop it by adding friction at the exact endpoint being abused, refunding any test charge that succeeded before it turns into a dispute, and then keeping controls that scale with risk rather than blocking everyone.

The attacker is after a fast, cheap verdict from a card issuer, and your form happens to provide one. That is why a small donation page or an "add payment method" screen can be hit harder than a large store.

How do you know it is card testing and not a checkout bug?

Stripe's guidance is that most attacks are visible as a significant rise in failed authorizations and payments: a spike in failed or blocked payments, a spike in declined requests with a generic decline outcome, and suspicious low-value payments with nonsensical customer names and emails. Stripe: protect yourself from card testing

A checkout bug tends to look different. Compare the two before you change anything:

If two or three of the left-hand signals appear together, treat it as an attack and move to containment. Investigating the root cause can wait an hour; the authorizations cannot.

Why do small merchants and donation forms get hit?

Testers look for any endpoint that returns an issuer verdict quickly with little friction. Common targets are donation forms with a free-entry amount, card verification on account sign-up, free trials that require a card, and guest checkouts that accept unlimited attempts. None of these needs a large merchant behind it.

Platform and plugin users are not exempt. Stripe notes that when you take payments through a plugin or platform, preventing card testing usually needs code-level changes, so the developer or vendor has to be involved. Stripe card testing guidance

What does a card testing attack cost the merchant?

The direct cost depends on your contract. Some pricing models charge for attempts or declines, so read your provider agreement rather than assuming failed payments are free.

The larger costs arrive later:

• Disputes. Any test charge that was approved belongs to a real cardholder who will eventually notice it. Unrefunded, it can come back as a fraud chargeback. See why chargebacks are a product problem.
• Acquirer monitoring. Visa's Acquirer Monitoring Program tracks fraud, disputes and enumeration, the network's term for this kind of testing. Its 2025 fact sheet says acquirers must take proactive steps to keep merchants below enumeration thresholds: an enumeration ratio of 2,000 basis points of authorization transactions, or 300,000 enumerated transactions. Visa VAMP fact sheet 2025 Acquirers manage that obligation through their merchants, which is one route to the reserves and reviews described in why payment processors hold funds.
• Distorted metrics. Thousands of junk attempts drag down your authorization rate and can trigger the wrong investigation. Separate them before anyone reports the number. The authorization rate as a P&L metric essay explains why that number deserves care.

What should you do in the first hour of an active attack?

Stripe's checklist for an attack in progress is to identify the activity, refund fraudulent payments to avoid disputes, adopt a recommended integration or add mitigations, and monitor the result. Stripe card testing guidance The sequence below turns that into owner-level steps.

1. Confirm the pattern

Check cards per source, amounts, decline mix and which endpoint is receiving the traffic.

Attack signals present

2. Contain the abused endpoint

Enforce a challenge server-side, tighten rate limits, or pause the targeted form or guest card-add.

Attempts continue after containment

Escalate to your provider's support and risk team with timestamps and affected endpoint.

Recheck containment

Attempt rate falls

3. Refund what succeeded

Refund approved test charges and cancel any orders, accounts or trials they created.

Exposure closed

4. Relax controls deliberately

Remove emergency friction in stages while watching attempt volume and genuine conversion.

Pausing a form is a business decision with revenue impact. Agree in advance who can make it outside working hours.

Two practical notes. First, do not rely on blocking IP addresses alone; Stripe states that single-heuristic filters such as IP rules are usually insufficient on their own. Second, check whether a secret API key has leaked. Stripe warns that leaked keys let testers create payments on your account directly, which no checkout change will stop.

Which controls hold up after the attack ends?

Emergency friction should not become permanent. Once the attack stops, replace it with controls sized to the risk of each endpoint:

1. Use the provider's recommended checkout components. Stripe says its current Payment Element and Checkout integrations include automated controls such as rate limiters, AI models and CAPTCHA triggers.
2. Enforce challenges on the server. A client-side CAPTCHA that the payment endpoint does not verify is decoration. Stripe recommends a challenge on every request that validates cards or processes payments.
3. Rate-limit by more than one key. Combine IP, device, account and card fingerprint. Stripe's examples include limiting the cards that can be added to one account and the customers that one IP address can create in a day.
4. Raise the cost of the cheapest target. Require a signed-in session before saving a card, set a sensible minimum donation, and avoid zero-friction card verification on public forms.
5. Decline on failed checks. Block or review payments that fail CVC or postcode verification, using your provider's rules engine.
6. Keep customer-facing decline messages general. Telling the browser exactly why a card failed helps the tester more than the customer. Give the precise reason to your logs and support tools instead.

These sit inside a broader design for layered fraud controls, and any new rule should go through the same fraud rule lifecycle as the rest: shadow mode, measured false positives and a named owner.

Who should own card testing defence?

Card testing crosses teams, which is why it often belongs to nobody. A workable split:

• Product owns where friction appears and accepts the conversion trade-off, endpoint by endpoint.
• Engineering owns rate limits, challenge enforcement, key hygiene and alerting on attempt spikes.
• Risk owns rules, thresholds and the relationship with the provider's risk team.
• Finance and support own refunds, dispute monitoring and customer contact for any real cardholder affected.

Write that split down before the next attack. The first hour is the wrong time to discover that nobody can pause the donation form at 3 a.m.

FAQ

Will refunding test charges prevent chargebacks?

It reduces the risk substantially because the cardholder sees a reversal, but it does not guarantee that no dispute is filed. Refund quickly and keep a record of each refund in case a dispute arrives later.

Should I block countries to stop card testing?

Geographic blocking can reduce noise, but testers route traffic through many locations, and blocking can turn away genuine customers. Treat it as a temporary containment measure, not the main control.

Does a CAPTCHA hurt conversion?

It can add friction. That is why risk-based challenges, shown only when signals look abnormal, are preferable to a challenge on every visit. Measure conversion before and after rather than assuming either way.

Why do most of the declines say generic_decline?

Issuers often return a non-specific decline when they suspect fraud. A spike in declined requests with a generic decline outcome is one of the card testing signals Stripe lists. The decline codes guide explains what to retry and what to leave alone.

Can a card testing attack get my merchant account restricted?

It can contribute. Acquirers watch fraud and enumeration levels, and sustained attacks can lead to reviews or reserves. Containing attacks quickly and refunding successful test charges is the best evidence that you manage the risk.