Android POS Applications for PAX Terminals and Event Ticketing

Summary

We build Android point of sale applications for payment terminals used at live events, including split-the-pot raffle ticketing that sellers carry through a stadium. The application sells tickets at several price levels, takes cash or card, prints a receipt listing the issued numbers, and uploads reconciled sales to a server. Terminals are registered to an event in a back-office portal, sellers sign in on the floor, and an administrator closes out each device when the draw is done.

The Challenge

Ticket numbers are the money, so issuance and reconciliation dominate the design. A seller walking a concourse will lose signal, and a dropped terminal may not come back; both cases need answers rather than assumptions. Duplicate submission of a recovered batch must be impossible, and a device-generated numbering scheme cannot guarantee global uniqueness.

The hardware imposes its own limits: modest processor and memory, a battery that has to survive a full event, a printer with narrow paper and finite throughput, and a screen used with gloves in poor light. Clock drift on devices that stay offline for hours corrupts reconciliation, because timestamps drive it. Charitable gaming is also regulated, and rules on ticket sequencing, record retention, and reporting vary by jurisdiction, so the number scheme cannot be designed before those rules are confirmed. Personal data collected at the point of sale has to be minimised, with retention and deletion defined explicitly.

The Solution

Android on payment hardware

Modern payment terminals are Android devices with locked-down platform services around a secure processor. A vendor SDK exposes the thermal printer, the barcode scanner, the card reader, and device management, while the card path stays inside the secure element and never surfaces raw data to the application. Distribution goes through the vendor terminal store rather than a consumer application store, with signing and terminal grouping handled there.

Payment, communication, and scanning

Card acceptance is layered: a payment SDK abstracts the reader and the transaction state machine, and a processor integration performs authorization, capture, void, and refund. Kotlin with a Retrofit HTTP layer covers server communication, with explicit timeouts and retry policy because venue connectivity is unreliable by nature. Barcode work uses the PDF417 symbology, the same standard encoded on driver licenses under the AAMVA specification, which allows age or eligibility checks and faster entry capture. Parsing that data responsibly means extracting only the fields the workflow requires and discarding the rest immediately.

Offline resilience and integrity

• Sales are written to a local database and mirrored to device storage, so a replacement unit can recover a lost device's records and upload them
• Store-and-forward queues transactions with sequence numbers and idempotency keys, so a resumed upload cannot duplicate ticket sales
• A software integrity screen compares a hash of the installed application against a value supplied by the server, using a modern hash algorithm and pinning the comparison to a signed server response

Server side and back office

The server owns event configuration, price ladders, batch allocation of ticket numbers to terminals, seller accounts with forced password change on first sign-in, and the close-out that returns a terminal to an available pool. Issuing numbers in server-allocated batches lets terminals keep selling offline while guaranteeing global uniqueness. Live standings and prize totals are read from the server rather than computed on the device, so every terminal shows the same figure.

How we build it

We define the ticket number allocation and reconciliation model first, then build against physical terminals early, since printer timing, scanner focus behaviour, and card reader state transitions are not faithfully reproduced in an emulator. Test plans include forced power loss mid-sale, airplane mode during upload, and duplicate submission of a recovered batch.

What This Delivers

Sellers take cash or card anywhere in a venue and keep selling when the signal drops, without any risk of duplicate ticket numbers. Administrators register terminals, allocate number batches, manage seller accounts, and close devices out from one portal, and close-out is a hard boundary producing an auditable set of totals per terminal, per seller, and per event, which is what a regulated cash-handling workflow has to show.

Technologies and Tools

Android on payment terminal hardware, Kotlin, the terminal vendor SDK for printer, scanner, card reader, and device management, a payment SDK and processor integration for authorization, capture, void, and refund, Retrofit for server communication, a local database with store-and-forward sync, PDF417 parsing under the AAMVA specification, and a back-office web portal.