How to stop card testing attacks (without wrecking checkout conversion)

Card testing attacks: what they are (and why they’re your problem)

A card testing attack is when automated scripts run lots of tiny authorisations or low-value payments to check whether stolen card details are valid. If a card “works”, it gets sold or used elsewhere for bigger fraud.

Even if you don’t lose much per transaction, you can still get hit with gateway fees, operational noise, higher decline rates, and support tickets. Stripe describes waves of “millions of small- or zero-dollar transactions” during major card testing surges—this stuff scales fast (Stripe).

How card testing shows up in your metrics

Card testing doesn’t look like a Hollywood hack. It looks like your checkout being used too efficiently.

Common signals merchants are advised to watch include rapid-fire low-value authorisations, spikes in declines, and repeated request patterns (for example, identical payloads or many different cards from the same source) (J.P. Morgan). Visa also frames these as enumeration/account testing patterns and recommends anomaly detection and technical controls (Visa PDF).

The practical goal: make testing expensive, slow, and measurable

For product owners and developers, the win isn’t “block 100% of bots” (nice dream). It’s:

1. Stop automated scale
2. Keep conversion steady for legitimate customers
3. Create clean signals your fraud team (or future-you) can act on

OWASP’s “automated threats” framing is helpful here: attackers abuse normal functionality at machine speed, so your defences need to be system-level—detect → decide → respond (OWASP Automated Threats).

A defence-in-depth playbook to stop card testing attacks

You’ll get the best results by combining a few boring controls that work extremely well together.

1) Put hard limits on payment attempt velocity (server-side)

Card testing lives on volume. Don’t negotiate with volume.

Implement rate limits specifically for:

1. Payment method creation / tokenisation endpoints
2. Authorisation/charge attempts
3. Failed payment attempts (declines are a key signal)

Use multiple keys, not just IP:

1. Per IP
2. Per device/session
3. Per account (if logged in)
4. Per email (if collected)
5. Per BIN / per card fingerprint (via your PSP where available)

When you throttle, return HTTP 429 with Retry-After so legitimate clients can recover cleanly.

2) Add risk-based human verification at the right moment

Don’t blanket-challenge every payer. Instead, step up verification when the pattern looks like testing.

Good step-up triggers:

1. Many attempts in a short window from the same device/session
2. High decline rate (especially across many different cards)
3. Repeated low-value amounts (e.g. £0–£2) or repeated “account verification” style attempts
4. Suspicious network patterns (datacentres/anonymisers) combined with velocity

This is where a human verification API or bot prevention layer fits neatly: you add a quick, user-friendly check only when risk rises.

3) Make your checkout harder to automate (without redesigning it)

Attackers love predictable flows.

A few practical hardening moves:

1. Require JavaScript-enabled, modern browser behaviour for the payment page
2. Use one-time tokens for critical steps (create payment intent, submit payment)
3. Tie attempts to a session and reject mismatches (token created in session A, used in session B)
4. Block obviously synthetic user agents and headless fingerprints

These don’t replace fraud controls, but they make cheap automation fall over.

4) Tighten what “anonymous payments” are allowed to do

If your business allows guest checkout, you can still put guardrails around it.

Examples:

1. Limit payment attempts until email is verified
2. Add a short “cooldown” after multiple declines
3. Require login after N failed attempts (or switch to step-up verification)

Product-wise, this is a simple policy: Allow / Step-up / Block based on risk.

5) Use PSP-native anti-card-testing features properly

Payment providers see patterns across many merchants. Use that leverage.

1. Stripe explicitly recommends using their newer payment integrations (like Checkout/Payment Element) and providing richer data to improve card testing prevention (Stripe docs).
2. Adyen calls out enumeration/BIN attacks and suggests short-term measures to reduce automated attempts reaching their platform (Adyen Help).

The practical takeaway: don’t starve your PSP of context. Pass through customer, device, and order signals you already have (within your privacy and PCI constraints).

A concrete rollout plan (that won’t derail your roadmap)

Week 1: instrument

Add dashboards per endpoint:

1. Attempts/minute
2. Decline rate and top decline codes
3. Unique cards per IP/device/session
4. Low-value transaction frequency

Week 2: throttle + step-up

1. Add rate limits on payment attempts (multi-key)
2. Add step-up verification on suspicious patterns
3. Alert on spikes (attempts, declines, unique cards)

Week 3: tune thresholds

1. Relax anything harming conversion
2. Tighten anything letting testing through
3. Segment rules by country, traffic source, and endpoint

What to measure so you don’t “win” and still lose

Track impact, not vanity blocks:

1. Card testing attempts stopped (estimated via patterns)
2. Decline rate (overall and on protected flows)
3. Checkout conversion and time-to-pay
4. Support tickets tagged “payment failed”
5. PSP fees and ops overhead during attack windows

Where Humans Only fits

Humans Only helps you stop card testing attacks by detecting automation early and giving you clear outcomes: allow, step-up, or block—without turning your checkout into a puzzle box.

It’s fast (typically under 2 seconds), privacy-first (zero tracking), and easy to drop into the exact endpoints attackers monetise. You also get real-time analytics, so tuning defences becomes a weekly optimisation—not a 3am incident.

Bottom line

To stop card testing attacks, focus on the mechanics: automated scale, repeatable flows, and cheap retries. Combine server-side rate limiting, smart step-up verification, and PSP-native protections—and measure conversion alongside fraud.

If you want bot prevention that’s pleasant for real customers and ruthless to automation, Humans Only is built for it: Stop Bots, Welcome Humans.