Offline POS system · verified cash continuity
When a prepared register loses its connection, LiftedPOS keeps cash continuity available: take an explicit cash tender, hold the transaction visibly in that browser, and let the server validate it after the connection returns.
CASH CONTINUITY · VISIBLE LOCAL QUEUE · SERVER-VALIDATED SYNC
Connection-state rail
The trace stays amber while the sale exists only in the browser. Green appears only on the branch where the server accepts replay. An unsuccessful replay stays pending for operator follow-up.
Catalog loaded, browser prepared, and the selected register has a current open session.
Explicit cash tender carries the continuity workflow until the connection returns.
The browser retains a visible replay record; server completion follows successful synchronization.
Automatic sync or Sync Now sends the record through current server checks.
Accepted by the server. Inventory, reporting, and the receipt can now follow the booked sale.
The replay remains queued for operator review and a later retry.
OPERATING WORKFLOW · VERIFIED AGAINST PRODUCT BEHAVIOR
Prepare while online
LiftedPOS can queue a completed cash sale only when the browser has a cached app shell and catalog from a prior online visit and browser storage remains available.
The capture shows the prerequisite rather than a simulated success state. Staff can see the product catalog, the selected location, and the open Main Register action. Those details matter because cached software without the right catalog or an active drawer does not create a complete operating path.
A merchant should load the exact workstation and browser that will be used at the counter, sign into the correct company, choose the real location and register, open the drawer using the store's normal procedure, and confirm the catalog appears before beginning an outage drill.
State matrix
Online, offline, and reconnected are not interchangeable modes. The final column describes what happens after replay reaches the server, including the possibility of a pending or rejected result.
| Behavior | Online + ready | Offline | Reconnected |
|---|---|---|---|
| Cash | Normal cash checkout against the open register. | Explicit cash tender can be queued locally. | Booked only if server replay is accepted. |
| Card | Configured online card workflow is available. | Card workflows pause with the connection. | Card work resumes online; queued continuity sales retain their cash tender. |
| Receipt | Follows a completed online transaction. | Pending; local queueing is not a receipt promise. | Available after the server accepts sync. |
| Inventory | Updates with server-booked sales. | No cross-system or cross-terminal update is promised. | Updates only after accepted replay. |
| Reporting | Uses server transaction records. | Remote reporting is not an offline workflow. | Reflects accepted replay, not the earlier browser queue event. |
| Drawer | Cash is attributed to the selected open session. | A current open register session is still required. | Server reloads the current open session before booking. |
| Pricing | Current server catalog and calculation apply. | A queued client price is not locked or authoritative. | Server reloads current product and modifier pricing, then recalculates. |
| Customer | Normal configured customer and loyalty workflows are available. | An existing association may travel with the queue; search and redemption are not promised. | Association is validated with the replay; no success is assumed. |
What works offline
Staff can work from the already available catalog, ring line quantities and supported modifiers, retain an existing customer association when present, apply supported discounts with the required permission, record tip and age-verification attestation when applicable, accept explicit cash, and place the result into the browser's pending queue.
What waits for a connection
Cards and other non-cash tenders, a completed receipt, authoritative inventory, reporting, remote visibility, customer search, loyalty redemption, online ordering, appointments, purchasing, and administration wait for the appropriate online and server path. Queued does not mean posted.
Outage walkthrough
Use a controlled drill with seeded demo data before relying on the workflow in a live store. The goal is to show exactly when the register is prepared, what the browser can hold, and how the operator recognizes a replay that remains pending.
Open the correct company, location, and register in the intended browser. Browse products and categories so staff can confirm the catalog and app shell are present.
Verify the selected register has an open session with the store's known opening cash. Do not treat a previously closed or different register as an acceptable substitute.
Observe the offline banner and pending count. Confirm that non-cash tender choices are not presented as available.
Use a product whose continued availability, price, tax, permissions, and age procedure can be checked after reconnect. Take explicit cash only.
The browser has retained a replay candidate. Tell the customer and cashier that the receipt is pending and the server has not accepted the transaction yet.
Allow automatic synchronization or use Sync Now. Watch the pending count, syncing progress, successful completion, or sync error rather than assuming network return equals success.
Only after acceptance should staff look for the booked transaction, receipt, inventory movement, drawer attribution, and reporting result.
Offline operating envelope
Offline continuity uses a previously loaded register, an open drawer, a preloaded catalog, explicit cash tender, local queue visibility, and later server validation. Replay uses the current server catalog and calculation before inventory, reporting, receipts, and drawer consequences are booked.
While offline, tender is cash only; cards, debit, rewards wallet, and split tender wait for a connection. A local queue is not a completed sale; the sale is complete only after the server accepts replay. The receipt remains pending until server acceptance.
The browser exposes pending, syncing, failed, and completed states. Staff keep the workstation available, protect its browser storage, explain the pending receipt, and assign one owner to any replay that remains in the queue.
The server ignores the queued client price, reloads the current server catalog, and recalculates pricing, discounts, and tax. Referenced products, modifiers, permissions, tax, age-verification attestation, customer context, tip, and explicit cash still enter current validation.
Replay requires a current open register session at the selected location; without one, the sale remains unsynchronized. That keeps accepted cash attached to an actual drawer instead of assigning it to a convenient register after the fact.
A client transaction identity gives the server duplicate replay protection. Automatic sync and Sync Now can retry the same pending identity without intentionally creating a fresh sale for every attempt, while every retry still faces current product, permission, pricing, tax, location, and drawer checks.
After reconnect, Sync Now retries pending sales; accepted replays clear from the queue, while unsuccessful replays remain pending. The product leaves unsuccessful replays pending; its online banner shows the remaining count as pending sync, and on a sync error says “Sync failed for some transactions (N remaining).” Inventory and reporting update only after the server accepts the replay.
After acceptance, compare the booked transaction with cash collected, drawer movement, receipt, inventory, and reporting. The server receipt becomes available after synchronization.
Use the intended browser, storage policy, network, register, peripherals, and employee roles. Test a clean replay, a simultaneous automatic/manual retry, and a controlled validation problem with seeded data. Document who communicates with the customer and who owns an unresolved queue.
Connect the procedure to cash drawer management, inventory, reporting, and permissions. Then qualify the store context for retail, convenience, smoke shops, vape shops, liquor stores, restaurants, bars, or cafes.
Offline POS questions
The documented offline path accepts explicit cash. Card and other connected tender flows resume through the configured payment path when connectivity returns.
No. The local browser queue is pending work. The server must accept replay before the sale is complete and before inventory, reporting, and the receipt follow the booked result.
No. Reconnect starts automatic or manual retry. Current products, modifiers, prices, tax, permissions, location, and open-drawer state can leave an unsuccessful replay pending for another attempt.
No promise is made. The app shell and catalog must already be available in that browser, and browser storage, cache, service-worker, and device behavior vary.
Run it with safe demo data, then map the locations, roles, devices, and configuration your operation needs.