Service resilience
POS Internet Outage Plan: Orders, Payments and Recovery
Build a safe POS internet outage plan that separates order capture, payment approval, printing and reconciliation, with clear escalation and recovery checks.
Write down what must keep working
An internet outage can affect several parts of a venue in different ways. A till may still display a menu while a kitchen device cannot receive new tickets. A payment terminal may use a separate mobile connection. A cloud report may stop updating even when a local printer continues working. Start your outage plan by listing these dependencies separately instead of asking a single question about whether the POS works offline.
If you are assessing HozPOS for venue operations, request evidence for the exact deployed build and device combination you intend to use. A visible offline badge or queued-order screen is not proof of authorised card processing, durable storage or correct recovery. This guide is a planning checklist, not a claim that HozPOS or any other product has completed your venue's resilience tests. Keep unverified functions clearly marked.
Separate order capture from card processing
Ask where an order is stored, which device can see it and what confirms delivery to the preparation station. Then ask a separate set of questions about payments: which provider and terminal are involved, whether an offline mode is supported for your account and territory, and who carries the risk of a later decline. Do not assume that an order recorded as paid in a demonstration represents a completed transaction with your payment provider.
Square's US offline-payment instructions demonstrate that the answer depends on supported devices, payment methods and operating conditions. Those instructions apply to Square's stated US service, not automatically to another provider or country. Obtain your own provider's current documentation and supported recovery steps. Do not copy time limits from an old article or use a competitor's feature as evidence of your own system's capability.
Prepare a fallback that does not remove safeguards
Keep the duty manager's escalation contacts available without the cloud dashboard. Document the symptoms staff should report, such as an order that has not reached the kitchen or a terminal showing an uncertain payment result. Specify which activities must pause and who can authorise a supported alternative. A controlled pause is preferable to repeatedly pressing a payment button when the previous attempt may already have reached the processor.
Do not disable firewalls, certificate validation or staff access controls to make a failed test appear successful. Do not write down card numbers, request sensitive payment information over chat or share an administrator login among the team. The PCI merchant security resources help frame payment-data responsibilities, but your provider and appropriate advisers must confirm the requirements for your setup. Keep technical troubleshooting separate from decisions about accepting financial risk.
Rehearse with approved test data
Use a provider-supported test environment or another explicitly authorised rehearsal arrangement. Record the starting order, device, user role, network condition and expected result. Check an unsent order, a sent kitchen ticket and an unsettled tab as separate scenarios. Make clear whether the test involved a simulated connection loss or an actual disconnected device. Avoid disrupting a live service merely to produce a demonstration screenshot.
The sports bar EPOS checklist provides a service scenario you can adapt. Include the staff member who receives the order, not just the person operating the till. A cashier seeing a success message does not prove that the kitchen received the same order once, with the correct changes. Capture unresolved results and stop the rehearsal if it could create duplicate transactions or expose customer data.
Recover one system at a time
When connectivity returns, confirm the provider's recommended sequence before restarting apps or clearing data. A pending operation may need time to reconcile. Distinguish failed, pending and completed states, and do not retry an uncertain financial operation until an authorised operator has checked its actual status. Keep a record of any manual service adjustments so they do not become unexplained differences in sales or inventory later.
Reconcile the order list, preparation tickets, receipts and payment-provider records using their actual identifiers. Stock can need a separate check if sales or wastage were recorded later than usual. Our restaurant stocktake and variance guide explains why matching time boundaries and units matters. A healthy connection indicator is the beginning of the recovery check, not evidence that every queued action has already completed correctly.
Keep the plan short enough to use
Summarise the routine on a shift handover sheet: recognise the failure, tell the manager, use only the approved fallback, protect payment information and reconcile before closing. Keep the detailed technical evidence separately. Staff need an understandable next action, while the manager needs enough information to decide whether trading can continue safely. Review the plan whenever you change a terminal, network, printer or critical software release.
After a real incident, record its cause if known, the actions taken, the unresolved transactions and the follow-up owner. Do not promise uninterrupted service based on one rehearsal; use the evidence to improve the next one. The HozPOS operations journal connects this plan with stock and service preparation. A useful outage plan makes uncertainty visible and gives the team a controlled response instead of an improvised workaround.