Offline POS Picks for Kitchens, Counters, and Cash-First Stores

No POS earns an “offline” verdict from a feature label: what matters is whether its 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

Each vendor documents a different offline model, checked on October 7, 2026.

• Square: its support center describes offline card payments inside the Square POS app. Payments are stored and processed on reconnection, and Square recommends uploading them within 24 hours. Gift cards, Tap to Pay, and manually entered cards are excluded, and declines are not reported until the device is back online.
• Toast: its support center describes an Offline Mode that devices enter after about 40 seconds without a connection. Orders and card payments continue, with receipts showing a pending authorization. Toast advises each employee to stay on one device so order and payment information stays together, and reports exclude offline data until the system syncs.
• Lightspeed: its Retail (X-Series) help center documents two separate pieces. On the register, offline mode is a backup that keeps cash sales, parked sales, and new customers or products available and syncs them on reconnection, but integrated card payments, gift cards, loyalty, and inventory views stop. For cards, Lightspeed Payments offline mode on the Smart Terminal (beta) must be enabled before the outage; staff key in the amount, and the payment is not linked to a sale in the POS.

Square, Toast, and Lightspeed (for its Smart Terminal offline payments) each state in the cited article that the merchant is responsible for declined or expired offline payments. None of this is a guarantee of behavior in a specific setup.

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.

The documented models diverge exactly here. On Square, the sale and its card payment stay together in the POS, but a decline appears only after reconnection. On Toast, order and payment information stays with the device that took it, so the manager must know which device holds which table. On Lightspeed, the register keeps cash sales but cannot take an integrated card, and the Smart Terminal (beta) collects card money without a sale record, so each card sale must be matched to its terminal payment and stock by hand afterward. 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. POS Platform Guide has not performed the evaluation and does not assert offline limits beyond those stated in the cited vendor articles.

Define the stop-selling threshold before the exercise. It may depend on outage duration, tender, basket value, customer communication, how long the checkout line is, 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 Toast when a restaurant must keep orders flowing to the kitchen through an outage and can assign one device per server. Choose Square when a retail or counter business needs the sale and payment to stay linked offline and can reconnect within a day. Choose Lightspeed X-Series when a store can lean on cash during an outage and accept that card payments on the Smart Terminal (beta) are reconciled to sales by hand. If the business cannot stop taking cards, cannot assign devices, and cannot reconcile by hand, none of the three documented models fits, and a manual card fallback agreed with the processor belongs in the plan instead. The right choice is not the system that promises the broadest offline label, but the one whose staff can recognize limits, protect customers, and reconcile every exception.