How Nairobi Event Organisers Can Prepare for Ticket-Sale Spikes, Bots and Fraud

For organisers · Operations & security

High demand is good news until the ticketing flow becomes the bottleneck. A Kenyan football sale in August 2025 showed how quickly buyers can lose confidence when a portal is overwhelmed. The practical response is not one anti-bot trick; it is layered capacity, purchase controls, secure ticket delivery and a rehearsed incident plan.

What happened during the Kenya–Madagascar CHAN ticket sale?

The incident is worth dating correctly because it is sometimes repeated without the year. On 19 August 2025, not 2026, the ticket sale for Kenya’s CHAN quarter-final against Madagascar ran into serious problems. Eastleigh Voice reported that the Mookh portal was overwhelmed after tickets went live and that Mookh attributed the disruption to automated bot traffic. The article also quoted cybersecurity specialist Charles Mwaniki cautioning that heavy legitimate traffic, server capacity and system design can also contribute to this kind of failure.^[1]

That distinction matters. A traffic spike does not prove a bot attack. For an organiser, the operational question is broader: can the ticketing stack distinguish normal demand from abusive automation while staying available to real buyers?

What do ticket bots actually do?

OWASP classifies scalping and denial of inventory as recognised forms of automated abuse. In practical terms, scripts can attempt to reserve scarce inventory faster than a human, create multiple accounts, repeat checkout requests or hold stock without completing payment. OWASP recommends controls such as virtual waiting rooms, server-side purchase limits, identity-linked limits and timed inventory holds.^[2][3]

International enforcement shows why this is treated seriously. In the United States, the Federal Trade Commission says the BOTS Act prohibits circumventing ticket issuers’ security measures or purchase limits for covered events. That law does not govern Kenyan events, but it demonstrates the same underlying risk: automated buying can distort fair access to limited inventory.^[5]

1. Separate a traffic problem from an inventory problem

A website can fail even when nobody is behaving maliciously. If 5,000 legitimate buyers arrive in the same minute, the payment flow, inventory service or database can become the choke point. Before a high-demand drop, the organiser should ask the ticketing provider what load has been tested, what happens when payment callbacks are delayed and whether tickets are temporarily held during checkout.

This is also why staged releases can be useful. Instead of placing all inventory behind one timestamp, a presale, member release or phased allocation can spread demand and reveal weaknesses before the largest audience arrives.

2. Enforce purchase limits on the server

A message that says “maximum four tickets” is not a control unless the system enforces it. OWASP recommends server-side purchase limits tied to more than one signal where appropriate, because determined buyers can rotate accounts or sessions.^[2] The exact controls should match the event’s risk; a 200-person workshop does not need the same defensive stack as a national football match.

3. Make the ticket difficult to copy

Ticket fraud does not end at checkout. Static PDFs and screenshots can be forwarded, duplicated or resold repeatedly if the scanning workflow has no way to invalidate them. Tikosocial’s current website says its tickets can use rotating encrypted QR codes and that scanners can work offline at the gate. It also advertises capped resale and one-tap transfer between buyers.^[4]

Those are Tikosocial’s stated product capabilities rather than an independent security audit, so organisers should still test them. Scan the same ticket twice. Put scanners offline. Transfer a ticket and test the old QR. Run the failure cases before paying customers arrive.

4. Design the gate for exceptions

Fraud prevention can create its own queue if staff have no exception process. Decide in advance how to handle a buyer who has changed phones, lost email access, arrived with a screenshot, or says a friend transferred the ticket. Give one supervisor authority to resolve exceptions while the normal scan lanes keep moving.

The organiser should also know which data is visible to gate staff. Exposing unnecessary personal information creates a different risk. The scanner needs enough information to validate entry, not the buyer’s entire profile.

5. Prepare the communication before something breaks

If sales fail, silence amplifies frustration. Prepare a short incident message before launch that can state what is affected, whether payments already made are safe, whether the queue will reopen, and where the next official update will appear. Do not promise a restart time until the platform confirms it.

Use one canonical sales link in social posts and email. That also reduces the risk of buyers following fake ticket pages during a high-interest moment.

A pre-sale checklist for small and mid-sized events

• Run a test purchase on M-Pesa and card from start to QR delivery.
• Confirm the maximum purchase limit and how it is enforced.
• Ask what happens when inventory is held but payment fails.
• Test duplicate scans, transfers and offline scanning.
• Give one person ownership of the ticketing provider relationship on sale day.
• Prepare customer updates and the official link before launch.

The goal is not to make a small Nairobi event behave like a global stadium tour. It is to remove obvious single points of failure. Capacity, purchase controls, secure ticket validation and clear communication solve different parts of the same problem. Layer them, test them, and make the failure process as deliberate as the happy path.

Frequently asked questions

Related guides

• QR ticketing and event fraud prevention
• Compare event ticketing platforms