Canonical checkout workflow
One implementation of the sale — line items, discounts, loyalty, tax, tender, change, and receipt — shared by the web register and the iPad shell. Fixing a bug fixes it in both places.
Platform
Cart, tender, discount, refund, and cash drawer run through a single canonical checkout workflow — identical in the browser and inside a native iOS shell on iPad. Not two products kept roughly in sync.
The register queues carts, tenders, and inventory writes locally, then reconciles automatically the moment connectivity returns.
Keyboard, scanner, and touch paths are first-class. Budtenders move through a sale without hunting for the next control.
Employee attribution, manager overrides, and permission checks are part of the transaction record, not a separate log.
Cart
Illustrative. Demos run in a dedicated environment with our team.
In detail
One implementation of the sale — line items, discounts, loyalty, tax, tender, change, and receipt — shared by the web register and the iPad shell. Fixing a bug fixes it in both places.
Cash sessions, drawer counts, drops, pickups, and blind-close reconciliation, with variance attributed to the employee and shift that produced it.
Refunds resolve against the original transaction, restore inventory correctly, and carry the same compliance and attribution requirements as the original sale.
ID scanning and consent capture happen inside checkout rather than as a bolt-on step a budtender can skip under pressure.
Receipt and label printing, cash drawers, and scanners are driven through a local hub service, so peripherals keep working during an outage.
Terminals enroll with proof-of-possession and bind to a store. A stolen tablet is not a working register.
Connected
These are the areas this capability touches most directly.
Demos are run by our team in a dedicated demo environment, walked through live on a call — so you see the parts that matter to your operation, not a generic tour.