Scalping bots
Scripts that add tickets to carts the moment a sale opens. Driven browsers and declared scrapers are reported at queue and cart.
Tickets for fans. Not for scripts.
On-sale moments are won by whoever is fastest, which rewards automation. Fingerly reports driven browsers, scrapers, hosting networks and repeat devices at queue, cart and checkout, so a ticketing platform can slow the scripts and let fans through.
- Bot detectionDriven browsers and scrapers.
- Repeat buyersCount purchases per device.
- Network contextHosting networks and proxies.
- Fast checksNo captcha in the queue.
[ 01 / 06 ]Abuse patterns
How abuse reaches ticketing and events.
Ticketing abuse is concentrated into a few minutes. These are the patterns that most often reach on-sales and resale-sensitive events.
Purchase-limit evasion
Buyers who create several accounts to exceed a per-person limit. A visitor ID counts the purchases behind the devices.
Proxy and datacenter traffic
Bots spread across proxies and hosting networks to avoid per-address limits. The network behind each request is reported beside the device.
Account takeover of fan accounts
Stolen logins used to buy with saved cards or to take over a purchased ticket. A new device on an anonymised network is the pattern to look at.
Card testing at checkout
Stolen cards tried against ticket checkout under the cover of a busy sale. The session is flagged for automation and unusual activity.
Presale and code abuse
Presale codes and promo offers passed around or claimed in bulk. Repeat claims are visible per device.
[ 02 / 06 ]Pattern to decision
From pattern to decision.
Fingerly does not run a queue and does not enforce limits for you. It reports what is behind each request so that your queue and your rules can.
01
Scalping and hoarding bots
Put the check where automation gets paid.
Identify at queue entry, at add-to-cart and at checkout. Automation, declared scraper and virtual machine signals together are a strong reason to refuse or slow the session; a single weak signal is a reason for a challenge.
- Check at
- Queue entryAdd to cartCheckout
- Reads
- AutomationDeclared bot or scraperVirtual machine
02
Per-person purchase limits
Count tickets per device, not per email.
Store the visitor ID with each order. A device buying far beyond the limit under many emails is visible, and so is a cluster of accounts sharing one. Families and offices can share a device, so review before you cancel.
- Check at
- CheckoutOrder confirmation
- Reads
- Visitor IDHigh activityDevice farm
03
Proxied and hosted traffic
See the network behind the request.
Datacenter proxies, hosting networks and Tor exits are classified on every identification. Weight them as context: a customer on a VPN is not a script on a datacenter proxy, and your policy should know the difference.
- Check at
- Queue entryCheckout
- Reads
- Datacenter proxyHosting networkResidential proxy
04
Takeover of fan accounts
Protect saved cards and bought tickets.
Recognise the devices a fan normally uses. Step up when a login from a new device also carries automation or an anonymised network, especially before a ticket transfer.
- Check at
- LoginTicket transfer
- Reads
- Visitor IDTor exit nodeAutomation
[ 03 / 06 ]Integration
Integrate at the right moments.
Four habits keep a policy for ticketing and events effective without turning it against genuine customers. A production identification is billed per request, from $0.0025, so it is worth placing where it earns its cost.
- 01 Identify at the moment
Call identify at queue entry, add-to-cart, checkout and ticket transfer, not on every event page. Pass your own order or account reference as the tag so the result comes back with the action.
await fingerly.identify({ tag: "checkout" }) - 02 Verify on your server
Send only the request ID to your backend, read the stored result with a secret key, and check that the tag matches the action. At on-sale speed the decision still belongs on the server.
- 03 Observe before you enforce
Rehearse in monitoring mode on a smaller on-sale. Record what each rule would have done, measure how many genuine fans it would have affected, then enforce.
- 04 Act in proportion
Slow or refuse clear automation, challenge uncertain sessions and review purchase-limit clusters after the sale, with a way for a genuine buyer to complete a purchase.
[ 04 / 06 ]Moments
Where to check, what to do.
Where a ticketing platform usually places the check and what it reads there.
| Moment | Identify when | Read | Usual first decision |
|---|---|---|---|
| Queue entry | The fan joins the queue | Automation, hosting network | Slow automated sessions |
| Add to cart | Before the hold is placed | Automation, declared scraper, high activity | Refuse or challenge |
| Checkout | Before payment | Suspect score, visitor ID | Challenge above your threshold |
| After the sale | When orders settle | Visitor ID | Review purchase-limit clusters |
| Ticket transfer | Before it is sent | Visitor ID, Tor exit node | Second factor for new devices |
Every decision is yours. Fingerly returns the visitor ID, the signals and the suspect score, and never blocks a request by itself.
[ 05 / 06 ]Questions
Questions about ticketing and events.
How a ticketing or event platform uses device fingerprinting against bots and hoarders.
Talk to the teamHow can ticketing platforms stop scalping bots?
Fingerly helps a ticketing platform see them: it reports driven browsers, declared scrapers, virtual machines, hosting networks and unusually busy devices at queue, cart and checkout without a captcha. Your platform decides whether to slow, challenge or refuse, and no detection stops every bot, so keep your own rate limits.
Can Fingerly enforce a ticket limit per person?
It gives you the evidence, not the rule. Store the visitor ID with each order and count tickets per device, then apply your limit. A shared device is possible, so review a cluster before cancelling a genuine fan’s order.
Will bot detection slow the queue down?
Fingerly shows nothing to the fan, and the browser SDK answers after an initial collection budget of 300 milliseconds. Identify at the moments that matter rather than on every page, so the queue is not asked more than it needs to be.
Can it see through proxies and VPNs used by resellers?
It classifies the connection as a commercial VPN, a datacenter or residential proxy, a Tor exit node or a hosting network, and flags a mismatch with the device’s region. Residential proxies are the hardest kind to tell from a real visitor, so use them with device signals.
Does it work on mobile ticketing apps?
Yes. Native iOS and Android SDKs, with React Native, Flutter and Lynx bridges, send the same identify request as the web SDK and add checks for emulators, rooted and jailbroken devices and cloned apps. In an app the device is a random install ID, never its hardware.
Less guessing. More knowing.
Make the next connection a trusted one.
Start with the signals, keep your own decisions, and pay as you go, only for what you identify. No credit card needed.