> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/usecases-workflows/events-and-venues/ticketing-and-point-of-sale.md). # Ticketing and Point of Sale ## Overview A venue's revenue arrives through the smallest transactions on the network. A ticket scan is a few hundred bytes. A card payment is a few kilobytes. Neither is remotely demanding in isolation. The difficulty is when they happen. Forty thousand people arrive through thirty gates in a forty-five minute window, and every one of them is scanned. Concessions then transact continuously through an interval that lasts fifteen minutes. The load is not sustained traffic; it is a wall of tiny, simultaneous, latency-sensitive sessions that appears and disappears on the event schedule. Public networks fail at exactly that moment, and for a structural reason: **the crowd that generates the revenue is the same crowd saturating the cell.** Forty thousand phones streaming and posting are contending with the terminal trying to authorize a card. Venue Wi-Fi fails the same way, from device density in a confined space. Private 5G removes the contention entirely. The terminals sit on a network that carries nothing but venue traffic, policed by the venue, sized for the peak the venue knows is coming. This workflow ran at the [2025 Australian Grand Prix](https://www.gxc.io/events-connectivity/), where a private network carried transactions alongside operations, security and media contribution for a seven day event. *** ## How It Works
Ticketing and point of sale: 200 to 2,000 terminals and scanners attach to Onyx RUs and an FHM, reaching Onyx Edge where ticket validation resolves locally while payment authorization leaves the site to the acquirer.

The aggregate is under 20 Mbps. The device count per radio constrains the design, along with the attach burst when the gates open.

### What each component does | Component | Role in this workflow | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **Ticket scanner** | Handheld or pedestal reader at the gate. Reads the barcode or NFC pass and needs a real-time answer before the turnstile releases | | **Payment terminal** | Fixed at a till, handheld for roaming vendors, or a phone-based reader. Carries the SIM and holds the PDU session | | **Onyx RU** | The radio. At a venue, placement follows where people queue, which is not where people sit | | **FHM** | Aggregates RUs into one logical cell, so a roaming vendor crossing a concourse never hands over mid-transaction | | **Onyx Edge, 5G Core** | Terminates the session and applies the subscriber group policy that keeps transactions ahead of bulk traffic | | **Local breakout** | Puts transaction traffic on the venue network, and card data on the venue's segmented payment VLAN | | **Payment gateway** | The acquirer connection. Usually the one hop in this chain that leaves the site | | **Ticketing platform** | Validates the pass against the entitlement record and marks it used. Hosted on the edge where duplicate-entry checking has to be immediate | | **Onyx Portal** | Per-terminal connectivity, session counts, and alerts, visible during the event rather than after it | | **Mesh Node** | Wireless backhaul to RUs at temporary gates, car park kiosks and pop-up bars where no cable was ever pulled | ### The transaction path, hop by hop | # | From → To | Interface | What happens | | - | ----------------------------------- | --------------------------- | -------------------------------------------------------------------------------------------- | | 1 | Card or pass → Terminal | NFC, EMV, barcode | The credential is read. Milliseconds, and entirely local | | 2 | Terminal → Onyx RU | **5G NR Uu**, uplink | A few kilobytes on the terminal's subscriber group. Small, but it must be scheduled promptly | | 3 | Onyx RU → FHM → Onyx Edge | eCPRI, aggregated fronthaul | No handover decision. The vendor has not crossed a cell boundary because there is not one | | 4 | Onyx Edge → UPF | internal | The session is terminated and the QoS policy applied | | 5 | UPF → venue network | **N6 local breakout** | Traffic lands on site, card data on the segmented payment VLAN | | 6 | Venue network → gateway or platform | IP | Ticketing validates on the edge. Payment authorization leaves for the acquirer | | 7 | Response → Terminal | the same path back | The turnstile releases, or the receipt prints | ### Where the time goes | Stage | Typical | | ---------------------------------------------- | ------------------ | | Card or barcode read | 50 to 150 ms | | Terminal to Onyx Edge, over the air | 10 to 20 ms | | Ticket validation on the edge | 20 to 50 ms | | Payment authorization to the acquirer and back | **300 to 2000 ms** | | Receipt or gate release | 50 to 100 ms | The acquirer round trip dominates, and you do not control it. You control everything either side of it, and whether the request reaches the acquirer promptly in the first place. On a congested public network the variable is not the acquirer, it is the seconds spent waiting for a scheduling slot before the request ever leaves the terminal. ### The constraint is device count, not bandwidth Add up the busiest ingress a venue will see. Five hundred terminals, a few kilobytes each, and the total is a handful of megabits. Bandwidth is not what limits this deployment. Three other things do. **Connection count.** An Onyx AP supports up to 96 simultaneous UE on LTE and 128 on 5G. Six hundred terminals and scanners across a concourse is a cell-planning problem measured in attached devices, not Mbps. This is the number that decides how many radios you buy. **The signaling burst at ingress.** Every terminal powers on and attaches inside the same short window. Attach, authentication and session establishment are control-plane work, and they arrive together. A network sized comfortably for steady-state traffic can still struggle at the moment the gates open. **Latency turning into queue length.** A payment that takes eight seconds instead of two does not fail. It adds six seconds to every transaction at that till. Across thirty gates and an arriving crowd, that becomes a physical queue out of the door and concession revenue that never gets spent. Latency is the mechanism; the symptom is people standing still. *** ## Network Requirements | | | | ---------------------------------------------- | -------------------------------------------------------------- | | Per-transaction payload | 0.5 to 5 KB | | Per-terminal sustained rate | < 50 kbps | | Aggregate at peak | typically **under 20 Mbps**, even for a large venue | | **Concurrent devices** | **200 to 2,000 terminals, scanners and handhelds** | | Transaction round trip, excluding the acquirer | < 100 ms | | Jitter | < 50 ms | | Residual loss | 10-6, a retried payment is a reconciliation problem | | Availability | **99.99% within the event window** | | Transaction QoS | **5QI 70**, non-GBR, mission-critical data, 200 ms PDB | | Reconciliation and updates QoS | **5QI 8 or 9**, non-GBR, scheduled outside the event | {% hint style="info" %} **Read the concurrent-device row, not the bandwidth row.** It is the line that drives the radio count. {% endhint %} *** ## Deploying It {% stepper %} {% step %} ### Survey to the queues, not to the seats Coverage has to be strongest where people stop moving: gate lines, concession counters, merchandise stands, car park kiosks. Those are usually at the perimeter and under structures, not in the bowl where the RF plan naturally concentrates. {% endstep %} {% step %} ### Count terminals per coverage area For every gate cluster and concourse, count every device that will attach: scanners, tills, handheld readers, vendor phones. Compare against the per-AP device limit. This count, not the throughput, sets the radio count. {% endstep %} {% step %} ### Separate the traffic classes Put transactions in their own subscriber group on 5QI 70. Put firmware updates, reporting and reconciliation on 5QI 8 or 9 and schedule them outside the event window. Without this, a terminal fleet pulling an update at the wrong moment competes with live payments. {% endstep %} {% step %} ### Segment the card data Card traffic breaks out locally onto the venue's payment VLAN, segmented from everything else at the Onyx Edge. Bring your PCI assessor into the design rather than the audit. {% endstep %} {% step %} ### Rehearse the ingress burst Test the moment the gates open, not steady state. Power on the full terminal fleet together and confirm every device attaches and transacts. This is the test that finds control-plane limits, and it is the one most often skipped. {% endstep %} {% step %} ### Watch it during the event Terminal connectivity and session counts in Onyx Portal, visible to the operations room while the event is running. A till that has silently dropped off the network is a queue forming before anyone reports it. {% endstep %} {% step %} ### Reconcile and tear down Reconcile transactions, then release the temporary gates and kiosks. At a seasonal venue the network is a reusable asset, not a sunk cost. {% endstep %} {% endstepper %} *** ## Devices and Ecosystem * **5G payment terminals**: fixed tills and handheld readers with an eSIM, from the usual payment hardware vendors. * [**Ticket scanners**](https://docs.gxc.io/devices/gxc-compatible-devices/mobile-computer-scanner): handheld and pedestal readers, barcode and NFC. * [**Vendor phones**](https://docs.gxc.io/devices/gxc-compatible-devices/smart-phones) **and** [**tablets**](https://docs.gxc.io/devices/gxc-compatible-devices/tablets-and-laptops): roaming sellers in the stands and the concourse. * [**5G CPE**](https://docs.gxc.io/devices/gxc-compatible-devices/mobile-cellular-routers) **at fixed points**: backhauling a cluster of wired tills behind one router where the tills themselves are not cellular. * **Ticketing platform**: hosted on Onyx Edge so validation and duplicate-entry checks resolve locally. * **Payment gateway connection**: the acquirer link, usually the only hop that leaves site. * **Mesh Nodes**: for temporary gates, overflow car parks and pop-up bars. *** ## Design Considerations **Ticketing and payment fail differently, and the design has to respect that.** A payment terminal can store a transaction and forward it when the link returns. A ticket scanner cannot: validating a pass offline means accepting the risk of the same pass being used twice at another gate. Ticketing needs live validation, so it is the workflow that sets the availability requirement. **Size for ingress, not for the average.** The busiest forty-five minutes of the day carry almost all of the attach load and much of the transaction load. A network sized on average event traffic will be comfortable for ninety percent of the event and fail during the part that matters. **SIM credentials are a real security improvement over shared Wi-Fi.** Hundreds of terminals on a shared passphrase is a credential that cannot be rotated in practice and cannot be revoked per device. SIM-based authentication gives each terminal its own credential, revocable centrally the moment a device goes missing. Combined with IMEI binding, a stolen SIM in an unauthorized terminal does not attach at all. **The acquirer link is the single point of failure you do not own.** Everything else in this chain can be made resilient on site. Plan the fallback for when that link degrades, and confirm what your terminals do when authorization times out. **Temporary venues justify the deployment on their own.** A circuit or a festival ground used twenty days a year cannot economically cable every gate. Mesh backhaul to temporary positions is what makes those positions viable at all. *** ## Validation Checklist * [ ] Coverage confirmed at gate lines, counters and kiosks, not just in the bowl * [ ] Device count per coverage area measured against the per-AP limit * [ ] Full-fleet attach test from cold, simulating the gates opening * [ ] Transaction round trip measured under that peak, not at rest * [ ] Transactions and bulk traffic on separate subscriber groups and QoS classes * [ ] Card traffic segmented onto the payment VLAN, reviewed by the PCI assessor * [ ] Ticket validation confirmed to resolve on the edge * [ ] Duplicate-entry rejection verified across two different gates * [ ] Terminal behavior confirmed when acquirer authorization times out * [ ] Portal alerting routed to the operations room for the event duration * [ ] Roaming vendor tested across the full concourse with no session loss *** ## Next steps * **Size it.** Take these requirements through [Plan Your Network](https://docs.gxc.io/plan-your-network): capacity, coverage, architecture, and a preliminary bill of materials. * **Compare it.** [Network Requirements at a Glance](https://docs.gxc.io/usecases-workflows/network-requirements-at-a-glance) puts every workflow side by side, for sites carrying more than one. * **Talk to us.** For a validated design and a quote, [contact GXC](https://gxc.io/contact-us/). ## Related reading * [Live Video Production](/usecases-workflows/events-and-venues/live-video-production.md) : media contribution over the same venue network * [Network Requirements at a Glance](/usecases-workflows/network-requirements-at-a-glance.md) : all workflows side by side ## Contact GXC To get in touch with GXC, please visit . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.gxc.io/usecases-workflows/events-and-venues/ticketing-and-point-of-sale.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.