A handheld can decode a paper ticket or a QR code shown on a phone, but entry is a business decision made by the event application. The purchasing question is therefore not only whether the code can be read. It is whether the selected device, check-in application and operating plan can return the correct admission result at the right entrance, including when the network is unavailable.
This guide follows one editorial event scenario from code capture to admission status. It complements Scanning Barcodes from Phone Screens, which addresses the optical capture path, and Offline Barcode Capture, which addresses uncertain transaction outcomes. It does not claim compatibility between AIDC GO hardware and a named ticketing platform.
Separate a readable code from permission to enter
A successful decode produces a value. The event application still has to identify the event and check-in list, find the ticket, apply entrance and time rules, and record the result. A green scan result should therefore mean that the application accepted the ticket under the active rules, not merely that the scanner produced characters.
The pretixSCAN Android documentation provides one bounded software example. It describes a valid ticket allowed by the current check-in rules as green, an already-used ticket as yellow, and invalid, canceled or disallowed tickets as red. Those states belong to that named application and configuration; they are not functions promised by a generic scanner.
For procurement, retain the captured value, selected event, check-in list, entrance identity, device time and returned business status for the same attempt. This evidence helps distinguish an unreadable ticket from a readable ticket that the application correctly refuses.
Define the entrance rules before selecting the device
Consider an editorial conference with a morning workshop, a main event and two entrances. A paper ticket and its phone-screen copy encode the same ticket identifier. The workshop entrance should admit only workshop participants, while the main entrance accepts the broader event list. Re-entry is permitted only after an exit has been recorded.
The device must present the code to the correct application context. A perfectly readable main-event ticket at the workshop entrance should receive a rule-based refusal. An already-used ticket should not be treated as a scanning failure. A canceled ticket should remain refused even if its printed symbol is sharp and easy to decode.
Write these cases as expected application results before testing. Include a valid ticket for each entrance, a valid ticket for the wrong session, an already-used ticket, a canceled ticket and a re-entry case. Use fictional or controlled test identities rather than live attendee data.
Treat offline entry as a data-distribution design
Offline mode changes where validation occurs. The pretixSCAN documentation says its offline mode checks an internal device database and periodically attempts synchronization. It also warns that, with more than one offline device, the same ticket can potentially be admitted more than once until the relevant devices synchronize successfully.
That warning reveals the purchasing boundary: the scanner does not independently prevent duplicate entry. Each offline handheld can only decide from the rules and ticket state it currently holds. The project must define how data is downloaded, how current it must be before doors open, what operators do after a long disconnection and how conflicts are reviewed after synchronization.
Use Device Deployment Readiness for broader preparation such as charging and device assignment. For ticket control, keep the evidence focused on the selected event data, last successful synchronization, scan decision and later server acknowledgement.
Follow one ticket through the exception branches
In the editorial conference, ticket EVT-1047 is downloaded to devices A and B before entry opens. Device A scans it online at Entrance East and receives an accepted result. Later, both devices lose connectivity. The attendee presents the same ticket to device B, whose local data has not received device A's check-in. Device B may accept it under its stale local state.
The useful response is not to claim that a different imager eliminates the duplicate. Record the two device identities, their last synchronization times, the ticket identifier and both decisions. When connectivity returns, confirm whether the platform reports or reconciles the conflicting state, and apply the event owner's approved exception process.
For re-entry, record an exit before expecting a second entry to pass. The pretixSCAN documentation makes re-entry dependent on the check-in-list setting and an exit scan. That is a software-rule example, not a universal ticket behavior.
Compare evidence for each check-in outcome
| Check-in stage | Evidence to retain | What it does not establish alone |
|---|---|---|
| Code capture | Ticket medium, captured value and device feedback | It does not establish that the ticket belongs to the active event or entrance. |
| Rule context | Event, session, entrance, list and rule revision | It does not establish that the device holds current ticket state. |
| Admission decision | Accepted, already used, canceled, wrong event or another explicit result | It does not establish that the server has received the decision. |
| Offline state | Data-download time, last sync, device identity and connectivity state | It does not establish that another offline device has not accepted the same ticket. |
| Re-entry record | Prior entry, exit status and re-entry rule | It does not establish that every entrance has synchronized the updated state. |
A complete test connects all five rows. A scanner demonstration that shows only decoded text does not test admission rules, and an application screenshot without device and synchronization context does not explain how the result was reached.
Test paper, phone screens and application feedback together
Use representative paper tickets and phone-screen tickets with the proposed configuration. Record screen brightness and presentation conditions where they matter, but do not convert a single successful scan into a universal readability promise. The article on phone-screen barcode capture provides a focused optical evaluation path.
Then test the same controlled ticket states through the customer-approved application: permitted entry, wrong session, already used, canceled and re-entry. Confirm that the operator can distinguish each result without relying only on color. Check what happens if the code is read twice, the operator changes entrance, the app is backgrounded, or the network changes during submission.
If the project uses keyboard, Intent or SDK input, document the exact path separately. Barcode Scanner Integration Methods explains why a decoded value arriving at the host is not yet proof that the target ticket application processed it.
Bring the full check-in path to the purchase discussion
Provide the ticket media, symbologies, phone-screen examples, event and entrance rules, expected exception states, offline policy, device count, application and OS versions, network conditions, operator feedback needs and evidence-retention requirements. Identify whether check-out and re-entry are in scope.
Ask the application provider for its supported capture methods, offline data behavior, synchronization semantics, conflict handling, device authorization and audit outputs for the exact release being evaluated. Ask AIDC GO for the relevant handheld configuration and versioned integration materials without assuming that a particular ticketing application is supported.
Use Rugged Handheld Terminals to compare the published hardware directions, then Integration & Support and Contact AIDC GO to present the project context. The approval decision should connect a readable ticket to the right application rule, recorded outcome and synchronization state.