+91-8727000867
+64 22 003 5555
Event platform planning guide
QR Check-in & Event-Day Testing Checklist
Plan ticket validation, duplicate scans, offline reconciliation, payment exceptions and event-day rehearsals before your first attendee arrives.
The short answer
A QR check-in test should verify entry rights, duplicate scans, cancellations, re-entry, permissions and recovery under realistic device and network conditions. A successful scan alone is insufficient. Offline devices cannot instantly know what another disconnected device has accepted, so the operating plan needs reconciliation and a staffed fallback.
Define what a ticket permits
Treat the code as a way to look up or validate an entitlement. Define the event, session, date, ticket state and permitted entry count. Avoid putting unnecessary attendee information in the code. Staff should see only the information their role requires.
Separate booking, payment, refund and attendance records. A refund after entry should not erase the attendance history. Whether a cancelled place returns to sale depends on the agreed inventory policy.
Use a test matrix that includes exceptions
On smaller screens, scroll sideways to compare the columns.
| Scenario | Expected behaviour to agree | Evidence to retain |
|---|---|---|
| Valid paid ticket | Accept once at the permitted event or session. | Ticket, gate, operator, device and decision time. |
| Repeated or simultaneous scans | Resolve competing connected scans consistently; make the previous admission visible. | Both attempts and the authoritative outcome. |
| Pending payment or refund | Apply the agreed entry policy and direct exceptions to an authorised operator. | Booking state, provider state and operator action. |
| Cancelled ticket or wrong event | Deny entry with a useful reason without exposing unrelated attendee data. | Decision and support path. |
| Lost network connection | Use the agreed offline or manual procedure, with clear provisional status. | Local actions, sync state and later reconciliation. |
| Re-entry | Apply the configured exit/re-entry rule rather than resetting the original record. | Complete entry history. |
Reconcile payment notifications safely
Payment providers can deliver asynchronous notifications. Verify their authenticity and design processing so repeated notifications do not issue another ticket or apply the same change twice. Reconcile booking state with the provider when delivery is delayed or uncertain.
Stripe documents webhook signature verification and duplicate-event handling. The implementation must follow the selected provider’s current documentation; a browser success screen alone should not decide that a ticket is paid.
Make offline limits visible to staff
Specify which ticket data is available on each device, how recently it was refreshed and how local scans are queued. A cancellation made after a device disconnected may be absent from its local copy. Two disconnected gates may each accept the same ticket.
Choose an explicit response: limit offline admission to designated devices or gates, route exceptions to a supervisor, and reconcile conflicts after reconnecting. The right policy depends on the event’s entry risks and operational capacity.
A browser’s online indicator does not prove that the ticket server is reachable. MDN describes navigator.onLine as unreliable for that purpose. Test service reachability and communicate the actual sync state.
Rehearse at the venue’s expected peak
- Use the intended devices and realistic ticket data; include dim screens, damaged codes and manual lookup.
- Agree peak arrival volume, concurrent gates and acceptable queue time before load testing.
- Test provider delays, API timeouts, depleted device batteries and interrupted synchronisation.
- Assign a decision owner for payment disputes, duplicate tickets and manual overrides.
- Record recovery steps, staff instructions and the criteria for stopping or rolling back a release.
Keep a clear acceptance record
For every critical scenario, record the expected outcome, actual result, environment, date and unresolved issues. Acceptance requires the organiser and delivery team to agree the evidence and remaining risks.
The interactive demonstration on our service page explains selected state changes using fictional data. It is not a scanner, a load test or evidence of production reliability. A real deployment needs its own technical and operational testing.
Technical references
These references support the technical explanations. They do not endorse Digittrix or establish a client project’s results.
Worked example: one ticket, two connected gates
Use a fictional paid ticket, DEMO-001, valid for one admission to a test conference. Gate A and Gate B are connected to the same test service. The agreed policy permits one entry and no re-entry. This is a proposed test procedure, not an executed test or a claim about production performance.
Use test accounts and synthetic attendee data. Record the application build, device/browser versions, network setup, operator and time. Run connected and disconnected cases separately: disconnected devices cannot instantly coordinate their admission decisions.
On smaller screens, scroll sideways to compare the columns.
| Step | Expected outcome to agree | Evidence to record |
|---|---|---|
| 1. Validate DEMO-001 at Gate A | Accept one admission and create an attendance record | Ticket state, operator, device and authoritative decision time |
| 2. Validate the same ticket at Gate B | Reject a second admission and show the prior admission | Both attempts and the final attendance count of one |
| 3. Use a fresh, unused test ticket for simultaneous connected scans | Exactly one authoritative admission; the competing request is rejected | Both request IDs, decisions and final stored state |
| 4. Use another fresh test ticket with both devices disconnected | Apply the agreed offline policy; potential conflicting admissions remain visible for reconciliation | Local records, last sync time and any supervisor action |
| 5. Reconnect and reconcile | Identify conflicts without silently deleting either attempt | Reconciliation output, resolution owner and audit history |
Leave Actual result and Evidence blank until the test has been run. A proposed expected outcome is not a pass. If two disconnected gates both admit the ticket, record that conflict and assess the operating policy; do not report duplicate prevention as proven. The worksheet tracks evidence completeness separately from test status. A complete record, including a recorded failure, is not release approval.
Event check-in acceptance worksheet
A reusable test record covering valid entry, duplicates, payment exceptions, offline recovery, permissions and peak arrivals. Includes actual results, evidence, owners and follow-up fields.
- Agree expected outcomes and the test environment before the rehearsal.
- Record actual results, evidence, operator and date for each scenario; leave unrun tests as Not run.
- Resolve failures and obtain the organiser’s release decision separately from this record. Use synthetic IDs and redact attendee information.
Editable Excel file · no email required. Save your own copy before editing. This download does not send your entries to Digittrix.