The 3am attack that doesn't want your products

Most fraud wants something from your store. Card testing wants something from your *checkout*. At some point — often overnight — a bot discovers that your payment form will answer a simple question: *is this stolen card still alive?* Then it asks that question hundreds or thousands of times, one card number after another, using $1–$10 orders or open-amount donations as the probe. The cards that approve get resold or used for real fraud somewhere else. You wake up to a wall of tiny orders, a spike in declines, and a payment processor that is suddenly very interested in your account.

This is card testing (also called carding or card checking), and it has become one of the most common attacks against small and mid-size merchants precisely because it doesn't need your store to be valuable — only reachable. Stripe maintains dedicated documentation on it, and the Nilson Report puts global payment-card fraud losses in the tens of billions of dollars a year — an economy that needs a constant supply of *verified* stolen cards. Your checkout is the verification step.

The good news: card testing is bot traffic, and bot traffic has to come from somewhere. This guide covers how the attack works, what it really costs, and how to shut it down at the IP layer before the card networks ever see an authorization.

TL;DR

• Card testing = bots validating stolen card numbers through small purchases or donations on your site. You're the lab, not the target.
• Small stores are preferred targets: no CAPTCHA, no rate limiting, guest checkout, cheap products or open-amount donation forms.
• The costs stack in three layers: per-attempt authorization/decline fees, chargebacks on the approvals, and — worst — card-network monitoring programs and account termination when your decline and dispute rates spike.
• Processor tools act too late. Stripe Radar and equivalents evaluate the payment after it's created; the card networks still see every attempt. Stop the bot before the payment intent exists.
• The strongest upstream signal is the visitor's IP: data-center origin, proxies, Tor, and high per-IP velocity identify carding bots with very high confidence.
• Block by risk tier, not by category — hard-block the automation signals, challenge the ambiguous ones, and real customers never notice.

What a card testing attack looks like

Card testing has a distinctive fingerprint. If you've been hit, you'll recognize most of this list; if you haven't, this is what to alert on:

• A burst of small orders — dozens to thousands in minutes or hours, typically the cheapest product in your catalog, a $1–$10 amount, or a custom donation value.
• A different card number on almost every attempt. The fraudster is working through a purchased list ("dump") of stolen numbers. Expect a high decline rate with scattered approvals.
• Rotating or clustered IP addresses — usually data-center ranges (AWS, OVH, Hetzner), open proxies, or residential proxy networks rented by the hour. Sometimes one IP hammers you; more often a pool rotates to stay under naive per-IP limits.
• Throwaway identities: disposable email domains, gibberish names, mismatched or copy-pasted billing addresses.
• Geo mismatch — billing addresses that don't match the IP's country, or traffic from regions you don't sell to.
• No human behavior: straight to checkout, no browsing, forms filled in milliseconds, headless-browser user agents.

Two attack variants are worth knowing. Full authorization testing runs a real small charge — these are the ones that become chargebacks. Zero-dollar / account-verification testing abuses $0 card-validation requests (or your saved-card flow) and produces no order at all, so it can run for weeks unnoticed while still generating per-attempt fees and network scrutiny. If your processor dashboard shows a pile of $0 verifications you didn't design for, you're being tested.

What it actually costs you

The transaction amounts are a rounding error. The real damage comes in three layers, each worse than the last.

Layer 1: per-attempt fees. Most processors charge for every authorization attempt — approved *or declined* — commonly somewhere in the $0.05–$0.30 range once network and gateway fees are counted. A quiet overnight run of 20,000 tests can cost you four figures in fees for transactions you never wanted, and some processors add explicit excessive-decline penalties on top.

Layer 2: chargebacks. Every *approved* test is a stolen card charged without the owner's knowledge, and a large share of them come back as disputes 30–90 days later. Each one costs the transaction amount plus a $15–$25+ chargeback fee, plus the time to respond. There's no winning these — the card was stolen. (Our chargeback prevention playbook covers the dispute side in depth.)

Layer 3: your processing relationship. This is the existential one. Visa and Mastercard run excessive-chargeback and fraud-monitoring programs with thresholds that start around 0.9%–1.5% of transactions. A card testing attack can blow through those in a single day — the attack inflates your dispute *count* while barely moving your legitimate volume. Merchants in the monitoring programs face month-by-month fines, mandatory remediation plans, higher reserves, and, if the numbers don't recover, account termination and a place on the MATCH list that makes getting a new merchant account very hard. Processors like Stripe will also simply pause payouts or close accounts that look like uncontrolled fraud funnels — from their perspective, a merchant who can't stop card testing is a liability to the whole network.

That's why "Radar caught most of them" isn't good enough. The attempts themselves are the damage. The goal is for the bot's request to die before a payment attempt exists.

The IP signals that expose carding bots

A card testing bot can rotate cards, names, and emails effortlessly — those are just fields in a script. What it cannot easily fake is where its traffic comes from. Every signal below is available before checkout runs, in a single IP lookup:

• Data-center / hosting origin. Real customers buy from residential ISPs and mobile carriers, not from AWS or Hetzner. A checkout attempt from a hosting range is automation until proven otherwise — this is the cleanest single tell, exactly as it is for bot traffic generally.
• Open proxies and Tor. Almost no legitimate buyer completes a purchase through an open proxy or a Tor exit node. At checkout specifically, these are safe to hard-block.
• VPN egress. Real people do shop on VPNs, so a bare VPN flag is a *friction* signal, not a block signal — but VPN combined with a fresh account, a disposable email, or a billing/geo mismatch is a different story. (How we detect VPNs.)
• Per-IP and per-network velocity. Five checkout attempts from one IP in ten minutes is not five customers. Track attempts per IP and per ASN so a rotating pool inside one provider's network still shows up as a cluster.
• Geo/billing mismatch. An IP in one country with a billing address in another is weak evidence alone, but it stacks with everything above.
• Risk score. Rather than hand-weighing each flag, fold them into one 0–100 score and act on thresholds — the model from IP risk scoring explained.

The tiered response that protects checkout without hurting conversion:

Gate the payment, not just the page

The implementation detail that matters most: run the check before you create the payment intent / authorization, not after. Here's the pattern for a typical Stripe integration — one lookup, then a tiered decision:

import os, requests
from flask import request, abort

PREDAX_API_KEY = os.environ["PREDAX_API_KEY"]

def classify_ip(ip):
    r = requests.post(
        "https://predax.io/api/v1/check/ip",
        headers={"X-API-Key": PREDAX_API_KEY},
        json={"ip": ip},
        timeout=2,
    )
    return r.json()

@app.route("/api/create-payment-intent", methods=["POST"])
def create_payment_intent():
    ip = request.headers.get("CF-Connecting-IP") or request.remote_addr

    try:
        c = classify_ip(ip).get("classification", {})
    except requests.RequestException:
        c = {}  # fail open — never let a lookup outage block real sales

    # Tier 3: hard-block high-confidence automation BEFORE Stripe sees it
    if (
        c.get("is_datacenter")
        or c.get("is_proxy")
        or c.get("is_tor")
        or c.get("risk_score", 0) >= 75
    ):
        log_blocked_checkout(ip=ip, risk=c.get("risk_score"))
        abort(403)

    # Tier 2: require a solved CAPTCHA for medium-risk traffic
    if c.get("is_vpn") or c.get("risk_score", 0) >= 40:
        if not verify_captcha(request.json.get("captcha_token")):
            abort(400, "captcha_required")

    # Tier 1: clean traffic proceeds with no friction
    return create_stripe_payment_intent(request.json)

Three details in that snippet are load-bearing. It fails open — a fraud check that can take down your checkout is worse than the fraud. It logs blocked attempts — that log is your evidence trail with the processor and your tuning dataset. And the block happens server-side at intent creation, so a bot that skips your frontend entirely and posts straight to the API hits the same wall.

The rest of the stack

IP screening is the highest-leverage layer, but card testing defense is a stack. Round it out with:

• Rate limiting on the payment endpoint — per IP, per session, and per card fingerprint if your processor exposes one. Even generous limits (five attempts per hour) break testing economics.
• CAPTCHA on checkout for guest and first-time purchasers. Modern invisible variants add near-zero friction for humans; combine with the risk score so only Tier 2 traffic ever sees a challenge. (Bots that beat CAPTCHAs still don't beat CAPTCHA *plus* IP screening — see form spam beyond reCAPTCHA.)
• Enforce AVS and CVV, and auto-decline mismatches. Card dumps often lack full billing addresses, so address verification kills a large share of tests.
• Remove the cheap probes: no $1 products, minimum donation amounts, and don't run $0 verifications on guest flows.
• 3-D Secure for risky orders — dynamically, driven by the same risk tiers, so it protects the edge cases without adding checkout friction for everyone.
• Keep your processor's tooling on. Stripe Radar and equivalents remain valuable as the last line — the goal of everything above is that they see almost nothing to catch.

Watch your dashboards for the early signs: a rising decline rate, $0 verifications you didn't design, bursts of guest accounts with disposable emails (the same signals as fake signups — often the same actors, since carded accounts get warmed up before use).

How Predax helps

Every /api/v1/check/ip call returns the exact signals this playbook runs on: `is_datacenter`, `is_proxy`, `is_vpn`, `is_tor`, the originating ASN, geolocation for billing-mismatch checks, and a composite `risk_score` (0–100) — one sub-second lookup you can drop in front of any payment endpoint. Responses are cached and the API is built to fail open, so it never becomes a point of failure in your checkout.

If you run WooCommerce, you don't need to write the code at all: the Predax Fraud Guard for WooCommerce plugin screens every checkout with these signals and adds the card-testing-specific layers on top — order velocity limits, billing-country vs IP mismatch detection, and disposable-email flagging — with block/flag modes per signal so you can monitor before you enforce. High-risk orders are blocked before payment or tagged for review, with every decision logged to an events dashboard.

View pricing — the free tier includes the data-center, proxy, VPN, and Tor flags plus risk scoring, which is enough to shut down most card testing attacks today.

Frequently Asked Questions

What is a card testing attack?

Card testing (also called carding or card checking) is when fraudsters use bots to run small transactions through your checkout or donation form to find out which of their stolen card numbers are still live. Your store isn't the target — it's the laboratory. Each approved micro-transaction confirms a working card that is then resold or used for a large purchase elsewhere. The attack typically arrives as a burst of hundreds or thousands of small orders in hours, each with a different card number, usually from data-center, proxy, or VPN IP addresses with throwaway email addresses attached.

Why was my small store chosen for card testing?

Precisely because it is small. Carding bots sweep the web for checkouts with the lowest friction: no CAPTCHA, no rate limiting, guest checkout enabled, and ideally a cheap product or an open-amount donation form that lets them authorize $1. Large retailers have fraud teams and velocity controls; a small WooCommerce shop or a nonprofit donation page often has neither. Nothing about your business attracted the attack — your checkout simply answered the probe faster and with fewer obstacles than the next site on the list.

How much does a card testing attack actually cost the merchant?

More than the transaction amounts suggest. You pay an authorization or decline fee on every attempt — commonly in the $0.05–$0.30 range depending on your processor — so ten thousand declined tests can cost hundreds to thousands of dollars in fees alone before a single dispute. The approved transactions then convert into chargebacks at $15–$25+ each once cardholders notice. And the worst cost is structural: a spike in declines and disputes pushes you toward the card networks' excessive-chargeback thresholds (around 0.9%–1.5% of transactions), which triggers monitoring programs, fines, higher processing rates, and ultimately account termination.

Doesn't Stripe Radar (or my processor's fraud tool) already stop card testing?

It helps, but it sits at the wrong layer to solve the problem alone. Processor-side tools like Stripe Radar evaluate a payment after your site has already accepted the request and created the payment attempt — so even blocked payments still consume authorization attempts, pollute your metrics, and count toward your decline rate. Processors also explicitly recommend adding your own upstream controls: rate limiting, CAPTCHA, and screening the visitor before the payment is created. IP intelligence is that upstream layer — a bot arriving from a data-center or proxy IP can be stopped before it ever reaches the card networks, which is the outcome your processor's monitoring programs actually care about.

Will blocking VPN and proxy traffic at checkout lose me real customers?

Not if you block by risk rather than by category. A meaningful share of real customers use VPNs, so a blanket VPN ban will cost you sales. The durable pattern is a tiered response: allow clean residential and mobile traffic, add friction (CAPTCHA, 3-D Secure) for medium-risk signals like a bare VPN flag, and hard-block only the high-confidence automation signals — data-center origin, open proxies, Tor, and high per-IP velocity. Card testing bots overwhelmingly come from that last tier, so you stop the attack while a privacy-conscious human on a VPN still gets through with, at most, one extra challenge.