When the register goes offline — what survives, what doesn’t

Most retail POS vendors built around card-present transactions. When the internet drops, the card terminal can’t auth — the sale can’t happen — the register stops being useful. That model leaks straight into how cannabis POS is built, even though the cannabis register doesn’t need card auth at all (cash-only by design in WA + OR + MI). The register is doing inventory decrement + tax math + receipt print + audit log + traceability sync. Three of those five can run on the local register without ever touching the cloud.

The register is local-first. Local means the register keeps its own copy of what it needs and writes there first, then syncs. Concretely:

• Inventory lookup. The product catalog (every SKU + price + tax category + on-hand qty) is mirrored locally on every register. Lookup is instant; no network round-trip.
• Cart build. Add product → cart updates. Apply discount (loyalty / heroes / first-visit) → math runs locally against rules cached at start-of-shift. The cart never waits on the cloud.
• Tax math. State-by-state rates baked in (WA 37% / OR 17%-20% / MI 10%) — not pulled per-transaction.
• ID scan + age verification. Local scanner + local rule (21+ recreational / patient lookup against locally cached endorsement list). Sale-to-minor block enforced offline.
• Receipt print. Receipt printer is USB to the register, not networked. Prints regardless of upstream link.
• Cash drawer open. Drawer trigger is wired to the register, not to the cloud. Open / close / balance happen locally.
• The transaction record is written on the register itself. Nothing is lost.

Honest list. These all wait for the link to come back.

• WSLCB-CCRS / METRC traceability submit. WAC 314-55-083(4) requires the information be “kept completely up-to-date” and sets no interval — no real-time rule, no stated deadline. Transactions queue locally; they push to CCRS / METRC the moment the link returns. The state doesn’t know whether the row arrived in 2 seconds or 47 minutes — the receive timestamp is what matters, not whether it crossed the wire instantly. (End-of-day reconciliation is the practical bar we hold ourselves to, and the 2026 CCRS technical guide is the place to check the transport contract.)
• Cross-store inventory transfer. Same-licensee inventory transfer to a sibling store needs both sides online for the manifest to commit. If one side is offline, the transfer queues; the manifest commits when both are reachable.
• Loyalty point accrual via cloud rules engine. If the loyalty rules are cloud-side only, the customer earns the points retroactively when the link returns. Better: rules-cache locally so the receipt shows the point earn in real-time. (CannAgent caches; many vendors don’t.)
• Online order claim. Customer ordered ahead via the public site? The pickup pre-reservation lives in the cloud. Offline registers can still complete a walk-in cash sale of the same product, but the ‘mark online order picked up’ sync waits.
• Vendor portal sibling-store hop. A vendor logging in to look at the other store from this register’s screen is a cross-store auth flow — needs the cloud.
• Real-time dashboard for the owner phone. The owner’s phone dashboard shows whatever the cloud knew at last sync. Lag is the price.

The order matters. Sync isn’t one batch — it’s a priority queue.

1. 1Audit-log rows first. Compliance writes are the highest-priority sync target. The state doesn’t care about the timing within reason; it cares that the row exists.
2. 2Inventory decrement reconciliation. If two registers were offline simultaneously and both sold the last unit of a SKU, the sync detects + flags the conflict for the inventory team to resolve manually. Better than silently double-selling.
3. 3Cash-drawer close + variance. The till count for the offline window flows up the moment the link returns. A variance over your threshold gets the standard review.
4. 4Loyalty point accruals. Customer’s account updates retroactively. Customer-facing communication: ‘Your points from earlier today have posted’ — never ‘our system was down.’
5. 5Online-order pickup status. Last to sync. The customer who walked in for an online order while the link was down already left with the product; the marker just catches up.

Tone matters. The customer doesn’t need to hear ‘our system is down.’ They need to hear that the sale is going through.

• Right: ‘Cash sale, easy — register handles this locally.’ (For the cash-only customer, internet is irrelevant. Don’t make them anxious about something that doesn’t affect their purchase.)
• Right (loyalty member): ‘Points will post in a few minutes — receipt shows what you earned.’ (Honest + reassuring; the receipt math is local + trustworthy.)
• Right (online order): ‘Your online order is in our local system. We can hand it to you now; the “picked up” flag updates when our connection comes back.’ (Honest about the queue without making it the customer’s problem.)
• Wrong: ‘Our system is down — I’m not sure if I can ring you up.’ (Telegraphs panic; loses the sale.)
• Wrong: ‘Sorry, can’t do anything until our internet comes back.’ (False — the register can almost certainly do this transaction.)

• Cloud-only POS that locks the register on a network blip. (Several vendors still ship this; ask before signing.)
• Manual paper-tracking of offline sales. (Some shops keep a notebook for outages — recipe for variance + audit trouble.)
• ‘Sorry, our system is down’ sign on the door. (Walks customers to a competitor.)
• Owner phone calls to the IT vendor mid-outage. (The register architecture should make this irrelevant.)