Offline and Sync Considerations for Laravel POS Systems

The golden rule of retail technology is simple: The cashier must always be able to take the customer's money. If the store's internet connection drops, a cloud-only Point of Sale system becomes an expensive paperweight. Customers will abandon their carts, and revenue will be lost.

Building a custom POS with Laravel requires shifting from a traditional request/response model to an offline-first architecture. The Laravel backend becomes the central source of truth, but the frontend must be capable of running entirely on its own.

1. The Offline-First Frontend

Your POS interface (whether built in React, Vue, or as an Electron desktop app) must load its critical data into local storage before the internet drops. When the cashier opens the register in the morning, the app fetches the daily product catalog, pricing rules, and tax rates, storing them in the browser's IndexedDB.

When a barcode is scanned, the frontend queries IndexedDB, not the Laravel API. This ensures the scan is instantaneous (sub-50ms) and works perfectly whether the store has gigabit fiber or zero connectivity.

2. Queuing Offline Transactions

When a transaction is completed offline, it cannot be sent to the server immediately. Instead, the frontend generates a unique UUID for the order and pushes it into a local "Sync Queue" in IndexedDB.

The Background Sync Process

The POS frontend constantly monitors the navigator.onLine status and occasionally pings a lightweight /api/health endpoint on your Laravel server. Once connectivity is restored, a background worker in the frontend silently begins flushing the Sync Queue. It sends the offline orders to a bulk Laravel endpoint (e.g., POST /api/orders/sync).

3. Handling Sync Conflicts in Laravel

When Laravel receives a batch of offline orders, it must process them carefully. Because the orders happened in the past, inventory levels might have changed in the meantime.

Laravel must accept the offline order as truth. Even if the system thinks an item was out of stock, if the cashier physically sold it offline, it was sold. The Laravel backend should process the inventory_movements, driving the stock negative if necessary, and flag the discrepancy for the warehouse manager to investigate.

Idempotency is crucial here. If the Wi-Fi is spotty, the frontend might accidentally send the same batch of offline orders twice. Laravel must check the order UUIDs against the database. If an order UUID already exists, Laravel simply returns a 200 OK without duplicating the transaction.

4. What Cannot Work Offline?

While cash transactions and inventory deductions can happen offline, some features inherently require a network connection:

• Live Credit Card Processing: Unless your payment terminal supports "Store and Forward" (where the terminal itself holds the encrypted card data until it reconnects), credit card processing will fail offline.
• Real-Time Global Inventory Check: A cashier cannot check if another store has an item in stock if they have no internet.
• Gift Card Balances: You cannot securely verify or deduct a gift card balance offline without risking double-spending.

Conclusion

An offline-first Laravel POS is a complex distributed system. It requires local databases, background sync workers, and a backend that gracefully handles delayed, out-of-order data. If you need a POS that survives internet outages, check out my full-stack development services.