Internet outage, local failure, payment and recovery evidence
Offline POS software: test every failure before the counter depends on it
Offline is not one switch. Test the exact internet, LAN, provider, local-service, device, power and recovery failures that can stop a real counter.
Evidence boundary
Reviewed 17 August 2026. Posnic evidence is pinned to stable release v1.3.0, source commit b531ef4 and the exact Windows x64 portable artifact recorded below.
The reproduced run blocked external hosts inside Electron while localhost remained available. It did not disconnect Windows, a network adapter, router or cable; execute a full shift; interrupt power; connect physical hardware; authorize a card; or test macOS, Linux or multiple tills. Those limits define what the result means.
Offline POS is six different failure questions
A useful claim names the failure, task and recovery result. A till can pass one row and fail another.
| Failure class | What may still work | What must be tested |
|---|---|---|
| External internet outage | A local database and API can remain available for local tasks. | Login, item lookup, cash sale, return, receipt, close and restart; then updates, messaging, dashboards and sync separately. |
| LAN or router outage | A single self-contained till may remain usable when its own processes and attached USB devices are local. | Other tills, network printers, payment devices, shared databases, DNS and duplicate reconciliation after the LAN returns. |
| Provider outage | The POS can still record an allowed local or cash transaction. | The exact acquirer, terminal, gateway, tax, messaging or ordering provider's fallback, expiry, duplicate, decline and later-reconciliation rules. |
| Local API or database failure | Internet availability does not repair a stopped local dependency. | Health indicators, restart order, corruption response, log capture, safe retry and whether an interrupted sale can duplicate or disappear. |
| Till, disk or power failure | Another prepared machine or approved manual process may preserve service. | UPS behavior, clean shutdown, spare hardware, installer access, credentials, backup age, restore duration and the stop/go authority. |
| Cyber incident or unsafe state | The safest action may be to isolate or stop the affected system. | Incident contacts, clean rebuild, offline encrypted backup, credential rotation, evidence preservation and validation before reconnecting. |
What the Posnic v1.3.0 run actually established
| Evidence item | Recorded result | Do not infer |
|---|---|---|
| Artifact identity | Windows x64 portable EXE; 166,461,732 bytes; SHA-256 606be5f1e7f05d3fc5db28f9ec54301f097435d056cbd4e887244e3668831e4b; matched the stable manifest. | A later release, installer package, macOS build or Linux build has the same behavior. |
| Isolation | Chromium host resolution mapped external hosts to not-found while localhost and 127.0.0.1 stayed available. | The Windows network adapter, router, DNS service, LAN or physical cable was disconnected. |
| Local path | Local API returned HTTP 200 before and after the workflow while an external HTTPS probe remained blocked. | Every local endpoint, background task, report, integration or long-running shift was exercised. |
| Sale result | Setup, login, item creation, one INR 125 cash sale and reopening stored sale S-O2MA-000001 completed. | Card authorization, KOT, returns, shift close, physical printing or all tax and discount paths were accepted. |
| Environment | Windows NT 10.0.26200.0 x64, Electron 43.2.0 and Chromium 150.0.7871.129 in a disposable profile. | Customer hardware, production data, another operating system or an older Windows build will match the result. |
| Recovery evidence | A separate synthetic restore recovered 20 collections and 53 documents and removed a known post-backup mutation. | A production backup schedule, off-site copy, ransomware recovery or promised recovery time has been proven. |
How the local Posnic runtime changes the outage boundary
Architecture tells you where to inject failure. It does not replace the drill.
Database on the till
The desktop architecture runs MongoDB as a supervised local process. This removes a remote database from the ordinary local sale path, but a disk, process, permission or local-credential failure can still stop it.
API in the Electron process
The Express API runs inside the Electron main process and shares its lifetime. Closing or crashing that process stops the API even when the internet is healthy.
Local derived ports
The application derives and persists local database and API ports. Firewall, endpoint-security or conflicting-installation behavior belongs in the target-machine test.
Optional sync agent
Cloud sync is a separate optional path. A local transaction and its later cloud reconciliation are two different acceptance results; duplicates, ordering and unresolved errors need evidence.
Network exceptions
The privacy document says update checks contact GitHub, MongoDB can be downloaded on first run when not bundled, and configured integrations contact provider accounts chosen by the operator.
Single-machine evidence
The reproduced result used one till. Do not extend it to a multi-till or shared-device topology until each host, LAN and recovery dependency has been mapped and interrupted.
Payment continuity is a separate provider decision
A POS can remain open while a payment route is unavailable. Record the sale path and payment path independently.
| Question | Evidence required | Reason |
|---|---|---|
| Is offline authorization permitted? | Written terminal, acquirer, payment-brand and merchant-account rules for the exact device and transaction type. | Offline capability, limits, risk allocation and upload deadlines are provider-specific; a local POS claim cannot answer them. |
| What can be stored before authorization? | Provider-approved design and current PCI scope for the device and application. | PCI SSC notes that payment terminals are in the cardholder-data environment and must be configured and managed for the applicable requirements. |
| What must never remain after authorization? | A test showing prohibited sensitive authentication data is not retained, including on failure and retry paths. | PCI DSS prohibits retaining sensitive authentication data after authorization even when encrypted. |
| How are duplicates prevented? | Stable order reference, retry behavior, terminal and POS records, later upload result and exception workflow. | A timeout can leave the operator unsure whether authorization occurred; blind retry can charge twice. |
| What is the fallback? | Approved cash, alternate terminal, manual or stop-sale procedure with staff authority and customer communication. | Availability does not justify bypassing provider rules, data controls or the business's accepted risk. |
| How is the day reconciled? | POS sales, terminal batch, provider settlement and exception totals after connectivity returns. | A completed local sale is not proof that funds were authorized, captured or settled. |
Posnic's reproduced offline sale used cash and no physical payment terminal. This section is an acceptance method, not a claim that Posnic provides offline card authorization or a PCI compliance determination.
Run a 12-record outage and recovery drill
Start with synthetic data on the real target equipment. Keep the exact failure, observed behavior and recovery evidence instead of a single pass label.
| Record | Exercise | Evidence to retain |
|---|---|---|
| 1. Scope | Pin the release, file hash, operating system, database, network map, tills, devices, providers and test data. | Versioned topology, owners and excluded paths. |
| 2. Healthy baseline | Start, sign in, sell, print, retrieve the sale and record local and external health before failure. | Timings, sale reference, receipt and health results. |
| 3. Internet loss | Interrupt the real WAN path during item lookup, cash sale, return, report and close tasks. | Completed and blocked tasks, messages and stored records. |
| 4. Payment path | Apply the provider-approved failure scenario without using live customer data or bypassing rules. | Terminal, POS and provider references plus the final outcome. |
| 5. LAN and devices | Interrupt router or LAN access and reconnect each network printer, terminal and peer till. | Device state, retries, queue behavior and failures. |
| 6. Local service | Stop or make unavailable the local API or database using an approved disposable environment. | User-visible response, logs, restart order and data result. |
| 7. Application restart | Close and reopen the till while the external outage remains active. | Startup result, login, unsynced work and prior sale lookup. |
| 8. Power and machine | Exercise the approved UPS, shutdown and replacement-machine procedure without risking production data. | Shutdown result, spare readiness and elapsed time. |
| 9. Backup and restore | Restore an off-device backup into a separate clean profile or replacement machine. | Backup hash and age, duration, counts and reconciled samples. |
| 10. Reconnection | Restore each network path and wait for configured queues or sync processes to settle. | Queue states, errors, duplicates and unresolved records. |
| 11. Reconciliation | Compare sales, payments, receipts, stock, returns, close totals and provider settlement. | Before/after totals and every explained variance. |
| 12. Decision | Assign corrective actions, retest dates, fallback owners and stop/go approval. | Named owner, due date, residual risk and signed decision. |
Offline selling still needs recovery objectives
The counter may survive a WAN outage and still lose records to disk failure, theft, ransomware or an unusable backup.
Define maximum data loss
Set the recovery point objective in business terms: the largest accepted gap between the latest usable copy and failure. The default schedule is not proof that a backup ran while the app or till was off.
Define recovery time
Set the recovery time objective for restoring an accepted counter service. Measure installer access, replacement hardware, database start, restore, login, devices and post-restore reconciliation.
Keep another copy
The default local backup folder is on the same disk. CISA recommends offline encrypted backups and regular availability and integrity tests because reachable backups can be deleted or encrypted.
Exercise the plan
NIST contingency guidance separates impact analysis, preventive controls, recovery strategies, plan development, training, exercises and maintenance. A checkbox that says backup enabled covers only part of that work.
Preserve trusted software
Keep the verified installer, checksum and required configuration with recovery records. Rebuilding can fail if the release, dependencies or device drivers are unavailable during an incident.
Reconcile after restore
A successful restore call is not the end. Verify users, settings, products, customers, sales, payments, stock, reports, exports and required devices before reopening.
Inspect the evidence you will reproduce
Primary sources used
Pinned Posnic architecture
Pinned Posnic privacy
Pinned backup policy
NIST SP 800-34 Rev. 1
CISA StopRansomware Guide
PCI Security Standards Council
Payment terminal scope and sensitive authentication data limits.
Continue the acceptance work
Use the detailed guides for the physical outage and restore procedure, then retain a written implementation boundary for any work Posnic is expected to perform.
Offline POS questions
Does offline POS software mean the till never needs internet?
No. Offline behavior is task-specific. Local cash sales may continue while card authorization, cloud sync, remote dashboards, messaging, support and updates still need a network. Test each required task during the exact outage the shop could face.
What offline behavior has Posnic actually reproduced?
On the pinned Windows v1.3.0 portable build, Posnic completed local setup, login, item creation, one INR 125 cash sale and stored-sale lookup while external hosts were blocked inside Electron. It was not an operating-system disconnect, router outage, full shift, power-loss or payment-terminal test.
Can card payments work when the internet is down?
That depends on the exact terminal, acquirer, payment application and merchant agreement. Posnic's local cash-sale test did not connect a payment terminal. Obtain the provider's written offline rules and test duplicate, expiry, decline and reconciliation behavior without storing prohibited authentication data.
What happens when the POS computer or local database fails?
A local architecture does not protect against till, disk, operating-system, API or database failure. The business needs a spare or replacement path, off-device backups, a measured restore and an approved temporary process. Posnic's synthetic restore result is evidence for one small test profile, not a recovery-time promise.
Will multiple tills keep working if the router or LAN fails?
Do not infer that from a one-machine internet-outage result. Multi-till behavior depends on where each database, API, printer, payment terminal and sync service runs. Inject the real LAN and host failures and reconcile every device after recovery.
How often should a shop run an offline POS drill?
Run it before go-live, after material changes to software, hardware, network, payments or recovery procedures, and on a recurring schedule set by the business risk owner. Keep the injected failure, results, evidence, recovery time and unresolved actions.