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.

Offline check-ins are recorded with the device's time and entrance; if two offline devices let the same ticket in, the first to sync stands and the other is shown to you as a duplicate entry rather than dropped. Card payments stored on a Stripe reader with no signal are the organizer's risk if the bank declines them later, which is why that part is being reviewed before it is switched on.

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.

The laptop box office is a second front end on the app's door sale: it prices the cart with the same quote, writes the order through the same door-sale path, and settles card money on your connected Stripe account exactly as the app's pay-by-QR does. While the guest pays, their tickets are held so nobody online can take them; an unpaid payment releases the hold when it expires or is cancelled. A browser can only drive internet-connected smart readers, so a Bluetooth or USB reader has to be paired with the BrightStar Organizer app instead. Refunds stay where they always were, on the order page, for the organizer and managers.