Restaurant Networking & Configuration Knowledge Base

Why the network matters more than the app

Most POS complaints — slow printing, disappearing tickets, failed payments — are network problems misdiagnosed as software bugs. A cloud POS depends on stable local networking to reach printers, terminals and the internet. A restaurant with a strong network can run demanding software on modest hardware; a restaurant with a weak network cannot rescue itself with a better POS.

This knowledge base is intentionally practical. It is written for operators and installers, not for network engineers.

Baseline network topology

• One business-grade router or firewall — not a consumer ISP box.
• One managed or smart-managed switch for wired devices (printers, KDS, back-office PC).
• One dedicated access point (or mesh) for staff and terminals; a separate access point for guest Wi-Fi.
• Wired connections for every printer and KDS screen when the building allows it.
• A secondary internet link (4G/5G router) as failover for payments.

Wi-Fi configuration

Use two SSIDs at minimum: one for staff and POS devices (WPA2/WPA3, hidden or not, with a strong passphrase), and one for guests (captive portal or open with rate limiting). Never place cashier tablets on the guest network — it exposes them to other guest devices and to bandwidth spikes.

Place access points where staff actually work: near the cashier stand, in the kitchen expo area, and above the dining room. A single AP hidden in the manager's office almost always leaves dead spots at the bar and terrace.

Static IPs and DHCP reservations

• Assign a DHCP reservation (or true static IP) to every receipt printer and KDS screen.
• Document the IP list in a printed sheet kept at the manager's station.
• Use a private range like 192.168.10.0/24 and reserve .10–.29 for infrastructure, .30–.99 for printers/KDS, .100+ for terminals and tablets.
• Never let the printer IP change — kitchen tickets that stop printing are almost always a lost printer IP.

DNS, firewall and payment terminals

Allow outbound HTTPS (443) to the POS provider, the payment gateway, the email sender domain and any integration endpoints. Block inbound connections from the internet — no port forwarding is needed for a cloud POS.

Payment terminals often need specific outbound hosts open. Ask the acquirer for their allowlist and add it to the firewall. Do not put the terminal on the guest network, even 'just for testing.'

Printer routing and troubleshooting

• Route categories to printers: hot kitchen, cold kitchen, bar, expo, cashier receipt.
• Test each route after any menu change — a category with no route falls silently to the default printer.
• Keep a laminated 'printer not printing' checklist: power, cable, IP reachable, paper, cover closed, error light.
• When a printer disappears from the POS, first ping its IP from the manager's PC; if that fails, the network is the fault, not the POS.

Internet failover and monitoring

A 4G/5G failover router costs less than one bad night. Configure the primary link (fiber or cable) as WAN1 and the cellular link as WAN2, with automatic failover for payments and cloud sync. Test the failover monthly; untested failover is not failover.

Basic monitoring — even a free uptime check on the POS URL and a status LED for the printers — gives managers a head start on issues before guests notice.

Frequently asked questions

Can I run the whole restaurant on Wi-Fi only?

Small venues can, if the access points are placed well. Larger venues should wire printers and KDS screens and use Wi-Fi only for tablets and phones.

Do I need a business ISP plan?

Yes, for the SLA and static IP option. Residential plans are cheaper but have no support commitment during a rush.

How do I stop tickets from disappearing?

Almost always a lost printer IP. Assign DHCP reservations, document the IPs, and check the printer's ping response first when tickets go missing.