Checkout Bots Explained: Scrapers, Card Testers, Scalpers

Your checkout log shows a traffic spike and the team calls it bots, as if that were one thing. It is at least three. One visitor copied your prices, one tested stolen cards at a dollar a try, and one bought the drop your customers wanted. Same hour, same word, three different problems.

Scrapers: the ones that never meant to buy

A price scraper walks product pages and records prices, stock levels, and sometimes reviews. Cloudflare draws the line plainly in its scraping guidance: crawling for search indexing or price comparison is ordinary web traffic, while scraping that hammers origin servers or republishes a catalogue is abuse. At checkout, scrapers show up as carts built and abandoned in patterns no shopper makes, full carts, no payment attempt, repeated on a schedule.

The cost is infrastructure and information, not lost sales. Your prices feed a competitor's repricing tool within the hour, and the crawl load lands on the same origin your buyers need. Rate limiting by session behaviour and serving cached prices to fast, repetitive visitors handles most of it without touching real checkout.

Card testers: small charges, large intent

Card testing uses your checkout as an oracle. A bot submits stolen card numbers in small transactions, often a dollar or less, to learn which cards are live before using them elsewhere for larger fraud. OWASP groups this with credential and card stuffing attacks because the mechanics match: high volume, small value, success rate is the metric the attacker watches.

Your tells are a rising share of declined authorisations, many cards per device or address, and amounts clustered at your minimum. The defence sits at payment: velocity limits per card fingerprint and per session, and a challenge that appears when decline rates spike, not a permanent wall for every buyer.

Scalpers: the ones who complete the purchase

Scalping bots do the thing the other two avoid: they pay. They complete checkout faster than a human can type an address, using stored profiles across many accounts, and they target limited stock. HUMAN Security's work on automated purchase abuse stresses that these requests can look technically clean, valid payment, real addresses, residential IPs, which is why bot scores alone miss them.

What gives them away is shape, not a single flag: account age measured in days, first purchase being the scarcest item in the catalogue, and delivery addresses clustered in ways your normal buyers are not. Queues, per account purchase limits, and holding scarce items out of general search results until the drop opens each cut a different part of that shape.

One defence for three problems is no defence

This is the part teams resist. The control that stops a scraper, aggressive rate limits on product pages, does nothing to a scalper who makes three careful requests. The control that stops card testing, payment velocity checks, never fires for a scraper that never pays. Buying one bot product and pointing it at all three usually means one problem gets managed and two get a dashboard.

Split your reporting the same way. Report scraper volume, card testing attempts, and suspected scalped orders as three lines with three owners. The month the lines merge back into a single bot percentage is the month the detail that made the controls work starts to rot.

Keep reading: Money mules recruited through romance chats: the account pattern platforms can see, Fake verification badges for sale: how the scam prices trust it cannot deliver.