A payment problem rarely arrives at a convenient time. The first goal is not to guess the cause. It is to keep the team safe, protect payment data, and establish a controlled fallback while someone confirms what has failed.
For a broader systems view, review the ServingIntel integrated operations platform.
That need was visible on June 23, 2026, when The Guardian reported a Worldpay disruption affecting card payments at pubs and shops during a busy England match. Judopay's independent incident record described latency, declines, and failed transactions before service returned to normal thresholds. A separate Worldpay status update on July 9 recorded intermittent connection failures affecting only a small share of transactions—the kind of partial failure that can look random at the counter.
Before the outage: define offline operation
Offline mode is not a universal switch. A POS may behave differently when the internet is down, the local network has failed, a processor is unavailable, or a cloud service is disrupted. Ask which outage types trigger offline operation, which devices and payment methods continue, who can approve a transaction, what limits apply, and how quickly stored payments must upload.
For neutral background and operating context, see National Vulnerability Database.
Do not rely on a manager discovering the settings during an incident. Toast's offline-readiness guidance, updated June 30 , is one vendor-specific example: it tells operators to verify payment settings, permissions, network design, and optional limits while the system is online. Your system may differ, so use its current documentation and support contact.
Related infrastructure planning is available in ServingIntel POS hardware guidance.
Run a controlled readiness check
Schedule a supervised, reversible test. Confirm which terminal holds pending payments, whether kitchen routing stays on the local network, how staff recognize offline status, and where the status page and support number are stored. End with a dated record of devices checked, expected behavior, gaps found, and owners. Never create live transactions or change payment controls without the required approval.
During the outage: narrow the failure
Start with impact, not assumptions. Determine whether one or all terminals are affected; whether orders, drawers, printers, kitchen displays, and online channels still work; whether the provider status page shows an incident; and the exact time and wording of the first error. A partial processor failure may allow some payments and reject others, so one successful attempt does not prove recovery.
A complementary portfolio perspective is available in the POS University continuity drill.
Use one approved customer message
Give the host, counter, servers, and phone team the same short update. Explain available payment options before the guest commits to an order. Do not promise that a pending card payment succeeded, assign blame before the cause is confirmed, invent workarounds, photograph cards, or write card numbers on paper.
Control retries and device changes
Repeated attempts can create confusion about whether a guest was charged. Assign one manager to approve retries, note the time and check number, and preserve the displayed result. Do not sign out, reinstall software, reset hardware, switch locations, or clear data unless current provider guidance directs it. Toast's July 2 offline workflow is product-specific, but its broader lesson applies: changing device state during an outage can complicate recovery or risk unsynchronized data.
Use the following resource when assigning escalation and recovery ownership: ServingIntel support resources.
After service returns: reconcile the recovery
A green status page does not finish the incident. Confirm every device is online and stored orders and payments are uploading. Review pending, declined, duplicated, voided, and delayed transactions using approved reports. Compare POS, processor, and deposit records at the level your finance process permits.
For additional independent reference material, review CISA Known Exploited Vulnerabilities Catalog.
Offline acceptance can shift authorization risk to the merchant. A captured transaction may be declined after the guest leaves, which is why limits, permissions, and follow-up procedures belong in the playbook. Never move card details into notes, spreadsheets, chat, or email.
Turn the incident into a 15-minute review
Within one business day, ask what failed, how the team confirmed it, which parts of service continued, which decision lacked an owner, what remains unresolved, and which single change should be tested before the next busy shift.
For another practical workflow in the portfolio, read the 86 The POS payment questions.
The improvement may be a printed escalation card, status-page alerts, a cellular backup review, clearer offline limits, spare network components, or a quarterly drill. The best response is the one employees can follow under pressure, customers can understand, and managers can reconcile afterward.
For additional restaurant and senior-living technology context, consult ServingIntel News & Insights.