83% Drop in Scalper Bot Activity for Online Travel Platform

The Problem

The OTA sells rail and flight tickets across the UK and Western Europe, with inventory that goes on sale at launch windows for popular routes. During these launches, low-fare inventory was routinely sold out within the first two to four minutes — before most real customers could complete a booking.

Customer support tickets told the story clearly: "sold out immediately," "couldn't get through," "prices doubled overnight." Checkout completion for real users dropped to 34% during launch windows as the checkout pipeline was hammered by bot traffic holding inventory in cart sessions that never converted. A spot check of secondary market listings showed dozens of the same tickets listed at 3–5× the original fare, posted within minutes of the launch window opening.

The bots were faster, more persistent, and more numerous than any human buying flow. They weren't breaking into the system — they were simply winning the race to hold inventory on every popular route.

The Attackers

Post-incident analysis identified three categories of bot operation, all running in parallel against the same inventory hold endpoint:

• Custom Puppeteer and Playwright scripts with per-session browser fingerprint rotation — each session presented a fresh browser profile with randomised user agent, viewport, and timezone
• Multilogin-based operations simulating multiple independent "real" users, with separate browser profiles each routed through different residential proxy exit nodes from Oxylabs and SOAX
• Bulk residential proxy rotation — no single IP address was reused across sessions, meaning standard rate limiting by IP had zero effect

The infrastructure cost per thousand bot sessions was low enough that even a 1-in-20 success rate on a popular route — grabbing a single resaleable ticket — was profitable. The economics strongly favoured the scalpers.

Why CAPTCHAs Made Things Worse

Before Sentinel, the platform had added reCAPTCHA v2 to the checkout flow in an attempt to block bot traffic. The results were counterproductive on both sides:

• Scalper bots routed CAPTCHA challenges to third-party solving farms at approximately $0.001 per solve — the latency difference between a human solve and a farm solve was negligible at automation scale
• Real customers on mobile networks and older hardware faced solve rates that added 4–8 seconds of friction per checkout attempt
• Legitimate checkout conversion dropped 8% across all traffic within two weeks of CAPTCHA deployment
• Bot session volume was unchanged — the CAPTCHA added cost but not enough to change behaviour

The CAPTCHA was defending the wrong layer. The bots weren't being stopped by a challenge that humans find difficult; they were being stopped by nothing, because the challenge was trivially solvable at scale.

Sentinel's Detection Approach

Sentinel evaluates the browser and network environment at the point of the inventory hold — the moment a session attempts to place a ticket into a cart before checkout begins. This is the critical chokepoint: block bot holds, and real customers can reach inventory they couldn't previously access.

The compound signals that flagged scalper bot sessions on this platform:

• Headless browser artifacts — Chrome headless and Puppeteer environments leave detectable signatures in navigator properties, WebGL renderer strings, and timing behaviours that persist even with fingerprint randomisation active
• Playwright-specific signals — Playwright injects detectable patterns into the automation control channel that are visible at the JavaScript environment level regardless of stealth plugin configuration
• Residential proxy classification — ASN-level routing analysis identified Oxylabs and SOAX exit infrastructure even when surface IPs appeared clean and residential
• Device velocity across IPs — the same physical device hardware profile hitting the inventory hold endpoint across dozens of different IP addresses within a launch window is a strong compound signal, invisible to per-IP rate limiting but clear at the device layer
• Superhuman form interaction timing — bots filling checkout forms complete field interactions in 80–120ms; human users average 900ms–2.4 seconds per field interaction on mobile

The Integration

Sentinel was integrated at the inventory hold endpoint — the server-side call that reserves a ticket for a checkout session. The monocle client token is collected at page load and submitted with the hold request. The full evaluation completes in under 200ms, well within the window before any user-visible latency occurs.

The "fake hold" pattern for confirmed bot sessions — returning a plausible success response that ties up the bot's session slot without consuming real inventory — was particularly effective. Rather than revealing the detection and prompting the scalper to adapt their tooling immediately, the platform silently fed bots phantom hold IDs that expired without any inventory being locked.

Results

Why WAFs and Rate Limiting Fall Short

Web application firewalls are designed to block malicious request patterns — SQL injection, path traversal, known attack signatures. They were not designed to distinguish a bot running Puppeteer from a traveller using Chrome. Both generate HTTP requests that look identical at the WAF layer.

Per-IP rate limiting has the same problem. A scalper operation routing through residential proxies from Oxylabs or SOAX will use hundreds of different exit IPs across a single launch window. Rate limiting by IP catches operations that use one or two IPs — it does nothing against distributed residential proxy fleets where no single IP exceeds any threshold.

Sentinel operates at the layer these tools cannot reach: the browser environment and hardware signals that reveal what kind of client is actually making the request. A Puppeteer script running on a datacenter VM, routing through a UK residential proxy exit node, looks like a clean UK residential user to a WAF. It does not look clean to Sentinel.