An event admission system has to answer three questions reliably: who is expected, what access they purchased or received, and whether an entry has already been accepted. QR codes are merely one way of presenting a credential.
This guide is part of the NexisHub Event Technology desk. It connects practical engineering, research, and product decisions to the wider NexisHub platform.
The operating idea
Consider an event whose registration desk has intermittent internet access. An attendee arrives with an invitation, but a second device already checked in the same code. The system must respond without creating a second admission, losing the original record, or turning volunteers into database administrators.
This article is a proposed engineering design and worked example for event operations. It is not a claim that NexisHub has deployed this exact event system or processed real ticket sales.
NexisHub separates verified platform documentation, repeatable observation, and inference. No optimization can guarantee selection or citation by an external system.
Worked example: one ticket scanned twice
Suppose ticket EVT-042 belongs to a single-admission session. At 18:05, two check-in devices submit a scan nearly simultaneously. If the server simply reads `status=unused` and updates it afterward, both may receive an accepted response. The correct transition must be atomic: accept exactly one scan for that ticket and event, and return 'already admitted' for subsequent scans with the first acceptance time and an escalation option.
A conceptual record has `ticket_id`, `event_id`, `attendee_id`, `eligibility_status`, `checkin_status`, `admitted_at`, `gate_id`, and a version or event ledger. Use a unique constraint or transactional compare-and-set operation for admission. A scan retry should carry an idempotency key so timeouts cannot produce contradictory responses. Do not store unnecessary identity documents simply to make gate operations convenient.
Offline is a reconciliation problem
At a venue with unreliable connectivity, a device may need a limited, signed roster and an expiry policy. Offline acceptance can reduce queues, but two disconnected gates can independently accept the same credential. The product must disclose that tradeoff and define the staff's response when devices reconcile.
Design a sync log with device identity, monotonic local sequence, ticket reference, decision time, server receipt time and conflict outcome. Test clock drift, stolen devices, roster expiry, revoked tickets, duplicate scans, and a reconnect after hours offline. A QR image by itself solves none of these.
Boundary between payment and admission
Payments, refunds and attendance are separate domains. A webhook indicating payment completion may arrive late, be duplicated or fail signature verification. Only server-verified, authorized payment events should change ticket eligibility. An attendee should not become 'paid' because the frontend received a success URL.
A refund issued after a ticket has been scanned presents a policy question, not merely a code branch. Define the permitted refund window, whether staff can reverse admission, and who reviews financial exceptions. Preserve the original payment event and the later decision as separate records.
Core principles
- Make check-in idempotentRepeated submission of the same accepted request must not count another admission.
- Treat access as a state machineSeparate invited, confirmed, eligible, admitted, cancelled and revoked conditions.
- Isolate events and rolesA gate operator for Event A must not search or edit Event B's attendee records.
- Make exception handling usableDefine escalation for mismatched names, cancelled tickets, device failure and offline conflicts.
A practical implementation workflow
Apply the work in a controlled sequence. Keep a baseline, name an owner, and define the evidence that will show whether each step was completed.
- 1. Specify the admission policyDetermine capacity, transfers, re-entry, minors, payment and exception rules before building screens.
- 2. Model authoritative stateKeep ticket validity, payment eligibility and check-in events in auditable records.
- 3. Design the minimum gate interfaceShow a clear accepted/rejected state, actionable reason and safe manual resolution.
- 4. Test adversarial sequencesScan duplicates concurrently, revoke a ticket, queue offline scans, restart a device and retry after timeout.
- 5. Reconcile with business recordsCross-check issued tickets, financial eligibility and accepted entries before producing attendance totals.
Common mistakes
Using QR as the source of truth
A code is a credential, not proof that a ticket is currently valid or unused.
Assuming online-only flow
Gate Wi-Fi loss creates operational failure unless an explicit fallback and reconciliation plan exist.
Counting scans as attendees
Failed scans, retries, staff tests and re-entries can inflate attendance.
How to measure it responsibly
Track unique authorized admissions, rejected scans by reason, median scan response time, staff override rate, reconciliation conflicts and the time required to close them.
Compare total accepted admissions against authoritative ticket records after the event. Keep financial settlement figures separate from admissions; an attendee can register without attending.
Keep observed outputs, diagnostic scores, inferred causes, and business outcomes in separate fields. A modelled score is not a citation, and correlation is not proof of cause.
What comes next
The worthwhile next step is a tabletop rehearsal with gate operators, not a feature list. Run a simulated queue, force connectivity loss and refine the exception paths before any real event use.
The durable response is to build pages that are accessible, semantically explicit, useful outside their original layout, and backed by evidence a reader can inspect.
Key takeaways
01A successful check-in is an authoritative, auditable state transition.
02Concurrent duplicates must produce at most one admission.
03Offline mode trades speed against reconciliation risk.
04Payment confirmation and attendance belong to separate processes.
Frequently asked questions
Can one QR code be scanned twice?
Technically it can be presented repeatedly. The server should enforce the event's admission policy and reject unauthorized duplicate use.
What happens without venue internet?
Choose an explicit offline fallback, restrict the cached roster, and reconcile conflicts later; do not promise globally unique admission without connectivity.
Does a payment success page prove ticket eligibility?
No. Validate payment through authoritative provider events and server-side state before issuing admission rights.
References and further reading
Turn a useful idea into a maintainable product.
Nexis Studio helps organisations move from problem definition to product design, engineering, launch, and long-term support with clear technical and commercial boundaries.
Explore Nexis Studio