Quick answer: When restaurant or hotel POS loses connectivity, first identify whether one terminal, one counter, the whole venue or only payment is affected. Separate the POS app, receipt/kitchen printer, local network, Internet and payment gateway. Record the time, device, error and last confirmed transaction. The shift manager owns the service fallback; IT checks endpoints and network; the POS or payment provider investigates application and transaction status. Never retry a card payment whose first result is unknown.
Classify the impact before restarting equipment
“POS is down” may mean the app will not open, orders do not reach the kitchen, a receipt printer is offline, revenue sync is delayed or a payment has an uncertain result. These symptoms belong to different components. Ask when it started, which counter is affected, whether another terminal works and whether the last successful transaction appears in the report.
Guest Wi-Fi working does not prove the POS network is healthy. Guest and business devices may use different SSIDs, VLANs, DNS or Internet paths. Record where the failure occurs and which network the terminal uses before escalating.
POS, Wi-Fi and payment triage matrix
| Symptom | First checks | Primary owner | Avoid |
|---|---|---|---|
| One POS will not open | Power, network, login, app update or error notice | Endpoint IT and POS vendor | Removing app data before backup |
| Several terminals lose service | AP/switch, gateway, DNS, ISP and recent changes | Network IT; ISP if needed | Resetting all network equipment before preserving logs/config |
| Order accepted but kitchen does not print | Printer, queue, IP, paper, cable/Wi-Fi and routing | Shift lead, IT and POS vendor | Repeatedly resending orders and creating duplicates |
| Payment result is uncertain | Reference ID, bank/payment-gateway status and receipt | Manager and payment provider | Charging again before reconciliation |
| Guest Wi-Fi fails but POS works | Guest SSID, captive portal, DHCP, uplink and coverage | Network IT | Moving POS to guest Wi-Fi as an untested workaround |
Incident workflow during service
1. Protect transactions and guest service
The shift manager records start time, affected area, counters and open orders. For an uncertain card payment, retain the reference/receipt and confirm its state with the payment provider before retrying. Any paper or alternative workflow must be approved, assigned to named staff and reconciled at shift close.
2. Test one affected terminal against a working one
Check power, Ethernet or Wi-Fi, device time, login, application status and the associated printer. Avoid changing several devices at once; a known-good terminal helps isolate the fault.
3. Keep guest and business networks distinct
Record the POS SSID and location, then check AP, switch, gateway, DNS, DHCP, captive portal and ISP against the actual network design. Do not change VLANs or broaden access without approval. NIST’s hospitality reference environment illustrates separation between guest, employee and property-management networks; it is a design reference, not a configuration to copy blindly.
4. Escalate application and payment issues with evidence
If the network is stable but one POS function fails, record app version, preceding action, error, time and a redacted order reference for the POS vendor. Send payment references to the payment provider. Do not post card numbers or authentication data in ordinary tickets or group chats.
Network boundaries and payment data
Network design should account for POS, property-management systems, kitchen printers, staff devices, guest Wi-Fi and office systems. Permit only required flows under a design confirmed by the system owner and vendors. The PCI Security Standards Council explains that effective, validated segmentation can help limit assessment scope. Drawing VLANs on a diagram alone does not prove PCI DSS compliance. IT Systems does not replace an authorized assessor or promise certification without a formal assessment scope.
Redact guest and payment data in incident evidence. Limit log access by role and retain only the transaction references required by company policy.
Incident closure and prevention checklist
- Time, area, shift, counters and affected service.
- POS/printer/AP model and asset ID, SSID and relevant network path.
- Redacted error image and order/payment reference.
- Recent changes to ISP, Wi-Fi, POS release, printer or credentials.
- Confirmed cause, owner, restoration time and temporary guidance.
- Retest: open shift, send order, print in kitchen, close bill and reconcile a test payment.
- Named owner and review date if the issue recurs.
Close the incident only after the shift lead confirms the actual workflow. A successful ping to a printer does not prove that a kitchen ticket was produced end to end.
When a venue needs an IT incident owner
If staff must call the ISP, Wi-Fi installer, POS provider, printer vendor and payment gateway separately, define one incident owner, a shared ticket, escalation paths and a restoration test. See IT services for restaurants, hotels and cafes for the service scope covering POS/PMS coordination, Wi-Fi, endpoints, vendors and shift-based support.
Frequently asked questions
Should we move POS to guest Wi-Fi during an outage?
Not without approval and a tested design. Guest networks may restrict required services and can mix business and guest devices. Use only a fallback validated by IT and the POS provider.
A card payment is pending. Should staff retry?
Check its status with the payment provider using the transaction reference first. Retrying before the first result is known can create a duplicate charge.
Who investigates when POS has Internet but cannot send orders?
IT checks reachability, DNS and network state; the POS provider checks application, account, order and kitchen integration. One ticket owner should follow the incident through a real service test.
Need a POS, Wi-Fi and printer review?
IT Systems can assess the network and incident workflow, coordinate with POS/ISP providers and define shift-based validation checks.
References: NIST NCCoE, Securing Property Management Systems; PCI SSC FAQ on payment-system scope and network segmentation.
