A sale recorded during a connection outage can leave a merchant with an item handed over and a card payment still waiting. Those are two different parts of the same transaction. In Square's US offline-payment guidance, an offline card payment appears as pending until the device reconnects and processing can proceed. A note saying “customer tapped” should therefore not quietly become “funds confirmed.” Consider an invented market seller using a Square Terminal with the supported Square Point of Sale arrangement and offline payments allowed. The example follows the payment's state, not the seller's sales forecast. Its dates, item price and customer are fictional; the processor's stated limits are the facts that constrain the story.
Put the start of the session beside the payment
At 10 a.m. on a fictional Monday, the Terminal begins an offline session. At 10:20 a customer buys a notebook for $18 and presents a card. The app records the offline transaction. On the seller's private event note, three separate entries would be useful: the session began at 10, the item was handed over at 10:20, and the payment is pending. None requires an invented bank-transfer date.
The session start matters because Square's upload limit is measured from that start, rather than giving every later purchase a fresh three-day clock. Its guidance requires Terminal, Register and Handheld users to reconnect and upload within 72 hours, while strongly recommending upload within 24 hours. Pending payments expire after the outer limit and cannot then be retrieved or reprocessed.
For this fictional Monday start, 24 hours later is Tuesday at 10 a.m.; 72 hours later is Thursday at 10 a.m. These are elapsed-hour examples with no clock change assumed. The recommended earlier upload point is not permission to plan an outage until the last minute. The second boundary describes what can be lost, not a convenient extra period in which to ignore the first.
Suppose another notebook is handed over at 4 p.m. Monday. Its later sale time does not move the session's starting point to 4. Keeping the start beside both entries prevents a seller from attaching Thursday afternoon to that second payment simply because it occurred six hours later.
Reconnection is a transition, not a bank balance
In our story, the seller restores the Terminal's connection at 6 p.m. Monday. That is eight hours after the session began, comfortably inside the recommended period. Square says reconnection uploads the payments automatically and makes completed and declined outcomes available. The merchant now has a new piece of information to inspect: what actually happened to the $18 transaction after upload.
One possible ending is a completed payment. Another is a decline. The earlier pending entry cannot tell the seller which ending occurred. The useful revision is to attach the actual outcome to that same transaction, rather than leaving one line in the event notebook and another unrelated line in the app.
For the completed branch, our example stops at the processor result. It supplies no settlement schedule or bank posting. A subsequent transfer and bank match would need their own actual records. For the declined branch, write that result plainly; do not preserve “paid” merely because the customer has already left with the notebook. A tidy stall total is less useful than an honest transaction history.
Square places responsibility for expired, declined and disputed offline payments on the seller. In the example, that makes accepting a pending $18 transaction a business choice before its eventual outcome is known. The seller should decide whether that uncertainty fits the event rather than relying on the customer's departure to make the payment final.
Keep a troubleshooting action from destroying the queue
An impatient response to a frozen-looking status can be to reinstall an app or reset a device. Square specifically warns against signing out, deleting its POS apps, changing modes or locations, or factory-resetting while offline payments are pending: the pending payments can be permanently lost. Treat the unresolved queue as part of the troubleshooting problem, rather than clearing the visible screen and assuming the money has gone somewhere safer.
The event note helps here too. A second person taking over the stall can see “pending offline payments remain” instead of interpreting the absence of a bank entry as a fresh reason to rebuild the setup. That note is an original handover suggestion, not a substitute for Square's current device-specific support instructions.
Keep private customer and account information out of a public stall notice. A customer-facing explanation can identify that the business is using an offline payment process without displaying a transaction list. The internal question is whether the actual device and settings support the process the seller intends to offer.
Read the clock for the hardware actually present
Do not turn the Terminal example into instructions for every reader generation, app or phone payment feature. The hardware name belongs beside the timing note, not in a forgotten equipment receipt. If the stall changes equipment, revisit the actual guidance before reusing the old event note. A familiar logo does not establish an identical operating arrangement.
Before the next event, use the current support page to identify the actual setup and decide whether offline card acceptance fits the business. In the worked story, the useful result is a connected record: session start, pending transaction, reconnection and actual processing outcome. That record can explain a genuine gap without pretending an outage sale was already settled.
Sources & further reading
Published sources for the details and examples discussed in this story.
