Insights · 2026-09-04
What to do when a payment terminal doesn't answer: a queue instead of a guess
When a remote payment result is unknown, there are two easy but wrong defaults — treat it as success, or treat it as failure. The rental operations system picked a third option.
The problem
The rental operations system takes payment through card terminals on site. Like any networked device, a terminal has a failure mode where a payment request is sent but no response comes back: the network drops, the device restarts, the reply is lost on the way back.
Why both 'easy' defaults are risky
Defaulting to success in that situation can hand out equipment against a payment that never actually went through — a direct loss. Defaulting to failure can deny service, or trigger a duplicate charge attempt, to a customer who did in fact pay. Both options try to guess an outcome the system genuinely does not know yet.
The decision
An undetermined result does not resolve the operation as either success or failure — it moves it into a separate manual-review queue. Staff see these operations apart from the normal flow and confirm or reject them after checking, rather than by default.
A related case is handled alongside it: if the payment service is unavailable entirely, a location has a cash-free fallback flow for issuing equipment — an external outage does not stop service on site.
Separately from result uncertainty, there is protection against concurrent payments on one terminal: a new sale on a device is blocked while it already has an operation in progress, so two payments cannot overlap and confuse the till totals.
Why it matters
A manual-review queue is not a sign that the automation is unfinished. It's a deliberate split: what the system genuinely knows is handled automatically; what it does not know goes to a person instead of being guessed away for convenience.