Stop checkout bots: practical defences for product owners and developers

Checkout bots: what you’re defending (and why it’s different)

Checkout bots aren’t “just traffic”. They’re automated scripts built to hit the most valuable actions in your funnel—add to basket, apply promo, and submit payment—at machine speed.

OWASP categorises these as automated threats to web applications: attackers abuse normal functionality, not obscure vulnerabilities (OWASP Automated Threats). In ecommerce, that distinction matters because your “normal” flows are exactly where the money is.

The three checkout-bot plays you’ll see in the wild

Most teams first notice checkout bots when a metric breaks, not when logs look scary.

1. Card testing (carding): bots run lots of small/low-value authorisations to validate stolen card details (Stripe; OWASP OAT-001 Carding).
2. Scalping / inventory hoarding: bots reserve scarce items faster than humans can click, then either buy or abandon.
3. Promo and loyalty abuse: bots spray codes, create baskets, and iterate until they find value.

For product owners, this shows up as lower conversion, higher declines, and support pain. For developers, it’s rate spikes, noisy telemetry, and “why is checkout slow?” incidents.

A practical model: Detect → Decide → Respond

If your bot prevention strategy can’t be explained in one diagram, it’ll be hard to tune without harming conversion.

Use a simple loop:

1. Detect signals (velocity, session integrity, workflow behaviour, network reputation).
2. Decide risk (low/medium/high) per request.
3. Respond with a small set of outcomes.

A solid enforcement policy is:

1. Allow (low risk)
2. Step-up verification (medium risk)
3. Block or throttle (high risk)

That’s enough to ship, measure, and iterate.

Where to protect: the checkout endpoints that matter

Checkout bots don’t need to browse your product pages. They target the endpoints that let them move fastest.

Prioritise protection on:

1. POST /cart and reservation/hold endpoints (inventory depletion)
2. POST /checkout and “place order” actions
3. payment creation/tokenisation endpoints (PSP-specific)
4. POST /payments/confirm / authorisation attempts
5. POST /promo/apply and rewards redemption

Concrete example: if you’re seeing card testing, protecting only login won’t solve it. You need controls specifically around payment attempts and tokenisation, because that’s where bots monetise.

The defence stack that stops checkout bots without wrecking UX

You don’t need a dozen overlapping tools. You need a few controls that reinforce each other and are easy to operate.

1) Rate limit per endpoint (not just per IP)

Rate limiting is boring—and extremely effective—when it’s specific. Apply different thresholds by endpoint and escalate penalties as behaviour worsens (Cloudflare rate limiting best practices).

Don’t key only on IP. Use multiple keys so attackers can’t just rotate addresses:

1. IP + session ID
2. device/browser integrity signals (where available)
3. checkout session / basket ID
4. account ID (if logged in)
5. email/phone (once collected)

When throttling, return HTTP 429 with Retry-After so legitimate clients recover cleanly.

2) Step up verification at the moment of risk

Blanket challenges across the whole checkout are a conversion tax. Instead, step up verification when signals stack up—high velocity, weird workflow, repeated declines.

PCI SSC explicitly recommends a layered approach for account testing patterns rather than relying on a single control (PCI SSC: Beware of Account Testing Attacks). “Layered” in practice means: rate limits + step-up + PSP controls + monitoring.

3) Make automation brittle with session-bound tokens

You can harden checkout flows without redesigning them.

1. One-time tokens for critical actions (apply promo, submit payment)
2. Tokens bound to a session/device; reject mismatches (token minted in session A used in session B)
3. Strict idempotency rules for payment requests
4. Enforce modern browser behaviour on checkout pages (bots hate consistency checks)

These controls raise the cost of automation and reduce cheap retries.

4) Use PSP-native anti-abuse features properly

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

For example, Stripe documents specific mitigations for card testing prevention and recommends using their newer payment integrations and providing richer context (Stripe docs). The practical takeaway: don’t starve your PSP of signals you already have (within your privacy and compliance constraints).

A quick “ship this” checklist (product + dev friendly)

This is the smallest set of changes that typically moves the needle fast.

1. Instrument attempts/minute, declines, unique cards per session, promo attempts, and conversion at each checkout step.
2. Add endpoint-specific rate limits on promo apply, payment tokenisation, and payment confirmation.
3. Implement step-up verification when velocity/declines/workflow patterns suggest automation.
4. Add session-bound tokens on high-value actions.
5. Review weekly: tune thresholds, keep conversion steady, and watch support tickets tagged “payment failed”.

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

If you only track “blocked requests”, you’ll optimise for drama, not outcomes.

Track:

1. Checkout conversion and drop-off on protected steps
2. Step-up rate and pass rate (are humans sailing through?)
3. Decline rate and top decline codes during spikes
4. Payment attempts per session/device (especially repeated low-value attempts)
5. Promo attempts per session and redemption success rate

A good result looks like: conversion stays flat (or improves), declines fall, and attack volume collapses before it hits your PSP fees and ops.

Where Humans Only fits

Humans Only helps you stop checkout bots with fast, privacy-first verification that’s pleasant for real customers and tough for automation. You can deploy it exactly where it matters—promo, basket, and payment endpoints—and use real-time analytics to tune allow / step-up / block decisions without guesswork.

If you want checkout bot protection that keeps humans moving and makes bots give up quickly, Humans Only is built for the job: Stop Bots, Welcome Humans.