Kiosk System

The Kiosk System was a touchscreen application deployed at TOCA Social venues across the UK. Walk-in customers used it to book interactive football gaming sessions on-site. Customers with existing bookings could check in by scanning a QR code. The system connected to physical card terminals for payments and displayed real-time availability and pricing.

TOCA Social lets you play football games using the ball to hit the screen. To get into the venue, you needed to sync with the game systems and Playmaker Social. The kiosk synced with AWS, which synced with Playmaker to signal that you'd arrived and how many guests you had. The backend could then prepare the game before it connected to all the other services. It was imperative that people used this when they entered the building. The alternative was the Reception Desk, which required a staff member to be present. The kiosks let anyone self-check in instead.

Problem/Context

Before this, queue length and wait time were big issues. Walking into a venue and seeing a long queue of people didn't feel right. We wanted to automate the process, take the reliance off reception staff, and streamline things so anyone could check in. The kiosk also allowed on-the-fly bookings: you could query availability, see if boxes were free, and book and pay there and then. That meant integrating a hardware payment terminal, which became a concern around testing. We hired an external company to build it because the team didn't have enough resources. We were expanding and wanted to get this out fast.

Role/Contribution

I was the project manager for the external contractors. I signed off pull requests and made architectural decisions. The development team wasn't always available to come to our testing centres or the venue, so I had to set everything up myself and run tests in venue to verify the hardware touch points. I gathered requirements from venue operations, coordinated with backend API developers on integration contracts, and worked with Stripe to integrate their Terminal SDK for in-person payments. I defined the business rules for age restrictions (under-18 time constraints varied by day of week) and established the configuration approach for multi-venue deployment.

Architecture

The application was effectively a state machine: one state to the next, representing your check-in journey. It rendered its interface using SVG elements for precise touch target positioning on large-format displays. Payment processing followed a state machine pattern to handle terminal disconnections, card declines, and promotional code application. Each kiosk loaded configuration from a JSON file identified by its MAC address, enabling per-venue settings without code changes. It was a lightweight application.

Observability

Pingdom and CloudWatch monitored availability and health.

PWA

It ran as a progressive web app because we wanted to download it onto a Unix system and display it full screen. We added offline support so that when the network dropped, instead of showing "page can't be displayed", we showed a custom screen that said something like "reconnecting". The kiosks were front and centre when you walked in. We didn't want a bunch of screens saying "can't connect to the internet". It was easier for staff to see "reconnecting" and start fixing it.

Security

Stripe Terminal SDK handled the payment integration. Stripe handled most of the PCI and card handling for us.

Accessibility

The kiosk was built to WCAG 2.1 accessibility standards at the time.

Outcome/Impact

We didn't track queue time or usage formally. The qualitative outcome was clear: you could walk into the venue and no longer see the queues. Staff feedback was positive, and overall sentiment was good.