The best offline POS is the system whose precise continuity behavior matches the business's risk and can be operated by trained staff. Square, Toast, and Lightspeed serve different merchant workflows, devices, and configurations. Buyers must verify current published terms and proposed settings rather than treating “offline” as one universal function.

Define what offline must preserve

Square may fit smaller merchants seeking continuity inside a broad stack. Toast may fit restaurants where orders, kitchen production, tables, and shift workflows must continue. Lightspeed may fit retail or hospitality operations that also need inventory and location recovery. The comparison is not a claim that each option handles every outage identically.

Separate local network failure, internet loss, provider disruption, device failure, peripheral failure, integration outage, and power loss. For each, define whether catalog access, order entry, production, cash, card acceptance, receipts, inventory, tips, refunds, and close continue. Document what is queued, unavailable, locally stored, later synchronized, or exposed to additional risk.

Scenario: selling continues while state becomes uncertain

During a busy period, internet access fails but local devices remain powered. Staff see an uncertain payment state, one customer retries, stock continues moving, and a manager changes an order. When service returns, deferred records and live transactions appear together. Finance must distinguish completed, failed, duplicate-looking, and corrected events.

Square should show that its recovery instructions remain simple for the proposed merchant setup. Toast should show restaurant orders and payments reconcile without losing production context. Lightspeed should show inventory and location records remain explainable. No candidate should receive credit for continuity that the written configuration does not support.

Run a controlled outage evaluation

Use synthetic orders and approved payment test modes. Establish a clean baseline, then interrupt one dependency at a time: internet, local network where safe, a noncritical integration, and one device. Run card and cash paths only as supported, modify an order, attempt a prohibited function, replace hardware, and reconnect.

Record every staff message, timestamp, local identifier, risk warning, retry, synchronization event, and support step. Reconcile orders, tenders, refunds, tips where relevant, inventory events, and settlement-related reports. Repeat with a backup manager using a printed runbook. This publication has not performed the evaluation and does not assert specific offline limits.

Define the stop-selling threshold before the exercise. It may depend on outage duration, tender, basket value, customer communication, queue visibility, inventory uncertainty, or inability to reach support. Assign authority to invoke and end the fallback. Staff should never invent a threshold during a line or override warnings merely because a device still accepts input.

Edge case: deferred acceptance is treated as guaranteed payment

An offline or deferred workflow may involve approval uncertainty, timing limits, configuration requirements, merchant risk, or later failure. Buyers must obtain current vendor definitions and train staff not to retry blindly or promise final payment status. Customer communication and correction authority belong in the outage plan.

Offline capability also does not establish PCI DSS compliance. Map device, application, network, storage, provider, processor, merchant, and validation responsibilities using PCI SSC sources. Sales-tax settings and retained fields do not prove correct legal treatment; tax ownership remains separate from operational continuity.

Offline criteria and conclusion

Score failure detection, staff guidance, permitted functions, risk visibility, local order continuity, payment-state recovery, inventory correction, duplicate controls, device replacement, support escalation, reconciliation, and evidence export. Include power, backup connectivity, spare equipment, and the manual decision to stop selling.

Choose the candidate whose documented configuration survives the business's most credible outage and makes recovery auditable. Square, Toast, and Lightspeed should each be tested in their intended operating context. The winner is not the system that promises the broadest offline label, but the one whose staff can recognize limits, protect customers, and reconcile every exception.

Traceable evidence

Sources for this decision

5 sources
  1. vendorSquare official product siteSquare · checked Aug 5, 2026
    Open source ↗
  2. vendorToast official product siteToast · checked Aug 5, 2026
    Open source ↗
  3. vendorLightspeed official product siteLightspeed · checked Aug 5, 2026
    Open source ↗
  4. standardsPCI Data Security StandardPCI Security Standards Council · checked Aug 5, 2026
    Open source ↗
  5. standardsPCI SSC Merchant ResourcesPCI Security Standards Council · checked Aug 5, 2026
    Open source ↗