Customers · Sep 1, 2026 · 6 min read

Ticket vendor: keeping resale inventory in fans' hands

How a UK ticket resale platform stops scalper bots taking capped-price tickets ahead of fans, including software pretending to be phones and racks of real handsets driven by automation.

Chris Taylor

Prosopo

In short

Customer: A UK ticket resale platform. Prices capped at face value plus a booking fee.
Problem: Scalper operations taking capped-price inventory ahead of fans, across the ticket page, queue gate, listings feed and checkout API.

Scalper bots stopped at the API, not just the checkout form
Fake phones and racks of real phones both caught
84% of real visitors never see a puzzle
Support can read why someone was stopped, without escalating

“A major ticketing company recently introduced Prosopo bot protection to their site which makes it near impossible to now scrape or use APIs the website itself uses without being a human.”

A publicly available scraping toolkitNot a customer testimonial. This is an attacker documenting why they dropped support for the platform.

This customer runs a ticket resale platform in the UK. Tickets are capped at face value plus a booking fee. That cap is the whole point of the business and also the reason it is attacked. A capped-price ticket that resells elsewhere for several times face value is an arbitrage, and where there is an arbitrage there is automation.

The problem

Scalper operations were acquiring capped tickets ahead of real fans. The pattern is familiar from primary ticketing: monitor for a listing, warm up accounts in advance, route each request through a different residential or mobile IP so every bot looks like a distinct buyer, then complete checkout faster than a person can load the page.

What makes resale harder to defend than primary sale is that there is no single on-sale moment to prepare for. Listings appear continuously as fans post tickets they cannot use, so there is no quiet period.

The platform does not have one form to protect. It has a ticket page, a queue gate, a listings feed and a checkout API, and the automation was hitting all of them. A CAPTCHA on the checkout form would have been routed around by going straight to the API the site itself uses.

So the deployment is Prosopo Protect at the edge. Every request to the site is scored before it reaches origin, and the verdict applies whether the request came from a browser, a script or an app.

The two hardest kinds to stop

Two kinds took the longest to stop.

Phones that are not really phones. These run a genuine mobile browser inside software pretending to be a handset, on rented server hardware. The operating system is real, the browser is real, and most of what the session reports about itself is true. Nothing has been faked badly.

What gives them away is speed. Certain calculations take a predictable length of time on a real phone's processor, and a different length of time on a server's. Measuring that reveals the claim without needing anything the client says about itself to be false. The block reads Claimed a device it was not running on, and the detail behind it is in our SIMD glossary entry.

Racks of real phones. Genuine handsets, wired up and driven by software. There is nothing fake about the hardware, so nothing about the device gives them away. These are caught on how they behave: taps and scrolls with a rhythm that repeats too exactly, and click sequences a person's hand does not produce.

Between them, these two are why detection cannot rest on identifying the device. If a defence works by spotting a fake phone, an attacker who buys real phones walks straight past it.

What the operations team sees

Every block comes with a reason you can read. When a fan contacts support saying they could not check out, the support agent can pull the request by ID and read the reason rather than escalating to engineering and waiting.

It matters more on a resale platform than elsewhere. A false positive here is not an abandoned basket but a fan who missed an event, and that becomes a public complaint.

Results

Automated sessions stopped

79,711

out of 1,004,817 scored, or about 1 in 13

30 days to
1 September 2026

Sessions scored

1,004,817

Every request to the ticket page, queue gate, listings feed and checkout API.

Stopped as automated

7.9%

79,711 sessions. The rest reached the site.

Real visitors who solved nothing

84%

Resolved by proof of work, which the browser completes on its own. No puzzle, no images.

The last figure is the one a ticketing operator should care about most. Of the 940,047 sessions that were not blocked, 84% were cleared by proof of work: the browser does a fraction of a second of computation and the visitor does nothing at all. Around one in seven saw an image challenge, and 3% a puzzle. Blocking bots is straightforward if you are willing to make everyone prove themselves; the difficulty is doing it without making fans queue twice.

Why sessions were blocked

30 days

Address already known for abuse

46,482

Connected through a network used to hide traffic

26,483

Session handed over to a different device

3,708

Went straight to the API, skipping the site

2,859

Claimed one operating system, behaved like another

1,885

Browser could not keep its story straight

747

Paid a service to solve the challenge

745

Claimed a device it was not running on

186

Reasons returned on the block itself, with related network reasons grouped into one row. The last row is the phones-that-are-not-phones population described above: 186 sessions claiming to be an iPhone or iPad while running on something else.

Two things worth drawing out. The largest category is an address already flagged from earlier abuse, the detection pipeline doing its job ahead of time: once a pattern is established the platform stops re-deriving it on every request and blocks on a cheap comparison at the edge instead. And the smallest rows are the interesting ones. A scalper operation that has been reduced to 186 sessions on a spoofed device and 745 through a solver service is an operation that has run out of cheap options.

Running an on-sale and worried about bots?

Tell us about your platform and your next on-sale date. We will look at your current setup before we reply.

Frequently Asked Questions

What problem was the ticket vendor solving?

A resale platform that caps prices is a target for exactly the automation it exists to prevent. Scalper operations were using automated clients to acquire capped-price tickets ahead of real fans, then reselling them elsewhere at a markup.

How is Prosopo deployed?

At the edge, in front of origin, rather than as a widget on a single form. Every request is scored before it reaches the application, so the ticket page, the queue gate and the checkout API are all covered rather than one form.

What kind of bots were hardest to stop?

Two kinds. Software pretending to be a phone, running on rented servers, where everything the session reports about itself is true but the hardware underneath is not a handset. And racks of real phones driven by automation, where the hardware is genuine and only the behaviour gives them away. Neither can be caught by checking whether the device looks real, because in both cases it does.

Why is ticket resale harder to protect than a primary on-sale?

A primary on-sale has a start time, so defences can be tightened around a known window. On a resale platform, listings appear continuously as fans post tickets they cannot use, so there is no quiet period and no moment to prepare for.