How to Protect an E-commerce Store from Bots, Card Testing, and DDoS

A store that makes money is a target. Not eventually — immediately. The traffic that hits an online store the moment it starts converting includes bots testing stolen cards, scrapers pricing out your catalogue, and scripts placing fake orders to drain your stock. None of it looks like an attack in your analytics dashboard. It looks like traffic, until the chargeback fees and the empty inventory tell you otherwise.

This is a practical rundown of the attack patterns that specifically target e-commerce stores, how to detect each one, and what mitigation actually looks like — not “install a firewall and hope.”

Card Testing: The Fraud You Don’t See Until the Chargebacks Arrive

Card testing (carding) is bots running stolen card numbers through your checkout in small automated batches to find which ones still work. A single stolen-card list can contain thousands of numbers; testing them against your store is cheaper and faster than testing them against a bank directly.

What it looks like: a burst of low-value transaction attempts, often under $5, from a rotating set of IPs, with an abnormally high decline rate. Real customers don’t attempt five failed card numbers in ninety seconds — bots do.

Why it costs you even when the card fails: every attempt — successful or not — burns your payment gateway’s fraud-check quota, and repeated failed authorizations can get your merchant account flagged for review. The cards that do work get used for a small “test” purchase, then a much larger fraudulent order follows within hours.

Mitigation: rate-limit checkout attempts per session and per IP. Flag and hold orders where the billing address, IP geolocation, and card-issuing bank country disagree. Add a velocity check — more than two to three failed authorizations from a single session should trigger a hold, not a retry prompt.

Fake Order Floods

Automated bots submit bulk fake orders — sometimes real card numbers with no intent to pay via other means, sometimes exploiting a “buy now, pay on delivery” or invoice flow. The goal varies: drain limited-stock inventory during a drop, disrupt a promotional price by locking in stock nobody pays for, or simply overwhelm your fulfilment team with orders that later cancel.

What it looks like: a spike in order volume with no matching spike in payment completions, concentrated in a narrow time window, often targeting a specific SKU or promotional price.

Mitigation: order validation before the order reaches your fulfilment queue — CAPTCHA or a proof-of-work challenge on checkout during high-risk windows (drops, flash sales), and a hold state for orders that haven’t completed payment within a set window rather than reserving stock indefinitely.

Price and Catalogue Scraping

Competitors and price-comparison aggregators scrape your product pages on a schedule to track pricing and stock levels. This isn’t illegal in most jurisdictions, but it erodes any pricing advantage the moment you make a change, and heavy scraping traffic itself can degrade performance for real shoppers.

What it looks like: structured, repetitive requests to product and category pages at a fixed interval, often from a rotating pool of IPs and user agents designed to blend in with organic traffic.

Mitigation: TLS fingerprinting and behavioral analysis catch scrapers that rotate surface-level identifiers (IP, User-Agent) but can’t easily fake the deeper connection-level signature. Rate limiting on non-authenticated catalogue requests slows scraping without affecting real browsing patterns.

Credential Stuffing on Customer Accounts

Leaked username/password lists from unrelated breaches get tested against your login page at scale, because password reuse means a meaningful percentage will work. A compromised customer account often has a saved payment method attached — turning a login page into a payment fraud vector.

What it looks like: high-volume login attempts across many different usernames, low success rate, distributed across IPs, frequently at off-peak hours when detection attention is lowest.

Mitigation: rate limiting and progressive lockout per account and per IP, alerting on unusual login patterns (new device + new location + immediate payment method access), and — if you’re not already — requiring re-authentication before a saved card can be charged.

L7 DDoS During Your Highest-Value Traffic Window

Application-layer DDoS floods are frequently timed deliberately: a product launch, a flash sale, Black Friday — the exact moment downtime costs the most in lost revenue and the exact moment your support team is least able to absorb the ticket spike.

What it looks like: a sudden traffic surge that doesn’t convert to checkouts, targeting a specific endpoint (search, product page, checkout) rather than distributed evenly across the site — a signal it’s designed to exhaust a specific resource, not just generate noise.

Mitigation: rate limiting and traffic shaping tuned to distinguish a flood from a legitimate spike (a marketing email blast produces a spike too — the difference is in request patterns, not raw volume), plus infrastructure that can absorb volumetric floods before they reach your application layer at all.

Shared WAF vs. Isolated Infrastructure

Most stores run behind a shared WAF platform — Cloudflare and similar services included — where your traffic sits alongside millions of other sites, sharing rule sets and rate-limit pools. That’s adequate for a lot of threats, but it isn’t isolation: your infrastructure is still discoverable, and a shared rate-limit pool can behave unpredictably under someone else’s attack traffic.

We built VoidFort to solve the isolation problem directly: a dedicated shield node per customer sits in front of your origin server. Traffic hits the Shield first, gets inspected against OWASP CRS rules, and only clean requests reach your store. Your real origin IP never appears in DNS records, TLS certificates, or scan results — attackers probing your domain find the Shield, not your infrastructure. It handles all of the patterns above — card testing, fake order floods, scraping, credential stuffing, and L7 floods — at the shield layer, before any of it reaches your application.

Where to Start

Most of the mitigations above don’t require replacing your platform — they require configuration most stores haven’t set up yet: rate limiting tuned to checkout and login endpoints, order validation before fulfilment, and traffic pattern monitoring that flags anomalies instead of raw volume.

We run security audits for e-commerce stores — Shopify, WooCommerce, Magento, or custom-built — that map your current exposure against the patterns above and deliver prioritised, costed recommendations. See our E-commerce Bot & DDoS Protection service for what that engagement looks like, or get in touch directly.