Tap to Pay POS — Selling at the Door

Underneath, the device is a Stripe Terminal reader discovered through the tap-to-pay method, which is the same code path on both iPhone and Android rather than two separate integrations. The payment intent is built on the server with a card-present payment method type and automatic capture, and it carries a deterministic idempotency key, so a tap that gets retried after a timeout cannot become a second charge. Extended and incremental authorisation are both deliberately switched off, since a ticket sale is a single fixed amount taken once.

Sign-in is device-based rather than a personal login being shared around. The app pairs to a device session that belongs to an organization and carries an operator name, and every sale request is checked against the set of events that session is allowed to work. A sale posted for an event outside that set is refused outright. That is what makes it safe to hand a phone to a volunteer for one night: the credential is scoped to the door they are standing at, and revoking the session cuts access without touching anyone's account password.

Once the tap succeeds, the sale is finalised server-side in one call. It creates a single walk-up registrant, labelled as such unless a name is taken, then one ticket row per unit sold carrying the payment intent reference, and a fresh random QR token for each of those tickets that stays valid for 48 hours. A separate receipt token, good for seven days, backs a short link where the buyer opens their own QR codes and can add them to a wallet. The text message is fire-and-forget: if it fails, the sale still stands and the operator shows the code on screen.

The check-in side is what genuinely holds up without signal. Scans are written to a local database on the device, each with its own identifier, and replayed in batches of up to a hundred once the connection returns. The server rules on each one individually and returns a verdict per scan, so a duplicate is caught at sync time rather than at the door. Entries the server rejects are kept with their attempt count and the stated reason instead of vanishing, which is how a disputed entry can be reconstructed afterwards.

That matters at settlement time as much as at the door: money taken from a tap lands through the same connected Stripe account that already receives your online payouts, on the same schedule, rather than sitting in a separate in-person balance you'd have to track down and move over. One fee schedule and one settlement path means the total in your dashboard is the total you actually receive, not something you have to reconcile against a second set of numbers.

Each sale also writes a dedicated door-sale record holding the amount in cents, the itemised list, the operator name, the device session and the payment reference, which is what a till reconciliation at the end of the night is built from. Sold counts are incremented per ticket type through the same database function the online path uses, so remaining inventory on the web page reflects what just went out the door. The tickets themselves hang off the registrant record, the same link every other order lookup and report follows.