Offline POS: What to Test Before a Store Rollout

A store can lose its internet connection while the terminal, printer and local network still have power. What happens next depends on the POS application, the devices connected to it and the workflow staff need to complete.

Before selecting hardware for a rollout, ask the software provider to define what “works offline” includes. Then turn that answer into a test plan for the exact store configuration. A successful sale at one terminal leaves several other questions open: did the kitchen receive the ticket, did the order reach the back office after reconnection, and can another cashier see it?

01 / FIELD CHECKSeparate internet loss from a local network or power failure

Use distinct test cases for a failed internet uplink, a disconnected terminal, an unavailable printer and a loss of power. Keep the store router and printer running when testing an internet-only outage. Test their failure separately so you can identify which dependency stopped a workflow.

A restaurant implementer on Reddit raised precisely this distinction: with a remotely hosted Odoo server and printers inside the restaurant, would kitchen tickets still print during an internet outage? The comments offered conflicting assessments of direct printing. Treat that discussion as a reason to test the proposed print path, rather than as proof that a particular arrangement will work. [1]

02 / FIELD CHECKDefine which operations must remain available

Ask for a feature-by-feature answer. Shopify distinguishes offline checkout from its optional offline card-payment feature. Its documentation also says that orders and inventory cannot sync with the admin while POS is offline. This is a software example, not a compatibility claim for an OCOM terminal. [2] [3]

Loyverse documents a different set of limits: offline receipts remain on the device until synchronization, refunds are unavailable, open tickets do not sync between devices, and integrated card terminals do not work offline. These differences are why a general “offline POS” label is too broad for a purchase specification. [4]

03 / FIELD CHECKTest with a small, traceable set of orders

Use a test environment or an agreed pilot procedure. Prepare a few identifiable products, including one scanned item and one item routed to a kitchen printer if the store uses one. Record starting quantities, order references and the software version.

1. Establish a baseline. Complete an online test order and verify the intended devices and back-office record.
2. Interrupt the internet connection. Preserve the local network for this case. Follow the provider’s supported offline workflow and create clearly identified test orders.
3. Observe each device. Check the receipt, kitchen ticket, cash-drawer action and customer display independently. Record unavailable actions rather than assuming they will recover.
4. Reconnect once. Confirm that each expected order appears in the back office once, with the correct items and totals. Investigate missing or duplicate records with the software provider.
5. Reconcile the workflow. Check the relevant inventory changes and the payment provider’s final status separately. A local order or printed receipt does not, by itself, verify every downstream step.

For a second till, add a test that shows what another cashier can see during the interruption and after synchronization. Keep application restart and device power-loss cases separate from the first exercise, with the integrator’s recovery instructions agreed in advance.

04 / FIELD CHECKPut recovery and support responsibilities in the handover

Ask the integrator to write down how staff recognize an unsynced order, when to stop taking new orders and who checks reconciliation after service returns. Avoid improvised recovery actions such as clearing application data while records remain unsynced; use the software provider’s documented procedure.

Agree on who owns the internet connection, local network, POS application, peripheral integration and payment service. Request the terminal’s supported network interfaces and operating-system configuration in the quotation. If backup connectivity or backup power is proposed, have the responsible supplier test that arrangement as a separate requirement.

Keep the approved configuration and test results together. A test on one software version and printer connection should not silently become a promise for a different deployment.

Preparing your hardware requirements for OCOM

Send OCOM the POS application and version, deployment country, required peripherals, preferred operating system and expected terminal quantity. Include the operations your store must retain during an outage and identify which software or payment partner will validate them.

Use the POS-1566 product information as a starting point for a hardware discussion, then confirm the exact configuration in the quotation. For the broader sample checklist, see POS Hardware Compatibility: What to Test Before a Bulk Order.