When the internet drops during checkout, the safest response is not automatically “stop taking cards” or “keep swiping.” The right response depends on whether your exact point-of-sale system, reader, account, payment type, and location were prepared for vendor-supported offline payments before the outage.
The problem: checkout looks simple, but several systems are involved
A sale can fail because the building lost internet, the local network is overloaded, the terminal lost power, the payment provider has a service incident, or only one reader has a cable or Wi-Fi problem. These failures can look alike at the register, yet they call for different actions. A working phone on cellular data does not prove the POS can safely use that hotspot, and a lit terminal does not prove it can reach the processor.
Supported offline mode is a controlled vendor feature, not a homemade workaround. Square says its supported POS apps can store offline payments in the app and process them after reconnection, subject to device, payment-type, time, and risk restrictions.[2] Stripe Terminal similarly stores payments locally on a POS device or smart reader and forwards them when a connection returns.[3] Neither description means a transaction was issuer-approved at the counter.
The business therefore has two jobs at once: keep legitimate sales moving when its approved setup allows that, and cap the financial and operational exposure created by delayed authorization. The plan must also preserve pending transactions. Deleting an app, clearing its storage, signing out, switching locations, or factory-resetting hardware can destroy records that have not yet reached the processor, depending on the platform.[2][1]
Who is affected—and what may not be affected?
Likely affected
- Card terminals that depend on the failed office internet path
- Cloud-based product, customer, inventory, tax, scheduling, or receipt features
- Online orders that normally appear in the register
- Gift cards, wallet types, loyalty tools, refunds, and manual card entry that the vendor excludes offline
- VoIP phones, cloud accounting, and other services sharing the same outage
May still work
- Cash, with a written receipt and later reconciliation
- Supported offline card acceptance already enabled on an eligible device
- A terminal using a tested, vendor-approved secondary connection
- Local functions whose data is already cached on the POS
- A separate device or site that uses an independent working connection
“May” is important. Square’s current support page, for example, excludes manually entered cards, Square Gift Cards, Cash App Pay, Afterpay, some Tap to Pay configurations, and certain hardware or app modes from offline payments.[2] Stripe lists supported reader categories and payment methods separately and says swiping is not allowed in offline mode.[3] Your contract, software version, country, hardware, acquiring rules, and custom integration can change what applies. Confirm your own provider documentation rather than borrowing another merchant’s checklist.
Step-by-step fix: the first 15 minutes of an outage
Pause the line and preserve evidence
Tell staff to stop repeated attempts while one person records the time, terminal message, network icon, provider banner, and which registers are affected. Photograph status screens without capturing card details, customer names, passwords, or other private information. Do not unplug random cables or erase errors with a factory reset.
Separate one-register trouble from a wider outage
Check another approved register, a wired workstation, and a normal website. From a phone using cellular data—not office Wi-Fi—check the ISP and payment provider status pages. If local printers and other wired devices also fail, the problem may be the local network rather than the ISP. An accidental Ethernet loop can make an office appear offline even when the modem is healthy; preserve the topology and isolate carefully instead of resetting everything. See our Ethernet loop troubleshooting guide.
Read the POS status, not just the customer-facing screen
Confirm whether the application explicitly says it is offline, whether offline acceptance is enabled, and whether the transaction will be marked pending. Square says its supported app retries a network-failed payment and can enter offline mode automatically; pending transactions then appear as “pending” until uploaded.[2] If your system does not clearly identify a supported offline state, switch to your documented fallback rather than experimenting.
Apply the preapproved risk limit
Use the lower of your provider’s limits and your own written policy. Consider a per-transaction cap, a total pending-dollar cap, restricted item categories, customer-facing disclosure, and manager approval. Stripe recommends reconnecting promptly, limiting transactions above a chosen amount, and stopping offline acceptance when the stored total crosses a chosen threshold.[1] A business selling a $12 lunch has a different exposure from one releasing a $2,000 laptop.
Use only the supported card-present flow
Let the approved reader prompt the customer to insert or tap as permitted. Do not copy card numbers into notes, spreadsheets, email, text messages, paper forms, or an improvised website. Do not key the card into a personal phone because the terminal is down. If a payment type is unsupported offline, offer cash, hold the item, issue a non-payment reservation, or ask the customer to return after service resumes.
Protect the device holding pending transactions
Assign one employee to each affected register. Keep it powered and physically secure. Do not sign out, delete or reinstall the app, clear its cache or data, switch locations or operating modes, or reset the device unless the vendor explicitly directs it and confirms the pending records are safe. Square warns that several of these actions can permanently lose pending offline payments; Stripe warns that reinstalling the app or clearing SDK disk storage can lose stored payments not yet forwarded.[2][1]
Restore an approved connection and watch the upload
Use the normal internet path or a backup connection that was tested with this payment setup. Our backup-internet plan explains why a phone hotspot is not automatically an approved terminal connection. When connectivity returns, keep the POS open and powered, watch its pending count, and allow forwarding to finish. Square recommends uploading within 24 hours and documents hard expiration behavior for pending payments after 72 hours in covered configurations.[2] Follow your provider’s current timer, not a number remembered from another platform.
Reconcile every result before declaring recovery
Compare the POS pending log, completed payments, declines, order numbers, cash receipts, and provider dashboard. Do not treat “internet restored” as “all sales approved.” Square says completed and declined results become viewable after reconnection; Stripe’s integration guidance describes callbacks and identifiers for reconciling forwarded payments.[2][1] Escalate missing, duplicated, failed, or expired items through the processor’s official support channel.
Cautions: good continuity plan versus costly improvisation
Phone readers: swipe the table left to see the full “Why it matters” column.
| Good practice | Bad practice | Why it matters |
|---|---|---|
| Enable and test supported offline mode before an outage. | Look for an “offline” switch while customers wait. | Eligibility, cached configuration, device pairing, and staff permissions may need online preparation. |
| Set a modest transaction and total-pending cap based on loss tolerance. | Accept every amount because the reader displayed success. | Collection is not authorization; later declines are the merchant’s risk. |
| Keep pending-payment devices powered, signed in, secured, and unchanged. | Reinstall, clear data, change location, or factory-reset. | The only stored copy may be on that device until forwarding completes. |
| Use a tested provider-approved backup network. | Move card data into email, notes, a personal app, or a homemade form. | An outage does not suspend payment-security obligations or vendor rules. |
| Reconcile completed, declined, cash, and pending sales by order number. | Assume all queued payments cleared when Wi-Fi returned. | Declines, duplicates, missing orders, or expired records need follow-up. |
Build the plan while the internet is working
1. Inventory the exact checkout path
Record the POS app and version, terminal model and serial number, connection type, location assignment, payment provider, merchant support number, status page, and account owner. Note which functions depend on cloud access: taxes, inventory, customer lookup, tipping, gift cards, loyalty, receipts, online orders, refunds, and end-of-day reporting. This prevents “card worked” from being mistaken for “the whole checkout worked.”
2. Decide what you will sell offline
Write a policy that ordinary staff can apply without guessing. Include maximum transaction amount, maximum cumulative pending amount per device or location, excluded high-resale items, acceptable payment types, manager escalation, receipt language, and the point at which the business changes to cash-only or pauses sales. Base the limits on what the business can afford to lose, because Square and Stripe both place decline-related risk on the merchant for offline transactions.[2][1]
3. Prepare power and connectivity together
A cellular gateway cannot help a dead terminal, switch, firewall, or modem power supply. Put the required network path and critical register on a correctly sized, tested battery backup. Then test a genuinely separate connection. A second service can share the same utility power, building conduit, or upstream carrier; a cellular link can also become congested during a regional outage. Keep guest Wi-Fi, cloud backup, camera uploads, and large updates off the limited backup path. If your phones share the outage, use our VoIP outage and 911 plan so customers can still reach you.
4. Run a controlled test sale and recovery
Schedule the drill during a quiet period with the account owner and processor’s test method. Confirm offline status, process only an approved test transaction, document how it appears locally, restore connectivity, verify forwarding, and reconcile the final status. Do not create a real outage test by disabling security controls, clearing data, or pulling unknown rack cables. Repeat after POS, reader, network, processor, or location changes.
5. Print a one-page register card
Include the five essential decisions: who declares the outage, which devices may accept offline payments, the amount limits, prohibited reset/data-clearing actions, and who confirms every queued payment after recovery. Store support numbers from known contracts or official sites. Outage pressure attracts fake “support” calls, so employees should never disclose codes, install remote-access software, or follow an unsolicited link.
Three realistic checkout examples
Café with low-ticket sales
The owner has enabled supported offline mode on two eligible terminals, tested forwarding, and capped both individual and total pending amounts. Staff continue small card-present purchases, stop gift cards and manual entry, keep the terminals powered, and reconcile the queue as soon as service returns.
Repair shop with a large invoice
A customer wants to collect a repaired computer and pay a four-figure balance. The amount exceeds the written offline limit. The shop keeps the device secured, offers cash or an approved later-payment arrangement, and does not release the computer merely because the terminal can collect an offline card.
Bad recovery
A register shows pending payments, so an employee deletes and reinstalls the app to “fix Wi-Fi.” The local records disappear before they reach the processor. Another employee accepts the same customers again, creating uncertainty and possible duplicates. The safer response was to preserve the device, restore an approved connection, and reconcile through official support.
Related guides from The IT Guys
- Build and test a backup-internet plan before your ISP goes down
- Build a VoIP outage and 911 plan
- Find an Ethernet loop before resetting the router
Frequently asked questions
Does “approved” on the offline reader mean the issuer authorized the card?
No. Stripe explicitly says authorization is attempted after connectivity returns and the stored payment is forwarded.[1] Treat the local success state as collected or pending unless your provider’s documentation says otherwise.
Can we write down card numbers and enter them later?
No. This guide does not provide card-storage or delayed-manual-entry instructions. Use only your processor’s supported card-present workflow. Offer a documented non-card fallback if that workflow is unavailable.
Can I connect the terminal to my phone hotspot?
Only when the terminal provider, your security policy, the device, and the cellular plan support that exact connection. Test it before an outage. A personal hotspot should not bypass the business firewall or become an improvised path for unapproved devices.
Should we reboot the terminal?
Follow the platform’s instructions. Stripe’s overview says its SDK can resume forwarding after a reboot when reinitialized, while Square allows powering off but warns against sign-out, app deletion, location or mode switching, and factory reset with pending payments.[3][2] When uncertain, preserve power and call official support.
Can refunds be processed while the original payment is pending?
Not necessarily. Square says an offline payment cannot be canceled or refunded while it is still processing; the refund can be issued after upload.[2] Check your processor’s current rule.
How often should we test?
Test after a material change and on a recurring schedule matched to your sales volume and downtime risk. Quarterly is a practical starting point for many small businesses, but processor requirements and higher-risk operations may justify more frequent checks.
Sources
- Stripe Documentation: Collect card payments while offline
- Square Support Center: Process offline payments
- Stripe Documentation: Accept offline payments overview
Vendor features, limits, supported devices, and menus can change. Verify the current rules for your processor, account, integration, country, and hardware before relying on offline mode.
Turn one checkout into a tested continuity path
Choose one register, one approved backup connection, one small test transaction, and one person responsible for reconciliation. If any step depends on memory or improvisation, document it before the next outage.