Stop scalper bots: a practical playbook for product owners and developers

What scalper bots actually do (and why they’re hard to “just block”)

Scalper bots (also called ticket bots, sneaker bots, or scalping bots) are automated scripts designed to buy limited stock faster than any human can. They monitor launches, spin up multiple sessions/accounts, and hammer your add-to-basket and checkout endpoints in milliseconds.

OWASP classifies this kind of behaviour as an automated threat to web applications: attackers abuse normal product functionality at machine speed, rather than exploiting one magical vulnerability (OWASP Automated Threats). That framing matters, because it means the fix is operational: detect, decide, respond.

Primary and secondary keywords (for SEO)

Primary keywords: - stop scalper bots - scalper bots

Secondary keywords: - bot prevention - inventory hoarding - ticket bots - queue management

The tell-tale signs you’re dealing with scalper bots

You don’t need a PhD in bot detection to spot the pattern. Scalper bots leave fingerprints in business metrics and backend behaviour.

Look for: - Stock disappears instantly, but payment success doesn’t rise in line with it (holds and abandons). - Huge bursts on a small set of endpoints (basket/hold/checkout) at launch time. - Lots of “different users” behaving identically: same flows, same timings, same headers, same errors. - Unnatural navigation: skipping pages humans usually touch, or repeating the same action with tiny variations.

Concrete example: a limited drop goes live at 10:00. At 10:00:01 you see 20,000 POST /cart/hold calls, then a spike in timeouts, then customer support tickets saying “sold out instantly”. That’s not hype—it’s automation.

A practical strategy that works: Detect → Decide → Respond

If your plan to stop scalper bots is “add a CAPTCHA” and hope for the best, you’ll end up playing whack-a-mole. A more reliable approach is a simple loop:

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

For most teams, the policy that stays shippable is: - Allow (low risk) - Step-up (medium risk) - Block or throttle (high risk)

This keeps product owners aligned (clear trade-offs) and developers sane (predictable states to debug).

Where to put defences to stop scalper bots (hint: not “everywhere”)

Scalper bots don’t care about your homepage. They care about the endpoints that reserve stock and convert it into orders.

Prioritise protection on: - Queue / waiting room entry (where applicable) - Reservation/hold endpoints (e.g. POST /hold, POST /cart) - Add to basket and update quantity - Checkout creation and payment confirmation - Promo apply (scalpers love discounted inventory too)

Concrete example: if you only protect login, a bot can still hit “guest checkout” at speed. If you only protect checkout, a bot can still drain inventory by placing holds. Protect the value chain.

The defence stack: what to implement (and what each piece is for)

You don’t need 12 overlapping tools. You need a few controls that reinforce each other.

1) Rate limits that are endpoint-specific (and keyed sensibly)

Rate limiting works best when it’s boring and precise. Apply different thresholds for hold/cart/checkout and escalate when behaviour worsens.

Cloudflare’s guidance on rate limiting best practices is a solid reference point for practical rule design and escalation (Cloudflare rate limiting best practices).

Keys that work better than IP-only: - IP + session ID - basket/checkout session ID - account ID (if logged in) - email/phone (once collected) - device/browser integrity signals (where available)

2) Queue management for launches (when demand spikes)

For high-demand drops (tickets, limited releases), queue management isn’t just about performance—it’s about fairness and control.

A good queue does three things: - smooths traffic so your backend survives the spike - limits how many purchase attempts a single actor can run in parallel - gives you an enforcement point for risk decisions before users hit checkout

Ticketing platforms often describe “smart queue” approaches as a way to prioritise fans and reduce bot traffic during onsales (see an example of “Smart Queue” positioning here: Ticketmaster Smart Queue).

3) Step-up verification at the moment bots try to win

Don’t blanket-challenge everyone. Step up when your signals suggest automation: - high-velocity holds or add-to-basket - rapid retries after errors/timeouts - lots of parallel sessions that converge on the same SKU/seat map - suspicious networks + scripted flow behaviour

This is the “pleasant for humans, expensive for bots” sweet spot.

4) Make reservation and checkout flows harder to automate

Small engineering changes can break a lot of commodity bot tooling: - one-time tokens for holds and checkout steps - tokens bound to a session (reject session A token used in session B) - strict idempotency for checkout/payment actions - limit “quantity increase” frequency on scarce SKUs

This isn’t theatre. It forces bots to keep state correctly, which is where many of them fall apart.

A simple rollout plan (product + dev can agree on)

Here’s a plan you can actually ship before the next drop:

1. Instrument your key endpoints (hold/cart/checkout): attempts/min, success rate, time-to-complete, abandon rate.
2. Run detection in monitor mode briefly to baseline “normal” versus “launch” behaviour.
3. Ship Allow / Step-up / Block on hold + checkout first.
4. Add endpoint-specific rate limits with sensible keys (not IP-only).
5. Tune weekly using outcomes: conversion, timeouts, abandoned holds, support tickets.

Concrete example: start with step-up only when a single session attempts 10 holds in 30 seconds, or when a device makes repeated holds across many accounts. Keep the first version conservative, then tighten.

What to measure (so you know you’ve actually stopped scalper bots)

If your dashboard only celebrates “requests blocked”, you’ll optimise for drama.

Track: - Hold-to-purchase conversion (bots often hoard but don’t complete) - Abandoned holds and hold timeout volume - Step-up rate and step-up pass rate - Checkout conversion during launches versus baseline - Time to complete checkout for real users

A win looks like: inventory lasts longer, genuine customers get through, and your infrastructure stops melting at 10:00.

Where Humans Only fits

Humans Only is built for bot prevention that’s fast, privacy-first, and pleasant for real users—without frustrating image puzzles. You can deploy verification exactly where scalper bots attack (queue entry, holds, add-to-basket, checkout) and use real-time analytics to tune your allow / step-up / block policy with confidence.

If you’re ready to stop scalper bots without turning your launch into a fortress, Humans Only is designed for it: Stop Bots, Welcome Humans.