Your POS Is Not Offline-Ready Until the Recovery Plan Is Clear

The internet goes down at 2:30 on a busy Saturday.

One customer is ready to pay. Another is collecting an online order. A member of staff is trying to return an item. The last unit of a popular product may already have been sold through another channel.

Your POS shows an offline symbol.

Can the shop keep trading?

The honest answer is not a simple yes or no.

"Offline mode" can mean that cash sales continue. It can mean selected card payments are stored on one device and submitted later. It can also mean that checkout remains available while customer search, gift cards, returns, discounts, online orders, inventory views, or connected apps stop working.

That is why an offline payment badge is not a continuity plan.

A retailer needs to know what staff can do during the outage, what new risks they are accepting, what information may become stale, and how every pending transaction will be recovered afterwards.

The question retailers are actually asking

In one retailer discussion after a POS outage, the practical question was not, "Does this platform have offline mode?"

It was: "What backup plans do I need to have in place to keep selling?"

The retailer kept a duplicate invoice book under the counter, entered transactions later, and maintained a second payment option. That response may not suit every business, but it exposes the real job.

The job is not to keep one screen open. It is to keep the sale, payment, order, stock record, and customer promise recoverable.

That requires three separate answers:

1. What still works while the connection is down?

2. What must staff stop doing or handle differently?

3. What must be checked after the connection returns?

If a POS provider cannot explain all three in plain language, the retailer does not yet have an offline plan.

Offline payment is not offline retail

Current provider documentation makes the distinction clear.

[Square's US offline-payment guidance](https://squareup.com/help/us/en/article/7777-process-card-payments-with-offline-mode) says supported offline payments are stored in the POS app and processed after the device reconnects. It also lists unsupported payment types and hardware, warns that declined payments are discovered after reconnection, and places responsibility for expired, declined, or disputed offline payments on the seller.

[Shopify POS documentation](https://help.shopify.com/en/manual/sell-in-person/shopify-pos/selling-offline/offline-features) says a logged-in device can continue some work offline, but new-product creation, customer search and editing, tips, gift cards, returns, exchanges, voids, automatic discounts, and some fulfilment actions require an internet connection. Orders and inventory do not sync with Shopify admin until connectivity returns.

[Lightspeed Retail X-Series documentation](https://x-series-support.lightspeedhq.com/hc/en-us/articles/25534272395163-Selling-in-offline-mode) explicitly describes offline mode as a backup function rather than a complete solution for offline selling. Its current guidance says only certain pages and actions remain available, and product inventory information is not visible offline.

These are not minor differences hidden in a technical appendix. They change what a shop assistant can promise a customer during an outage.

The correct buying question is therefore:

"Which parts of our real store workflow remain safe, and how do we recover the rest?"

Step 1: Identify the failure before choosing the fallback

Not every outage is the same.

The shop's Wi-Fi may have failed. The broadband provider may be down. A payment processor may have a service disruption. The POS platform may be unavailable while the wider internet still works. One till may be affected while another remains connected. The building may have lost power.

Each situation can require a different response.

A useful opening procedure should tell staff how to check:

• whether other websites or devices can connect
• whether the POS provider reports a service incident
• whether the payment terminal has its own connection
• whether a mobile hotspot is available and approved
• whether the fault affects one device, one location, or the entire business

This matters because switching into an offline workflow unnecessarily can create pending transactions and extra reconciliation work. Waiting indefinitely for a broken connection can lose sales.

The operating rule needs to be explicit: who declares the outage, which fallback starts, and how staff know when normal operation has returned.

Step 2: Define exactly which payments are allowed

"Card payments work offline" is too vague for staff guidance.

Ask the provider:

• Which card types and payment methods are supported?
• Does the feature work in our country and account plan?
• Which readers, terminals, phones, and tablets are compatible?
• Must offline payments be enabled before the outage?
• Can we set a maximum value per transaction?
• How long can the device accept or store pending payments?
• When must it reconnect and upload them?
• Who carries the loss if a payment is declined later?
• Can a pending payment be cancelled or refunded?

Square's current US guidance, for example, distinguishes between supported hardware and payment types, recommends uploading promptly, and says pending payments can expire if they are not uploaded within the required period. Shopify says offline card processing may be available in some configurations, but capture happens after reconnection unless eligible hardware and settings support a different path. Lightspeed tells retailers using third-party processors to confirm offline options with that provider.

The general lesson is simple: offline card acceptance is deferred risk, not guaranteed money.

A retailer should set a transaction ceiling that reflects what it can afford to lose, rather than accepting every high-value sale because the screen permits it.

Step 3: Protect the device holding pending transactions

During normal trading, restarting an app or signing in again can feel harmless.

During an outage, the device may be the only place where an unpaid or unsynced sale exists.

Square warns users with pending offline payments not to sign out, delete the app, switch modes, switch locations, or factory-reset the device or hardware. Shopify warns that logging out or turning off a device may cause loss of offline orders. Lightspeed says unsynced sales are saved in the browser until they can reach its servers.

The exact rules vary, but the operating principle is consistent:

Treat the affected device as a temporary transaction ledger.

Staff instructions should identify:

• which device holds the pending sales
• whether it may be restarted or powered off
• whether the app may be closed or the user signed out
• whether a location, register, or mode may be changed
• who is responsible for keeping it charged and physically secure
• how the next shift is told that unsynced transactions remain

Without this handover, a well-meaning employee can erase the only recoverable copy of the day's transactions while trying to fix the connection.

Step 4: Decide what happens to orders and stock

Payment continuity receives the attention because the customer is standing at the till.

Inventory continuity is where the quiet damage appears later.

When a device cannot sync, it may not receive:

• a web order placed during the outage
• a sale completed on another connected device
• a cancellation or refund
• a stock transfer
• a receiving update
• a manual adjustment from another location

Shopify states that POS orders and inventory cannot sync with Shopify admin while offline. Square notes that, depending on the disruption, new online orders may not appear on the POS until service returns. Lightspeed says product inventory information is unavailable in its X-Series offline mode.

That means the last unit shown before the outage is not automatically safe to promise.

Set a low-stock rule in advance. For example:

• physically verify the last two units before selling
• pause Click and Collect promises for scarce products
• record every manual sale with SKU, quantity, price, payment method, and time
• keep returns and exchanges separate until the system reconnects
• avoid stock transfers and non-essential adjustments during the incident

The goal is not perfect real-time inventory during a disconnection. The goal is a complete enough trail to rebuild an honest stock position afterwards.

For a broader pre-purchase workflow test, see [Before You Buy a POS, Test the Inventory Handoffs](https://ezycarto.com/blog/before-you-buy-a-pos-test-the-inventory-handoffs).

Step 5: Give staff a short outage script

An outage plan that lives only in the owner's head is not a plan.

Put a one-page instruction beside each till. It should be readable under pressure and include:

1. Confirm the type of outage.

2. Notify the duty manager.

3. Start only the approved fallback.

4. Use only supported payment methods and devices.

5. Apply the offline transaction limit.

6. Record each sale or order that may need manual review.

7. Do not sign out, reset, update, or move the affected device unless the provider's instructions permit it.

8. Mark low-stock items for physical verification.

9. Tell customers clearly if receipts, refunds, collections, or confirmations will be delayed.

10. Escalate any uncertain transaction instead of improvising.

The script should also name the person who can approve exceptions. A queue at the till is not the moment for every employee to invent a different risk policy.

Step 6: Reconnection starts the recovery, not the celebration

When the Wi-Fi symbol returns, the incident is not finished.

The system still needs to upload, process, and reconcile what happened while disconnected.

A proper recovery sequence is:

Confirm connectivity

Check the POS, payment service, and any connected sales channels. Do not assume that one successful web page means every service has recovered.

Keep the affected device stable

Leave the app, account, location, and device state unchanged until pending orders and payments have uploaded according to the provider's instructions.

Review payment outcomes

Separate completed, declined, expired, duplicated, and still-pending transactions. Assign an owner to each exception. A sale recorded in the POS is not settled revenue until its payment outcome is known.

Reconcile orders

Check offline receipts or manual invoices against the POS order list. Confirm that each customer order appears once, with the correct items, quantities, price, tax, and payment status.

Reconcile inventory

Compare the items sold during the outage with the stock movements created after sync. Look especially at low-stock products, online orders, returns, and any item handled manually.

This is where a shared stock truth matters. [When the Online Store and the Till Need the Same Stock Truth](https://ezycarto.com/blog/when-the-online-store-and-the-till-need-the-same-stock-truth) explains why channel reconciliation cannot be treated as a background detail.

Close the incident

Record what failed, how long it lasted, which fallback was used, what exceptions remained, and what the team should change before the next outage.

Recovery is complete only when the money, orders, and stock tell the same story.

The POS outage test to run before you buy

Do not settle for a demonstration in which every device has perfect connectivity.

Ask the vendor to help you run this controlled test with the exact plan, country, hardware, payment processor, apps, and sales channels you intend to use:

1. Sign in and complete the required initial sync.

2. Disconnect the approved test device from the internet.

3. Sell an ordinary product for cash.

4. Attempt an eligible card payment using the supported offline setup.

5. Search for a customer and create a new customer.

6. Try a return, gift card, discount, and online-order lookup.

7. Check a low-stock item and note what inventory is visible.

8. Create a sale on another device or channel if possible.

9. Reconnect the test device without signing out or resetting it.

10. Confirm the payment outcome, order upload, inventory movement, receipt, and reports.

11. Deliberately review one exception, such as a declined or duplicated transaction.

12. Write down every step staff would need to remember.

The purpose is not to make a vendor fail.

It is to discover the operating boundary before customers discover it for you.

A practical continuity checklist

Before approving a POS, make sure you can complete these sentences:

• We know how to distinguish an internet failure from a POS-service failure.
• We know which devices and payment methods work in each situation.
• We have enabled and tested the required settings in advance.
• We have a sensible maximum offline transaction value.
• Staff know who carries the risk of a later decline.
• Staff know which device actions can lose pending transactions.
• We have a manual record for sales the system cannot safely capture.
• We have a rule for scarce stock and online collection promises.
• We know how orders and inventory behave while disconnected.
• We know how to upload, reconcile, and investigate exceptions.
• One named person owns the incident until payments, orders, and stock agree.
• We test the plan periodically rather than waiting for a real outage.

If several answers are unclear, the system may have offline features but the business is not offline-ready.

Where EzyCarto fits

Our view at EzyCarto is that retail software should be judged by the operating truth it preserves, not only by the feature name on a pricing page.

Checkout, orders, inventory movements, and reporting are connected responsibilities. When one part is interrupted, the system and the operating procedure should make it possible to understand what happened and restore a trustworthy record.

That principle is shaping how we think about EzyCarto: make everyday retail workflows clearer, keep important handoffs visible, and help smaller operators ask the practical questions before complexity appears at the till.

This article does not claim that EzyCarto currently processes offline card payments. It gives retailers a framework for evaluating continuity honestly, including the limits that every provider should explain.

The buying rule

Do not buy "offline mode."

Buy a recovery process that your staff can understand and your business can afford to trust.

The useful question is not whether the till can remain open for another transaction. It is whether the business can later prove what was sold, what was paid, what stock moved, what failed, and what still needs attention.

Test that process before signing the contract. Write it down before the outage. Rehearse it before a busy Saturday makes the decision for you.

Sources

• [Square: Process offline payments](https://squareup.com/help/us/en/article/7777-process-card-payments-with-offline-mode)
• [Shopify: POS offline features](https://help.shopify.com/en/manual/sell-in-person/shopify-pos/selling-offline/offline-features)
• [Lightspeed Retail X-Series: Selling in offline mode](https://x-series-support.lightspeedhq.com/hc/en-us/articles/25534272395163-Selling-in-offline-mode)
• [Reddit: What kind of POS software do electronics stores actually use?](https://www.reddit.com/r/smallbusiness/comments/1q3oeox/what_kind_of_pos_software_do_electronics_stores/)
• [Reddit: Outage backup plans?](https://www.reddit.com/r/shopify/comments/1rs2fq3/outage_backup_plans/)

Provider capabilities, regional availability, supported hardware, and time limits can change. Verify the current documentation and your exact configuration before relying on any offline payment or recovery feature.

CTA

Use this checkout continuity checklist in your next POS trial. Ask the vendor to demonstrate the outage, the limits, the reconnection, and the final reconciliation, not only the happy-path sale.