There is a scenario that plays out at hybrid and in-person events more often than anyone in the industry likes to admit. Someone registers for your conference, pays for four colleagues to attend with them, and receives a single confirmation email — for themselves. No QR code covers the group. The platform has no concept of five people being under one booking. Your organiser is working from a clipboard and a hunch.

The group arrives in two waves. Three people show up at 9 am. The other two follow at 10:15. The organiser manually cross-references the spreadsheet, guesses which tickets are still outstanding, and marks entries by hand.

After the event, it turns out two of the five didn't show. The booking was fully paid. No system knows what happened. The organiser wants to issue a partial refund but has no clean record of who actually arrived versus who didn't.

This is the group registration problem. And the reason it persists is not that organisers haven't noticed it —it's that most event platforms are architecturally built around a single registration, a single person, a single ticket. Groups are an after thought bolted onto a system designed for individuals.

The Root Issue Is Architectural, Not Operational

Most event QR code check-in systems generate a QR code tied to a single registration record. That works perfectly when one person registers, and one person attends. The moment a buyer registers on behalf of a group, the model breaks.

The typical workaround — asking each group member to register separately — creates a different problem: the buyer has to fill in a form five times, and the organiser has no way to see that these five registrations belong together. They lose the concept of the group entirely.

The correct architecture treats the buyer and the group as a single unit. One registration, one payment, one QRCode that represents the entire order. The platform needs to know how many tickets were purchased by type, who arrived and when, and what the remaining balance is at any point in time.

That's what we built into Virtrio, and the design decisions behind it are worth walking through — because they explain why this problem is harder than it looks.

What 'Correct' Group Check-In Actually Looks Like

When a buyer registers and selects quantities across multiple ticket types — say, two adult tickets, three children's tickets, and one infant ticket — those selections need to be captured as a single group order with individual line items. Not as six separate registrations. Not as a note in a comments field. As structured data that the check-in system can actually work with.

The QR code emailed to the buyer encodes a lookup reference for the entire order, not just their personal registration. When the organiser scans it at the venue, they see:

•      The event name and date

•      The registrant's name and reference number

•      Each ticket type, the purchased quantity, and the number already admitted

•      The remaining balance foreach type in real time

That last point is the one that changes how check-in actually works at a venue. The organiser is no longer checking someone in — they're recording a partial admission event against alive order.

Partial Admissions: The Feature Nobody Builds

The family of five arrives, and only three walk through the door first. The organiser enters: Adult = 1,Children = 2, Infant = 0. The system records that as one admission entry, deducts from the running balance, and updates the order state. Remaining: Adult= 1, Children = 1, Infant = 1.

An hour later, the same QR is scanned again. The organiser sees the updated balance. They record the second arrival: Adult = 1, Children = 1, Infant = 0. The infant didn't make it.

This multi-scan model sounds simple, but it requires the check-in system to maintain an append-only admission ledger per order — one that accumulates across multiple scan events and always reflects the live remaining balance. Most event QR code check-in implementation slack this concept. They treat a scan as a binary event: checked in or not.

The other thing worth noting about this design is that the QR token itself grants no access to the check-in page. Scanning it as an attendee gets you an 'Unauthorised' screen, not your own ticket details. The token is a lookup key. Only authenticated organisers with event-level permissions can view or act on it. Defence in depth, at the check-in layer.

After the Event: Reconciliation and Refunds

The admission ledger that powers real-time check-in also serves as the foundation for post-event reconciliation. Once the event is over, the organiser can open a reconciliation dashboard that shows, per group order, exactly what was purchased, what was admitted, and what was a no-show.

For paid events, the no-show data connects directly to refund processing. If two of the five tickets were no-shows, the organiser can issue a partial refund for exactly those two tickets, calculated as the quantity times the unit price at the time of purchase. The refund goes through the organiser's connected Stripe account. The platform records the refund status, tracks the Stripe confirmation, and surfaces any failures with a retry option.

Free events get the same reconciliation data — useful for venue capacity planning, catering, and future event design — without any refund controls appearing. The system gates refund functionality on whether a payment exists, not on a toggle. No unnecessary UI for something that doesn't apply.

The Design Principle That Makes This Clean

The entire feature was built as additive infrastructure — seven new database tables, zero modifications to existing ones. The current single-ticket registration flow is completely untouched when the feature isn't enabled. There's no performance overhead, no behavioural change, no risk to existing registrations.

Different registration sets within the same event can have different configurations. Your General Admission track can have multi-ticket group registration with QR check-in enabled. Your Speaker track can use the standard single-ticket flow. Both operate independently, with their own admission data.

This is the kind of architectural discipline that matters when you're running production events. New features shouldn't introduce risk to what's already working. They should slot in cleanly, activate when you need them, and disappear when you don't.

Group booking and partial admission tracking have long been a known gap in event infrastructure. The fact that most platforms still leave organisers with clipboards and guesswork at the door isn't a product problem. It's an architecture problem. And architecture problems have architecture solutions.

‍