Recover a checkout after a payment timeout

01

Preserve the transaction the customer intended to pay

Keep the sale reference, basket version, amount and provider payment reference together before the request leaves the POS. These details let the system investigate the original attempt after a connection problem. A new screen session or restarted terminal should not force the operator to recreate the sale from memory before its payment status can be checked.

Freeze or clearly control changes while the payment result is uncertain. Removing an item from the basket does not change a payment already being processed elsewhere. If the customer wants to alter the purchase, first resolve the existing attempt through the provider’s supported process. The recovery interface should show the amount and the original sale context so a supervisor can distinguish this case from a later, separate transaction.

02

Distinguish a decline from an unknown outcome

A confirmed decline and a communication timeout require different actions. In the first case, the provider has supplied a result. In the second, the application lacks reliable evidence about the outcome. Give these states different labels and instructions. A generic payment failed message encourages the cashier to retry even when the first request may still be active.

Record the last confirmed status, when it was obtained and the source that supplied it. A local timeout should not replace a provider confirmation that arrives afterwards. Where the provider offers status lookup or asynchronous confirmation, design their use according to the actual integration contract. Do not assume all providers expose the same events, timing or cancellation behaviour merely because their terminals look similar at the counter.

03

Check the existing attempt before starting another

The first recovery action should investigate the payment reference already associated with the sale. If the provider confirms success, continue the unfinished downstream work without another charge. If it confirms a result that permits a new attempt, the operator can proceed through the agreed path. If the outcome remains uncertain, keep the case visible and escalate according to the store’s operating procedure.

Use the provider’s documented retry protection where supported, and understand its limits. A request identifier only protects the operation if the receiving interface recognises it under the conditions being used. The implementation must preserve the original parameters and distinguish a retry from a genuinely new payment attempt. Test this behaviour with the payment partner rather than treating an arbitrary local identifier as universal duplicate prevention.

04

Give the cashier a short, usable recovery sequence

The operator should see the customer-facing amount, the current evidence and the next permitted action. Avoid requiring them to interpret raw provider codes during a queue. Retain those details for support, but translate them into a precise operational instruction. If supervisor approval is needed, show who has been asked and whether they have accepted the case.

A recovery checklist can be rehearsed before the integration goes live. It should preserve continuity when another cashier takes over and prevent shortcuts that hide an unresolved transaction. The customer should receive a factual explanation of the check underway, without an unsupported assurance that no money could have moved.

• Find the original sale and its existing payment attempt.
• Check the latest authoritative provider status.
• Keep uncertain outcomes separate from confirmed declines.
• Continue receipt and stock work only through the agreed transition.
• Record any authorised new attempt or subsequent corrective action.

05

Reconcile late confirmations and competing actions

A delayed confirmation may arrive while a supervisor is investigating. The system should update the same payment record and make the new information visible before another action is accepted. If two operators open the same recovery case, show ownership and prevent them from independently starting conflicting operations against the same sale.

Keep a trace of late events, status checks and decisions. An event replay must not create another sale or repeat a completed stock update. Reconcile payment references against sale records regularly so an accepted payment cannot remain indefinitely disconnected from the business transaction. Any corrective financial operation follows the provider’s supported process and the merchant’s authority rules; it should not be an automatic guess based on the age of a timeout.

06

Test failure timing with the actual provider

Rehearse a connection loss before submission, after acceptance and during return of the result. Include delayed confirmation, terminal restart and a handover to another employee. Record the expected operator instruction for each case and confirm it with the payment provider or integration partner. Use their supported test arrangements and approved equipment for the chosen setup.

RDC can implement the sale state, recovery view and connections to provider status, receipt handling and inventory. Scope EU-hosted or company-managed components alongside store connectivity, access, monitoring and retention of transaction references. Keep card collection within the approved provider boundary and assess licence and support requirements explicitly. Measure unresolved outcomes, time to authoritative confirmation and duplicate attempts prevented or investigated. A clear recovery process improves the team’s ability to act on evidence; its value should be assessed with the store’s own operating data.