An offline POS sale should stay one sale
A receipt printed during an outage is not proof the server accepted the sale. Plan the retry before the network returns.
Rootscratch ·
The receipt has already printed. The customer has the bag. Then the store network drops, and that sale is still only on the terminal.
When the line comes back, the terminal uploads again. If the first attempt reached the server and only the reply was lost, a careless retry creates a second sale. Stock moves twice. The shift total stops matching the drawer. A stored card payment can pick up a second attempt as well.
Give the sale an identity on the terminal before it leaves. The server should recognize a repeat of that identity and return the sale it already stored. A new HTTP request ID on each retry does not make it a new sale.
Saved is not the same as accepted
A counter receipt shows that the terminal kept the sale. It does not show that the server accepted it, or that a card issuer approved the payment.
Staff closing a shift should see which sales are still waiting. A reconnect during close should not print those receipts again or add a second tender.
Offline card payments are a provider choice
Not every reader, card or wallet can store a payment and send it later. Stripe Terminal can store some in-person card payments on a supported reader and forward them after connectivity returns. Authorization is attempted only after that forward. Stripe says the merchant assumes the decline and tamper risk: if the reader cannot forward the payment, or the issuer declines it, there may be no way to recover the funds after the goods have already been handed over. Stripe also documents an offline maximum of US$10,000, or the equivalent in the operating currency. An offline PaymentIntent may not yet have a Stripe ID, so the sale needs an identifier of your own. Those limits are in Stripe's offline card-payment guide.
Decide which tenders may proceed offline, which amounts must wait for a connection, and what the cashier says when approval has not happened yet. Confirm the same points with the provider you actually use. Reader support and card rules are not interchangeable.
Two terminals can sell the last unit
While both terminals are offline, neither can see the other's sale. If one unit is left, both can sell it. When they reconnect, do not delete one sale to make the stock count look right. Keep both records and show the conflict to the person who can correct stock.
Use the price that was on the terminal when the sale was made. A catalog change during the outage should not rewrite a receipt the customer already holds.
Test the lost reply
Drop the network after the terminal has saved a sale, then restore it twice. The server should show one sale. Repeat that with a lost response, a reboot while sales are still queued, and two terminals selling the same last unit. A declined card that was forwarded after reconnect should stay on an exception list, not disappear because the drawer was already closed.
Rootscratch's POS and frontline sales service covers sales, receipts, shift close, and rules for local records and later synchronization. Interrupted payments are on that test list. Bring a sample receipt, the tenders you allow when the network is down, and the way a shift is closed. Payment terminals and fiscal rules still need confirmation for the place you sell. Custom POS software is not automatically a certified fiscal solution.