Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Build an offline-first point-of-sale PWA by separating five jobs: loading the app shell, keeping a usable catalog on the device, recording sales locally, syncing queued operations safely, and handling card authorization through a payment provider’s supported offline flow. Use a service worker for app resources and network behavior, and IndexedDB for structured sales and durable sync state. Neither one, by itself, makes a card payment authorized offline.
The key design rule is to show a sale as saved only after its IndexedDB transaction commits. Then treat server sync and payment as separate outcomes, each with a status the cashier can understand.
What “offline” needs to mean in a POS
A POS can be partially offline while still being unable to complete a sale. Decide which capabilities the store needs, and model their status separately:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- App available: the POS interface can open without a network connection.
- Catalog available: the device has usable product, price, tax, and configuration data.
- Sale recorded: the device has durably stored the order and its line items.
- Order synced: the server has accepted the order or returned a definitive error.
- Payment resolved: the selected payment method has an outcome, such as paid, declined, pending, or requiring reconciliation.
These are not interchangeable states. An order stored on a device is not necessarily on the server, and a queued payment request is not an authorized payment.
#1 Best Overall
- Android 14 Performance: The Multzo POS H10 handheld terminal is powered by Android 14 and an Octa-Core processor, allowing you to run compatible business applications. The integrated 720x1440 touchscreen display provides clear, sharp visuals for quick and intuitive navigation during daily operations.
- Ink-Free Thermal Printing: Features an integrated 58mm direct thermal receipt printer that produces clear monochrome prints without the need for ink cartridges. Designed to fit standard 58mm thermal paper rolls, it provides a reliable, cost-effective solution for printing retail receipts and mobile checkouts.
- Contactless Payments & Scanning: Equipped with an integrated NFC reader that supports contactless tap-to-pay payments for streamlined customer checkouts. The built-in 5.0MP rear camera functions as a barcode scanner to quickly and accurately read both 1D and 2D barcodes for inventory and sales.
- All-Day Battery Life: Powered by a built-in 6000mAh battery that delivers up to 14 hours of runtime, making it ideal for mobile retail and food trucks. It supports 10W fast charging to complete a full charge in 2 hours, and a compatible charger is included.
- Seamless Connectivity & SDK: Stay connected anywhere with dual-band Wi-Fi, 4G LTE cellular networks, Bluetooth, and USB connectivity. Weighing 345 grams for comfortable handheld use, this terminal also provides an available SDK for developers to integrate custom software.
Prepare the PWA before the connection drops
A service worker cannot make a first visit work offline: the browser must initially fetch the page and worker while connected. On that visit, register the worker, cache the resources needed to start checkout, and download the store’s required data. The worker is scoped to requests and runs separately from the page; it may be stopped and restarted, so its in-memory variables are not durable storage. web.dev’s service-worker guide explains these first-load and lifecycle constraints.
- Load the POS while online. Confirm that the page is controlled by the registered service worker before relying on its fetch handling.
- Cache the app shell. Precache the minimum files needed to render checkout and an offline navigation fallback. Keep cache rules explicit; do not assume every URL or response should be cached.
- Download operational data. Save the catalog, prices, tax rules, and configuration the store needs for the intended offline period.
- Record freshness. Keep a version or timestamp for the downloaded snapshot and display when it was last updated. The sources do not prescribe a POS-specific catalog schema or freshness threshold, so set those according to the store’s pricing and compliance needs.
- Exercise the offline path. Test a real installed, previously loaded app after removing network access, rather than assuming a successful online load proves the offline experience.
Use the service worker for resources, IndexedDB for sales
Cache Storage is useful for app files and chosen network responses; it should not be the transactional source of truth for sales. Put structured operational records and the durable outgoing queue in IndexedDB. Browser storage shares capacity, and writes can fail; surface quota or transaction errors instead of silently treating them as success. The web.dev offline-data guide describes IndexedDB for structured offline data and identifies transaction completion as the useful signal that a write succeeded.
Microsoft Learn likewise recommends IndexedDB for PWA data, noting that it can be used by both front-end code and a service worker: Store data on the device. Keep durable business state in IndexedDB rather than a worker global, which can disappear when the browser terminates the worker.
Rank #2
- DURABLE POS CASH DRAWER: Volcora cash register drawer measures 13"x13.25"x4", voltage is at 12-24 VDC. Our money drawer has a heavy duty durable metal frame that is an ideal cash register for small businesses and even big establishments too.
- 4 BILL 5 COIN SLOTS: Our small cash register has a built in cash tray that comes with a removable coin tray to maximize the partitions to 4 bill slots and 5 coin slots. The front panel has 1 media compartment for large bills, checks, and receipts storage without opening the drawer.
- SECURED CASHIER REGISTER: Our cash box with money tray and lock is secured with 3-position key lock: 1-manual open, 2-auto open by printer/POS, 3-lock. Perfect as cash registers for business, our package includes 6 keys for additional backup.
- CONNECTIVITY AND COMPATIBILITY: Our cash drawer suits the point of sale system for small business. Just connect the cash drawer to a receipt printer via the RJ11 / RJ12 cable included in the package, and then to your POS to automatically open or close cash trays. Our cash drawers can be used with most major receipt or thermal printer brands. Compatible with Star, Citizen, JAY, and Bixolon. (No USB port, so CANNOT be connected to POS directly via USB)
- 100% LIFETIME GUARANTEE: Contact us if you are not satisfied with our cash drawer tray for checkout counter and we will send you a new replacement.
Keep the local record sufficient to recover
A practical sale record should preserve the order and line items, a stable local order identifier, the cashier and device identifiers, the catalog/configuration version used, and the current sync and payment states. Store a corresponding pending operation in the same read-write transaction as the sale. This is an architecture recommendation, not a POS schema specified by browser documentation.
Only tell the cashier “saved on this device” after the transaction’s completion signal. If the write aborts or quota is exhausted, show that the sale was not safely recorded and give staff a defined recovery path; a rendered confirmation before commit can create a false impression of durability.
Record checkout locally, then sync the order
Validate checkout against the data available on the device, commit the order and its pending operation together, and only then show local success. Once connectivity is available, deliver pending operations to the server in a deliberate order. Preserve each operation until the app records a definitive server outcome.
Rank #3
- ALL-IN-ONE DESIGN: The POS STORE Q2i Mobile POS Terminal combines a 5.5-inch HD capacitive touchscreen with an integrated 58 mm thermal receipt printer. The monochrome thermal printer prints at speeds up to 80 mm per second on standard 58 mm thermal paper, eliminating the need for ink. This single handheld device streamlines payment and receipt processing.
- INTEGRATED 1D BARCODE SCANNER: Features a built-in camera scanner designed to read standard 1D barcodes, including UPC, EAN, and Code 128. This enables quick scanning directly on the retail floor or tableside. Please note that the built-in scanner is designed for 1D barcodes and does not read QR codes.
- ANDROID 11 & POS SOFTWARE COMPATIBILITY: Running on the Android 11 operating system with Google Play Store access, this device supports popular point-of-sale applications. It is compatible with systems including Loyverse, Square, Helcim, KORONA POS, and Stripe Terminal to easily manage your transactions and inventory.
- WIRELESS CONNECTIVITY & WORKDAY POWER: Stay connected using dual-band Wi-Fi (supporting 2.4 GHz and 5 GHz networks) and Bluetooth. Equipped with a rechargeable 7.4V / 5000mAh lithium battery and a USB-C port, this mobile terminal is built to keep your business running smoothly.
- COMPLETE RETAIL KIT: The package includes the Q2i terminal, a power adapter, a USB-C cable, a paper roll, and a quick start guide. Measuring 2.03 x 3.4 x 8.2 inches and weighing 364 grams, this compact terminal is easy to carry and comes backed by a 1-year seller warranty.
- Validate locally. Use the downloaded catalog and configuration, and make their version or age available to the cashier when it matters.
- Create a stable operation identity. Give each logical sale a unique ID that remains unchanged across retries.
- Commit sale plus queue entry. Write the order, items, and pending-sync operation in one IndexedDB read-write transaction.
- Show the correct state. Distinguish “saved on this device” and “awaiting server” from “server accepted.” Use separate payment states such as “payment pending,” “paid,” and “needs reconciliation.”
- Replay and reconcile. On a definitive server response, persist the outcome and update the visible order state. Keep unresolved operations available for retry or staff review.
A timeout is ambiguous: the server may have committed the request even though the device did not receive the response. Retrying without duplicate protection can create a second effect. Stripe documents idempotency keys as a way to retry its API requests after connection errors without performing the operation twice; that behavior is provider-specific, so confirm the equivalent guarantee with the server or payment API you use. Stripe API: Idempotent requests.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Choose a replay strategy that matches the POS lifecycle
Background Sync can retry queued requests when the browser signals connectivity, but it is an opportunity to deliver work, not a guarantee of immediate delivery. Workbox Background Sync stores failed requests in IndexedDB and retries on a sync event where supported. Where native Background Sync is absent, Workbox’s documented fallback attempts replay when the service worker starts; that depends on a controlled page starting the worker. Chrome for Developers’ Workbox Background Sync documentation describes both behaviors.
| Approach | Delivery behavior | Lifecycle dependency | Retry control and trade-off |
|---|---|---|---|
| Workbox Background Sync | Queues failed requests in IndexedDB and retries on a sync event when available. | Its fallback when native support is unavailable runs when the service worker starts, which depends on a controlled page starting it. | Convenient for replay, but define the queue’s retryable failures and permanent-error handling explicitly. Source: Chrome for Developers. |
| App-managed foreground replay | The app can submit pending operations while it is running and connected. | Requires the POS page to be open and able to run its replay logic. | Gives the application direct control over ordering, visibility, and handling; it does not provide delivery while the app is closed. Source context: Workbox’s documented fallback depends on worker startup. |
Whichever strategy you choose, decide which failures merit retry, how often to retry, how long an item remains eligible, and what happens to an item that cannot succeed. Workbox’s default failure handling catches network exceptions; an HTTP response such as 4xx or 5xx does not automatically count as a fetch failure unless the strategy turns selected responses into exceptions. Avoid retrying permanent validation or authorization failures indefinitely. Retain them for a visible cashier or manager reconciliation path instead of dropping them.
Rank #4
- Responsive 15.6-inch touchscreen display supports resolutions up to 1920 x 1080, providing a clear and direct interface to streamline order entry, improve checkout accuracy, and speed up daily transactions.
- Powered by an Intel Core i5 5th Gen processor and preinstalled with the Windows 11 operating system. Equipped with 8GB RAM and a 128GB SSD, this all-in-one terminal delivers reliable processing speeds for running demanding point-of-sale applications.
- Built with a durable aluminum alloy housing designed to withstand busy commercial environments. The unit features a space-saving 45 x 36 x 13 cm footprint, allowing it to fit neatly onto crowded checkout counters.
- Equipped with physical USB, serial, Ethernet, and VGA ports, plus built-in Wi-Fi and Bluetooth to connect receipt printers and other accessories. This hardware-only terminal is compatible with Windows-compatible POS software and comes with a 1-year manufacturer warranty.
Keep card authorization separate from order synchronization
A PWA can record an order while offline without having authorization for the card transaction. Offline card-present collection depends on the chosen processor, reader, payment method, device, region, and the provider’s reconciliation and risk rules. Verify the exact flow before describing a card sale as paid.
| Payment path | What it establishes | What to verify |
|---|---|---|
| Online authorization | The payment provider handles authorization while the reader and service can reach the provider. | Confirm that the reader and payment method are supported in the deployment region. Regional requirements vary; see Stripe’s regional considerations for a Stripe-specific example. |
| Provider-supported offline terminal collection | A configured terminal flow may collect transactions while the reader is offline, subject to that provider’s rules; collection is not the same as guaranteed approval or later reconciliation. | For Stripe Terminal, the configuration API exposes an offline.enabled option, which defaults to false. Confirm eligible reader, geography, payment methods, risk limits, and reconciliation behavior in the provider’s documentation: Update a Configuration and Regional considerations. |
Do not put card authorization into the same status as order upload. A server may accept an order while payment remains pending, or payment may require reconciliation after a reader reconnects. Make those outcomes visible and define staff actions for each one.
Test failure and recovery paths, not just the happy path
Test on the target browser, device, reader, and deployment region. Chrome for Developers warns that the DevTools Offline checkbox is not a reliable way to test service-worker requests: page requests may be taken offline while worker requests can still reach the network. Inspect the Workbox IndexedDB queue during queue tests. See Retrying requests when back online.
- After the first online visit and service-worker control, remove real network access; confirm the app opens and the intended catalog is available.
- Record a sale, close and reopen the app or restart the worker, then reconnect and verify that the operation replays and the server result reconciles to the same order.
- Deliver the same operation more than once and confirm the server’s idempotency behavior prevents duplicate effects.
- Exercise network errors, selected 4xx and 5xx responses, and a permanently invalid operation; verify retry, stopping, and staff-review behavior.
- Test out-of-order operations, stale catalog or price data, clock changes, and an item that never succeeds.
- Force or simulate a local write failure and quota problem; verify the UI does not claim the sale was saved.
- Test the payment provider’s offline reader flow separately from order sync, including its supported payment methods and post-reconnect result.
Because a POS affects money and inventory, keep an audit trail and make device-local, server, and payment states distinguishable. Never discard queued sales silently or infer successful reconciliation merely because the browser reports connectivity.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
