Imagine a guest leaving a bag at the counter. They scan at the entrance, notice the bag and turn back without passing. A second scan brings up ‘already used’. Who can correct the record, and what proves whether the first entry happened?
Questions like this should be settled before buying ticketing turnstile access control integration. Agree on the events that validate a ticket, consume its entitlement and confirm passage. Then define how exits, repeat visits and operator corrections affect that record.
At ไทเกอร์วอง, our pedestrian access work includes QR-code and card-based entrance arrangements. For a new project, we need the venue’s admission rules and the ticketing provider’s interface details. Reading the code does not settle whether its owner can enter.
What does a successful ticket scan actually authorize?
Take a sample from each ticket type on sale. The QR symbols may look alike, but a timed session and a multi-visit pass spend different entitlements. A group booking introduces another question: how many people does one scan allow? The reader quotation should follow those decisions.
For each type, identify the event or area, permitted visit time, remaining entitlement and cancellation status. Ask the ticketing provider which system checks those conditions and which response the gate controller receives. “Valid code” is too broad to serve as the acceptance rule.
Bring printed samples and phone tickets to the demonstration if the venue accepts both. Watch the identifier received by the application as well as the reader’s indicator. A successful read with an incorrectly interpreted identifier will still leave a guest at the entrance.
Ticket contents also need an owner. A readable code does not tell the gate whether a booking was refunded a moment earlier. Agree how cancellations and other changes become visible at the entrance, including the behaviour when that update cannot be obtained.
Staff credentials should have their own permission rules. A staff card opening the lane must not reduce a visitor’s ticket balance or appear as a paid admission. The same distinction applies to service access and supervised group entry.
Keep the approved rule sheet with the demonstrated software version and reader/controller configuration. It gives the next installer something definite to check when a sales channel or ticket format changes.
When should a ticket be marked as used?
The key purchasing question is when the admission becomes spent. Possible designs may use authorization, an opening command or confirmed passage, but those events are not interchangeable. Ask the suppliers to explain their proposed choice and its consequences for a guest who does not walk through.
For a proposed TGW-TT001 tripod turnstile installation, identify what passage information is available from the supplied configuration. Confirm how the ticketing application receives and uses it. Do not infer that every rotation, refusal or timeout is automatically reported.
A useful demonstration starts with one valid ticket and no passage. Scan it, wait without entering, and try again after the lane’s permitted passage interval ends. Compare the screen message, remaining entitlement and recorded events with the venue’s agreed rule.
Use a second reader for the next trial. Present copies of the same ticket at neighbouring lanes at nearly the same time, with the supplier observing both requests. Which request reserves the admission? What does the other reader show while that decision is pending?
Test a lost response as well. Approval can be stored at the ticketing service while its reply fails to reach the lane. Now the guest scans again. The suppliers need to show how that second request is related to the first, including the remaining balance on a multi-visit pass.
An event identifier can make this much easier to trace if the proposed system provides one. Otherwise agree on another practical method for tracing the ticket, lane and decision across the suppliers’ records during acceptance.
How will exit records allow or prevent re-entry?
A guest asking ‘Can I come back after lunch?’ needs a clear answer. For procurement, that answer becomes a re-entry rule: whether leaving ends admission, any limit on returning and the credential needed at the next scan.
A return rule that depends on recorded exit needs a dependable source for that record. A free-exit opening, a supervised side gate and a scanned exit may produce different evidence. The ticketing design must account for the actual exit routes people will use.
When considering a TGW-WT001 flap gate, confirm the proposed direction settings and the events available to the ticketing system. Entry and exit rules should be demonstrated with that configuration, including any staffed alternative route.
A group ticket needs particular attention. Suppose part of a group arrives late while one of the earlier visitors has already left. Walk that sequence through with the operator. It exposes whether the proposed ticket represents a single group movement or separate admissions. Avoid using a single group scan to imply that an unverified number of people passed.
Also separate occupancy reporting from sales reporting. A report of paid tickets can include people who never arrived. Approved scans can include abandoned entries. Label these totals clearly, and have the operator explain which one they will use for each operational purpose.
Who resolves rejected tickets without blocking the queue?
‘Cannot read’ and ‘already admitted’ send staff down different paths. In one case they may need a clearer ticket; in the other they need the earlier entry record. A wrong date or cancelled booking belongs with the booking desk. Decide these routes while approving the screen messages.
Place assistance where staff can examine the problem without holding the guest inside the lane. The operator should be able to identify the relevant booking and entry attempt through the agreed support process, without making an unnecessary copy of the complete ticket code.
Use roles to control corrections. Restoring an unused admission may require a supervisor, while redirecting a guest may be a normal attendant task. The venue should name those roles and decide which corrections require a recorded reason.
Keep the first attempt when correcting the balance. Add the operator, time and reason as a separate action. If the guest later disputes what happened, the supervisor can examine both the original decision and its correction.
For a network outage, select a documented operating mode with the ticketing provider. If any local validation is proposed, ask what information it has, how current it is and how duplicate use is handled when lanes cannot share decisions.
Recovery needs a procedure too. After the connection returns, compare the local events with the central ticket balance. Who handles a conflict? The recovery trial is unfinished until the operator can answer that question and locate the records needing attention.
Which ticket journeys should the suppliers demonstrate together?
Arrange an acceptance session around guest journeys rather than isolated device features. Invite the person who will deal with disputed admissions to use the operator screen during the session. Give them the proposed instructions and see whether they can find the relevant attempt.
| Guest journey | Outcome to agree | Record to examine |
| Valid ticket and completed entry | One permitted admission | Ticket decision and passage event |
| Approval followed by no passage | Agreed retry or correction path | Timeout and entitlement balance |
| Same ticket at adjacent lanes | No unauthorized extra admission | Both requests and final balance |
| Exit followed by return | Venue re-entry policy applied | Exit evidence and new decision |
| Refunded ticket presented | Current cancellation rule applied | Booking status and refusal reason |
| Connection loss and recovery | Agreed operation and reconciliation | Local events and conflict report |
A refused guest also needs somewhere to go. Check the display from their position and follow its instruction to the assistance point. Staff there should know which issues they can resolve and which need a supervisor.
The handover pack needs the signed ticket rules and trial records, with a named contact for each interface. Assign responsibility for changes to ticket formats, sales channels and gate software. A later upgrade should repeat the journeys it could affect.
Send your ticket types, sample code formats, entry and exit layout, existing platform details and re-entry policy for a ticketing integration review. We can discuss the pedestrian gate and reader arrangement while the ticketing provider confirms the entitlement logic and required interface work.