Transforming the Fair Experience Through Digital Ticketing and Cashless Payments

Overview

It was 2009. The iPhone was two years old, QR codes were still mostly a curiosity outside Japan, and a family-owned traveling midway wanted to sell fair admission online and stop printing ride tickets altogether.

No product did that. Event ticketing platforms sold seats to one show at one venue on one night; this was dozens of independent fairs a year, moving from town to town, with rides and games and funnel cake all taking paper tickets at the point of sale. Nothing in the market came close.

So I built the thing instead. As the primary full-stack developer I designed and delivered a LAMP platform with its own content management system, QR-coded admission tickets, iOS and Android validation apps for gate staff, and a cashless midway where a customer’s own ticket became their wallet. Organic traffic grew more than 60 percent. Annual ticket sales grew more than 20 percent.

Organization

One of North America’s oldest and largest family-owned traveling midway operators: rides, games, and food concessions at fairs and festivals across the eastern United States.

The business is seasonal and it moves. Every few weeks the whole operation packs up and reassembles somewhere else, which means every system it depends on has to work in a field, on borrowed power, staffed by people hired for the season. Before this project, the customer experience was cash at a window and a strip of paper tickets — an approach that had worked for decades and was starting to look its age to anyone who had bought a concert ticket on their phone.

Challenge

The ambition was specific: be the first major traveling midway operator selling fair admission online, and eliminate paper ride, game, and food tickets entirely.

That is not an e-commerce website. Read the requirement honestly and it decomposes into eight systems that all have to agree with each other:

• Online admission sales.
• Secure digital ticket generation.
• Real-time validation at entry gates.
• Mobile applications for staff on the midway.
• Digital purchasing of ride, game, and food credits.
• A reusable customer wallet.
• Content management for dozens of seasonal events.
• A rebuilt public website to sell it all from.

Each piece existed somewhere in the market. Nothing joined them, and nothing understood a business where the venue changes every two weeks. Custom was not a preference. It was the only option that met the requirement.

Solution Architecture

I came to the project on a recommendation after finishing another enterprise engagement, and built the platform on LAMP — Linux, Apache, MySQL, PHP.

The first real decision was the content management system. Adapting an existing one would have meant bending the business to fit the software: fairs are not blog posts, and a seasonal event with its own ticket inventory, its own dates, and its own promotional calendar does not map onto a generic page tree without a fight. I wrote one instead, shaped around how the company actually operates — seasonal events, website content, ticket inventory, promotions, and fair-specific information under one administrative roof.

In performance testing it comfortably outran several widely adopted open-source CMS platforms of the period. The more useful outcome was that nothing in it existed for a use case the company did not have, and every feature could be tuned for the ones it did.

That CMS became the backbone the rest of the platform hung off.

Digital Ticketing Platform

The ticketing system had a harder job than a normal event ticket.

Dozens of independent fairs run through a season, each with its own dates and gates, and every ticket sold needs to be unique, verifiable in a field, and impossible to use twice. I designed it around QR codes, with each ticket carrying an identifier tied to a single transaction.

• Secure online purchasing.
• Automated QR code generation.
• Unique identifiers per ticket.
• Real-time validation at entry.
• Single-use enforcement, so a screenshot gets you in once.
• Integration with each fair’s event information.

Gate staff scanned, got an immediate verdict, and moved the line along. That last part is the whole point — a validation system that takes three seconds per guest is a validation system nobody uses by August.

Mobile Applications

Gate and midway staff needed to scan, and the answer could not be dedicated hardware. Specialized scanners cost money, break in the rain, and have to be shipped between venues with everything else.

So I built companion applications for iOS and Android that turned a phone into a validator, checking each code against the central platform in real time. The web platform reached out into the field on devices people already had in their pockets.

Cashless Midway Platform

This is the part that had not been done in the industry before.

Once inside the fair, a visitor scanned their own admission QR code and landed in a personal event portal where they could buy ride, game, and food credits. No second ticket, no strips of paper, no counting how many tickets a ride costs while a queue builds behind you. The QR code they already had became their balance.

Vendors scanned that same code to redeem credits for a ride, a game, or a corn dog. Run low, buy more from your phone, keep going. A digital wallet before most people had a word for one — and in an industry where the alternative was a cash box and a roll of tickets.

Purchases got simpler, lines got shorter, and an entire category of paper disappeared from the operation.

Website Modernization

In parallel I worked with an award-winning creative designer on a full rebuild of the public website, covering usability, visual identity, navigation, and performance.

It had two jobs: be the face of the company, and be the front door for ticket sales. Getting the second one right is why the traffic growth turned into sales growth rather than just traffic.

Results

The paper-and-cash operation became a connected one, with website management, online commerce, mobile apps, admissions, and midway payments all in the same system.

• The company’s first online ticket sales platform, launched.
• QR-code digital ticketing, integrated end to end.
• iOS and Android validation apps in the hands of gate staff.
• A cashless midway covering rides, games, and food.
• Paper ride, game, and concession tickets eliminated.
• Organic website traffic up more than 60 percent after the redesign and launch.
• Annual fair ticket sales up more than 20 percent after online purchasing went live.
• A platform that scaled across a full season of venues.

Early adoption is only worth something if it works on the first weekend, in a field, with real customers who did not sign up to test anything. This did.

The project was never really about software. It was about taking a business vision — no more paper, buy from your phone — and deciding what had to be true for it to happen: web, mobile, commerce, digital identity, payment flows, and the operational reality of staff who get hired in June. I led the architecture, the development, the integrations, and the deployment strategy, and worked with design stakeholders to keep it feeling like one product rather than seven.

Key Technologies

• Linux
• Apache
• MySQL
• PHP
• LAMP Stack
• Custom Content Management System (CMS)
• QR Code Technology
• E-Commerce
• Mobile Application Development
• iOS
• Android
• REST APIs
• Digital Wallet
• Ticket Validation
• Systems Architecture
• Full-Stack Development
• Responsive Web Design

Lessons Learned

Transformation works when it follows the whole customer journey rather than one step of it. Had this project shipped only online admission sales, the customer would still have queued at a ticket booth inside the gate with cash in hand, and the headline would have read “now with a website.” Joining content, commerce, mobile, admissions, and payments is what made the difference people actually felt.

The other lesson is about when to build. Off-the-shelf is almost always right, and it was wrong here — not because the products were bad, but because no product had ever been asked to run a business that relocates every two weeks. When the requirement genuinely has no precedent, building is the cheaper option, and it buys you something a license never does: a couple of years where your competitors cannot do what you do.