What to Do When Your POS Goes Down — Offline Mode and Recovery Playbook

It's 11:00am Saturday. Your busiest hour. Comcast just went dark, the router lights are blinking amber, and there are six people in line. This guide is for that moment — and the one after it, when you want the outage to never cost you a sale again.

Why your POS goes down

When operators say "the POS is down," they almost never mean the POS software itself crashed. The actual root causes, ranked by frequency:

1. 1ISP outage — Comcast, Spectrum, AT&T fiber, Cox. Regional cable cuts, head-end maintenance, or just a flaky last-mile drop. The FCC requires major carriers to report significant service outages through the Network Outage Reporting System, but the small ones that wreck a Saturday at your shop never show up there.
2. 2Router or switch failure — the box in the back office has been running 24/7 for four years and finally gave up. Or the PoE switch that feeds the terminals lost a port.
3. 3Power outage during a partial grid event — power flickers, the UPS holds the terminals but not the router, and the modem reboots into a 10-minute negotiation cycle.
4. 4Payment processor downtime — rare but real. The card networks themselves almost never go down, but individual processors do, and that hits authorization, not the POS itself.
5. 5POS vendor incident — the cloud platform has a regional issue. Modern vendors publish status pages; this is the case where offline mode matters most.

The takeaway: roughly 80% of "POS down" events are local — your router, your ISP, your power. The cloud is rarely the problem. Which is why offline mode, properly configured, handles most of these without you even noticing.

One pattern worth naming: the first thing most operators do when something glitches is open a ticket with the POS vendor. That's the wrong first step. Almost always the issue is upstream of the vendor, and 10 minutes of router diagnostics resolves what an hour-long support call wouldn't. Save the vendor call for after you've ruled out the local network.

What offline mode actually does

At a modern cloud POS, the register caches a working copy of the catalog, tax rules, and dual-pricing logic locally. When the connection drops:

• Cash, gift card, and store credit transactions — process normally. No external network needed.
• Card payments — stored as deferred authorization. The transaction is recorded locally and the auth call queues. When connectivity returns (usually within minutes), the auth fires and clears in the background. Risk: if a card later declines, you're on the hook for that transaction. Most processors cap deferred-auth exposure at a per-transaction ceiling (often $50–export const blogPosts: BlogPost[] = [

50) for exactly this reason.

• Loyalty lookup — works for any customer whose record was synced recently. New lookups or point balances older than the last sync may be stale.
• Inventory — deductions happen locally and write to the cloud on reconnect. On-hand counts are accurate at your register; multi-location visibility waits until sync resumes.
• Reporting — end-of-day, X-reports, and Z-reports still work from local data. Multi-location consolidation and back-office dashboards wait for the connection.
• Receipts — print and email-queue normally. Email sends when the connection returns.

What this means in practice: a single-register shop loses almost nothing functional during a typical 30-minute ISP outage. A multi-location operator loses the cross-store view but keeps each register independently operational.

There's a second-order benefit worth calling out. Because the register caches catalog, pricing, and tax rules, the speed of ringing a sale during an outage is sometimes faster than during a normal day — the terminal isn't waiting on any round-trip to the cloud for the line items. Customers usually don't notice anything is wrong. That's the bar a well-configured offline mode should hit.

The 9-step recovery playbook

When the lights blink and the spinner starts spinning, run this in order. It takes about three minutes from step 1 to "back to ringing."

1. Check the router (power cycle)

Walk to the router. Unplug it. Count to 30. Plug it back in. Wait 90 seconds for it to negotiate. Roughly 40% of "outages" resolve here — the router locked up, not the ISP.

2. Check cellular failover

If you have a 4G/5G failover router or a terminal with built-in cellular (the PAX A77 ships with 4G LTE active by default on every Lifelong deployment), it should auto-failover within 15–60 seconds of the primary line dropping. Look for the cellular indicator on the terminal — usually a small signal-bars icon or an "LTE" label. If it's green, you're already back online; the queue you thought was forming was just the failover transition.

3. Switch the register to offline mode

Every modern POS has a toggle or it does this automatically. On Lifelong systems it's automatic — the register detects the dropped connection within ~10 seconds and shows a small "Offline" banner. If your platform requires manual flip, the toggle is usually in Settings → Connectivity or accessible from the register status bar.

4. Inform staff with a 30-second script

Tell the team — and the line — calmly:

> "Our internet is briefly out. Card payments are still working, just a slight delay. Cash and gift cards are normal. We're not closed."

That sentence prevents 90% of the customer anxiety. Don't say "the system is down" — that triggers people to bail. Say "internet is briefly out, card payments are still working."

5. Set a cash-only fallback ceiling for high-value transactions

For transactions above a threshold (we recommend $200 for general retail, $500 for verticals with higher average tickets), require a manager to approve the offline card auth or ask the customer for cash. The deferred-auth risk on a $40 t-shirt is negligible. On a export const blogPosts: BlogPost[] = [ ,400 piece of equipment, it isn't. Set this ceiling in the back office before the outage so staff aren't making the call under pressure.

6. Process refunds with paper backup

Refund authorization sometimes requires a cloud lookup (original-transaction validation, loyalty rollback, store-credit issuance). If a refund won't go through, do the refund on paper: customer's name, original receipt number, amount, reason, signed. Process it in the system when connectivity returns. Most platforms have a "post-dated refund" workflow for this.

7. Pause integrated online ordering

If your shop has online ordering or buy-online-pickup-in-store integrated through Havok, Square Online, or a similar storefront, pause it from the storefront admin if you can reach it (sometimes the storefront is hosted elsewhere and still up while your in-store internet is down). Don't accept orders during an outage you can't fulfill in real time — you'll create a queue of confused customers when the system reconciles.

8. Reconcile after the connection returns

Within 5 minutes of the connection coming back:

• Watch the deferred-auth queue clear. Most platforms show a count of pending auths. It should drop to zero.
• Spot-check any flagged transactions. A failed auth shows as "needs attention" — usually a card with no funds or a closed account. If a transaction failed, you have the customer's name and the card last-4 from the local record; reach out for a re-run.
• Confirm inventory sync completed. Multi-location operators: confirm the day's sales hit the cross-store dashboard.
• Confirm online-ordering integrations are re-enabled.

9. Document the incident for vendor follow-up

In a simple log (a Google Doc works), capture:

• Start time, end time, duration
• Symptom (no internet, slow sync, terminal frozen)
• What you did (router cycle, cellular failover, called ISP)
• Number of deferred auths and how many failed
• Sales count during the outage

After three of these, patterns appear. If your ISP is at fault twice a month, that's a service-credit conversation. If your router has lockups, that's a hardware-replacement conversation. Pattern visibility is what turns a recurring problem into a fixable one.

What CAN'T be done offline

Be honest with staff about what offline mode doesn't cover, so they don't try and burn time:

• Real-time inventory checks across locations — "Does the Buckhead store have one in stock?" can't be answered until sync resumes.
• New customer creation with full loyalty enrollment — most platforms queue the record locally; loyalty number issuance may be delayed.
• End-of-day cloud backup — Z-report runs locally; the cloud backup happens on reconnect.
• Refund authorizations that require an original-transaction lookup beyond what's cached.
• Loyalty point redemption beyond what's cached — if a customer says "I have 4,200 points," you may not be able to confirm.
• Reporting from the back office — the owner at home can't pull a sales dashboard during the outage. Wait.

Hardware that earns its keep when this happens

The right hardware turns most outages into non-events:

• PAX A77 with 4G LTE built in — when Wi-Fi or wired internet fails, the terminal's cellular radio takes over without operator action. Auths keep clearing in real time, not deferred. This is the single highest-ROI hardware feature for outage resilience.
• Landi C20 Pro with Ethernet backup — if your Wi-Fi is flaky (interference from the neighboring building, a marginal access point), the Ethernet line is a fallback path before you even need cellular.
• UPS battery on the router — a $90 consumer UPS keeps your router and modem up during a 10-minute power flicker. Without it, every brownout becomes a 5-minute reboot cycle and a 90-second ISP renegotiation.

This is why we push hardware-first architecture rather than tablet-on-Wi-Fi for serious retailers: a tablet running cloud POS over consumer Wi-Fi is a single point of failure. A PAX A77 with cellular failover is two paths to the processor before you even notice. The cost delta between the two architectures is a few hundred dollars one-time — a single Saturday outage on the tablet setup wipes that out in lost sales.

For the full hardware lineup and our recommendations for resilience, see the Lifelong hardware lineup and the /resources/blog/pos-hardware-buyers-guide-2026.

Preventing the next outage

A 30-minute audit, once, prevents most future incidents. The checklist:

• Cellular failover — confirmed active on terminals or router. Test by unplugging the primary line on a Tuesday morning; the terminal should keep working.
• UPS battery on router and modem — rated for at least 15 minutes runtime. Replace the battery every 3 years.
• Separate VLAN for POS — your POS traffic doesn't share a broadcast domain with the guest Wi-Fi or the back-office laptop. Reduces "guest streaming knocked out the register" incidents.
• Monthly offline-mode test — at 8am on a slow weekday, unplug the WAN line for 5 minutes. Confirm the terminal goes offline, processes a export const blogPosts: BlogPost[] = [

test transaction, and reconciles when reconnected. Log the test.

• Processor relationship that supports offline auths — confirm your merchant agreement allows deferred authorization and know the per-transaction ceiling.
• Documented runbook at the register — the 9-step playbook above, printed, taped under the drawer.

The NIST Cybersecurity Framework treats this kind of preparation under the "Recover" function — having a documented, tested process for restoring operations after a disruption. A POS outage is a small business-continuity event; treating it that way moves it from "panic" to "procedure."

Where Lifelong fits

Every Lifelong POS deployment ships with offline-mode active by default, and every PAX A77 ships with 4G LTE active out of the box. Our standard maintenance playbook includes a 5-minute monthly offline-mode test that the merchant or our remote support team runs together, so the first time a real outage happens isn't the first time anyone confirmed the failover works.

For complex integrations — Havok online ordering, QuickBooks, multi-location consolidation — we configure the queue behavior so each integration knows what to do during an outage rather than failing loudly. See our integration partners and payments architecture for the integration stack we support.

8 years building this since Kermit's first deployment, 500+ merchants across all 50 states, Atlanta-based support team that answers the phone when the lights blink.

FAQ

Can I process credit cards if the internet is down?

Yes, with offline authorization. The transaction is recorded locally and the auth call queues for when the connection returns. Most processors allow this up to a per-transaction ceiling (commonly $50–export const blogPosts: BlogPost[] = [ 50). The small risk window: if a card later declines, you're on the hook. For tickets above your ceiling, fall back to cash or wait.

Will I lose sales data if I lose power?

No. Modern cloud POS caches transactions locally to disk before acknowledging the sale. When power and internet return, the queue syncs. We have not seen a properly configured modern POS lose sales data to a power outage in years. The bigger risk is unposted transactions — a sale started but not completed when power dropped — which is why a UPS on the register is worth $90.

How long can a POS run offline?

Depends on the processor agreement and the platform's cache size. Typical range: 4 to 24 hours of full offline operation. We've ridden out 6-hour Comcast outages without intervention. Beyond 24 hours, deferred-auth queues start to get large enough that the platform may pause new card authorizations and ask the operator to switch to cash-only. The shop that gets hit hardest by long outages is the one that didn't put a UPS on the router — the modem reboots every time the power dips, and the cumulative downtime adds up.

Does dual pricing still work offline?

Yes. Dual-pricing rates (cash vs card pricing for surcharge or cash-discount programs) are cached locally on the terminal. The math happens at the register, not in the cloud, so the price the customer sees is correct even with no connection.

What about Havok or other online orders during an outage?

Pause online ordering from the storefront admin — the storefront is often hosted separately and still reachable from a phone even when your in-store internet is down. When you reconnect, the order queue reconciles: the platform will show you any orders received during the gap, and you process them in normal flow. Don't try to accept orders you can't see in real time.

Get a free outage-resilience audit

If you're not sure whether your current POS would survive a Saturday-morning ISP outage, we'll run through the 30-minute checklist above with you over a phone call. Free. We'll tell you what's set up correctly, what isn't, and what the cheapest fixes are — even if you're not a Lifelong merchant.

Atlanta-based, 500+ active merchants, 99% retention rate.