Pair the kiosk once. Ring sales forever.
A 6-character code, a 10-minute window, and your counter is live for the next 90 days. No email logins on the kiosk. No re-auth at shift change. No session-expired toast mid-rush.
Live on production today across pos.botline.cc and pos.botline.pk.
A kiosk that logs the cashier out at 5pm is a kiosk you do not own.
Most POS software was built for a person sitting at a desk — log in, work for an hour, log out. A counter is the opposite. It opens once, stays open, and outlives shift change, deploys, internet drops, and the owner closing their laptop.
So we rebuilt the auth layer underneath the kiosk from the ground up. The cashier on the floor sees one thing forever: the sell screen.
Here are the four screens you and your cashier will actually see — start to finish, under two minutes.
Four screens. Once. Forever.
This is everything that happens the first time you connect a new till. After this, the cashier on this device never sees a login screen again.
Open the pair flow
Owner opens Store Settings → POS Devices and clicks Pair a POS kiosk. They type a label like Counter 1 and hit generate.
Show the cashier the code
A 6-character code appears on the owner screen. It is good for 10 minutes and works exactly once — if someone else types it first, it is dead.
Cashier types the six characters
The cashier opens pos.botline.cc/<shop>/pair on the kiosk tablet and types the six characters. No email, no password, no manager account.
Ready to ring sales
The kiosk loads the sell screen and stays there. A signed device cookie now lives on the tablet for 90 days, rolling forward every time it is used.
Five layers between the cashier and the database.
Skip this section if you are an owner — nothing here changes how the till feels at the counter. This is for the person on your team who wants the wiring. Each layer catches a different kind of fall; together, they cover every outage we have seen on production this year.
Service Worker shell cache
Holds the kiosk HTML, CSS, and JS bundle on the device with stale-while-revalidate. A bad deploy cannot blank the screen.
IndexedDB sales queue
Every sale gets a ULID before the network call. If the request fails, the queue retries with the same key. The server deduplicates on the ULID — replays are no-ops.
Paired-device cookie
A 90-day rolling cookie scoped to pos.botline.cc, signed with a secret separate from the user JWT. It cannot be substituted for an owner session.
Kiosk session (24h + 15-min silent refresh + 5-min grace)
The kiosk JWT lives a full retail day, rotates in the background, and a server-side grace window catches the seconds-after-expiry edge.
Dedicated POS service
POS routes run as their own service with their own deploy lane. Dashboard, tenant, billing, marketing — none of them touch it.
You handed out the device. You can take it back.
Every paired kiosk shows up at /dashboard/store/settings/pos-devices with its label, where it last checked in, and a revoke button. Hit revoke and the next sale that device tries to ring will bounce back to the pair screen.
- Label every till on pair — Counter 1, Counter 2, Drive-through, Back room — so you know what you are killing.
- Last-seen timestamp updates on every request so a forgotten tablet is obvious.
- Revoke is instant — no waiting for a session to expire. The device cookie is invalidated server-side.
- Cashiers identify with their PIN on a paired device, so the audit trail shows the right person on every sale even after a shift change.
The till and the back office walk in through different doors.
The kiosk lives at pos.botline.cc (and pos.botline.pk for Pakistani shops). The owner dashboard lives at botline.cc. They share nothing — not a session, not a cookie, not a token.
- The kiosk device cookie is scoped to the kiosk subdomain only. It cannot be read by the dashboard, and the dashboard's session cannot be read by the kiosk.
- The kiosk and the owner dashboard sign their sessions with different secrets. A stolen owner session cannot impersonate a till, and a stolen till cookie cannot open the owner dashboard. Substitution is not a check we have to remember to run — it is impossible by construction.
- There is no email-login UI on pos.botline.cc or pos.botline.pk at all. The only way onto a kiosk is the 6-character code the owner generated, with a 10-minute window.
- Before the fix, any browser could extend its session to 24 hours just by claiming to be a kiosk. After the fix, the kiosk badge is stamped onto the session signature at login time and verified on every refresh — the claim has to be signed by us, the request body can't override it.
And it stays up even if…
Pairing once would not matter if the kiosk fell over when the WiFi blinked or we shipped an update. So we built four ways the till keeps ringing — three things that keep the kiosk standing, and the pair-once flow above them that means the cashier never sees a login.
…we ship a dashboard update at 2pm.
The kiosk holds its own copy of the sell screen on the tablet. While our servers restart, the cashier keeps ringing — the screen does not blank, the cart does not clear.
…the shop internet drops mid-shift.
Sales queue locally on the tablet during the outage. When the link comes back, they post in order, and the same sale never lands twice — even if the cashier hit charge again during the freeze.
…we deploy something else, or restart the shop service.
The till runs on its own service with its own deploy lane. A dashboard release, a tenant restart, a billing rollout — none of them touch the till’s process. It just keeps serving.
…and it never makes the cashier log in.
Once a tablet is paired, the cashier sees the sell screen forever. Sessions roll over silently in the background, and a 90-day device cookie keeps the till open through nights, weekends, and shift changes.
All four are live on production today. Each one is monitored, and each one is recoverable without a phone call to support.
What the three waves actually changed.
Five numbers and one URL pattern, before and after. No interpretation — read the rows.
From 9am open to 9pm close, no logins, no toasts, no calls to support.
The same kiosk, paired once last Tuesday, runs the whole day. Here is where each part of the system shows up.
The four questions every owner asks first.
Hit revoke on /dashboard/store/settings/pos-devices. The cookie is dead on the next request. Pair a fresh code in the morning.
Open the Paired kiosks list and revoke that device. The revocation check runs server-side on the very next request, so even if someone copied the cookie into a different browser, that browser gets bounced to the pair screen and cannot ring a sale.
No. The kiosk lives on pos.botline.cc (and pos.botline.pk for Pakistani shops) — neither has a dashboard UI at all. The device cookie is scoped to the kiosk subdomain and cannot read the main dashboard at botline.cc.
It is one-shot and lasts 10 minutes. Whoever types it first wins, and you will see them appear in the Paired kiosks list with a fresh last-seen timestamp. Revoke and re-pair.
Something else on your mind? Talk to us
Pair one tablet. Watch a shift run.
We will set up a pilot tenant for your shop, paired to a tablet you already own. You ring through Friday rush. We watch the logs. Nobody calls support.
All live on production today — pos.botline.cc & pos.botline.pk.