NFC Points casino Kiosk + Live Leaderboard

• Built an in-house NFC card kiosk so players can scan their card and instantly see points and a live leaderboard.

• Replaced a vendor proposal (~€2k) with a lightweight system running on the arcade’s existing PC + USB NFC reader + display.

• Reduced “points desk” interruptions and gave staff simple tools (search, logs).

• Stack: Python (Flask), SQLite cache, USB NFC reader, Windows display, a small front-end (HTML/CSS/JS).

Why I built it

The casino i worked at (FunFair casino) was running a promotion where for every euro played in any of their locations around Ireland the player would get certain amount of points, all the players were ranked and the top 10 players on the leader board would win free cruise ship tickets. Players constantly asked staff to check their points. The operator had looked at a commercial solution, but the quote was expensive and came with recurring costs. I offered to prototype something small: a self-serve kiosk that reads the player’s NFC card, fetches their points, and shows a clean leaderboard on a large screen.

Constraints

• Use hardware already on site (existing Windows PC + monitor).

• Plug-and-play USB NFC reader.

• Hard on the “simple and reliable” rule staff shouldn’t need to babysit it.

My role & timeline

I scoped, built, and tested the whole system. First version took about a week to get working. I then spent a few short sessions hardening it and polishing the UI.

Stack & architecture

• Backend: Python Flask service that listens for NFC read events, looks up the player, and returns their points.

• Data: small SQLite cache (to avoid hitting upstream endpoints too often and to keep the kiosk snappy).

• Reader: USB NFC reader (keyboard emulation mode) → parsed and sanitized card IDs.

• Frontend: Minimal HTML/CSS/JS for the kiosk screen + a separate leaderboard view that auto-refreshes.

• Ops: Runs as a Windows service; logs to rotating files; one-click restart.

Build highlights

1. Fast reads, no fuss. The reader behaves like a keyboard, so I listen for a short “scan” sequence, validate it, and immediately show a spinner.

2. Caching to dodge rate/latency issues. Points can be cached safely for a short period; I store them in SQLite with timestamps, so the kiosk feels instant, even at busy times.

3. Two screens, two jobs. Kiosk view (big card + current points) and a separate leaderboard view that rotates top players each runs in full-screen browser mode.

4. Safety & privacy. Stored only what we needed: hashed card IDs and public display data. No personal details, no PII. Clear logs, easy purge command.

5. Admin bits that help. Small staff panel: search by card, re-calculate ranks, clear cache, download logs. These tiny touches saved a lot of back-and-forth.

Challenges & how I solved them

• Reader quirks. Some cards send trailing characters; I added a strict parser + checksum rules.

• Stability. Kiosk runs as a Windows service with a watchdog. If anything crashes, it auto-restarts and writes a short error log.

• Display burn-in / boredom. Leaderboard rotates between top lists and short “how to use” instructions to keep the screen useful for newcomers.

Results

• The in-house build replaced a ~€5k vendor quote with no recurring fees.

• Fewer “can you check my points?” interruptions for staff during peaks.

• Players liked the self-serve scan and the “race for the top” feel of the leaderboard.

• Maintenance has been close to zero—occasional cache purges and one update to the styling.

What I’d improve next

• A small staff tablet view for on-floor checks.

• More analytics (peak scan times, most active players) to help with promotions.

• Swap the keyboard-emulation NFC reader for an SDK-based reader to get richer events and better error handling.