Keep self-checkout payment, receipt and stock states aligned

01

Record the basket that enters checkout

Create a stable transaction identity when the customer begins the checkout journey and keep an identifiable basket version for payment. Preserve item quantities, approved adjustments and the total presented to the shopper. This gives the supervisor a concrete record to inspect if the lane restarts or the customer moves to a staffed desk.

Decide when the basket can change and when it must wait for another operation to finish. An item removal during a pending payment cannot simply alter the amount already submitted to the provider. If a supervisor changes the basket, the lane should acknowledge the accepted version before the customer continues. The same transaction reference should connect the lane screen, supervisor request and later reconciliation, rather than creating a separate identity in each component.

02

Use provider evidence for the payment state

The payment provider’s supported interface establishes the financial outcome. Keep its reference and confirmed status with the transaction, and distinguish an unanswered request from a confirmed failure. A timeout on the lane does not prove that the customer was not charged. The interface should explain that a check is underway and call for assistance when the result cannot be established automatically.

Keep payment collection within the approved provider arrangement and avoid placing full card details in the application’s ordinary records. The supervisor should work with the sale amount, provider reference and allowed actions, not sensitive payment information that is irrelevant to recovery. Agree confirmation, lookup and retry behaviour with the selected partner. These capabilities must be verified for the actual integration rather than assumed from another provider’s documentation.

03

Track receipt completion as its own outcome

Identify what confirms the required receipt or fiscal operation in the store’s chosen equipment setup. Preserve that reference separately from the payment confirmation. A successful payment cannot prove that a device produced the required result, just as a local printing message cannot establish the payment outcome. The customer-facing completion screen should be based on the agreed end-to-end conditions.

Work with the authorised equipment supplier to define recovery when a response is uncertain or the device needs attention. Show the supervisor what is already confirmed and which action remains permitted. Do not issue blind repeat commands merely because the customer pressed the help button again. The recovery process must preserve the transaction identity and the equipment’s actual operating constraints, including any step that requires staff inspection.

04

Reconcile stock without reopening payment

Define the inventory event associated with the completed purchase and the location from which quantity is consumed. If stock posting is delayed, retain the pending work under the existing transaction. The lane or recovery desk should not interpret that delay as a reason to request another payment. Keep the business outcome and the remaining integration work distinguishable.

Use a stable movement reference and recognise repeated delivery of the same update. Reconcile transactions requiring a stock movement against movements actually accepted by inventory. A missing update should create an operational task with enough context to repair it. The review should also catch an unexpected quantity or location, since a posted movement can be wrong even when its technical request succeeded.

05

Give the recovery desk a complete handoff

The desk needs the transaction, lane, basket, confirmed payment result, receipt state and stock state in one view. Record why the customer was referred and who owns the case. This lets the next employee continue the investigation without asking the shopper to reconstruct every screen they saw. Keep the original lane state linked to the same case after the transfer.

Use a recovery checklist that makes completion observable. A case should close only when the agreed customer outcome and remaining internal actions are accounted for, including an assigned follow-up when a background issue cannot be resolved immediately at the counter.

• Identify the original transaction and the basket version paid.
• Confirm the payment outcome through the selected provider.
• Check the receipt or fiscal reference with the equipment interface.
• Verify the inventory movement or identify the pending correction.
• Record the customer’s next step and the owner of any remaining work.

06

Rehearse interruptions across the entire journey

Test a lane restart during payment, a late provider confirmation, a receipt interruption and an inventory outage. Include the shopper walking away before an uncertain result is resolved and a different staff member taking over the desk. The system should preserve the case and its evidence regardless of whether the original browser session remains open.

RDC can connect the lane, supervisor and recovery views to the store’s payment, fiscal and inventory systems. Compare EU-hosted and company-managed services through local connectivity, device responsibilities, monitoring, access and recovery requirements. Measure unresolved transactions by missing step, repeat recovery attempts and time until an authoritative outcome is recorded. Use these findings to improve the state transitions and staff instructions before expanding the deployment. Bring provider documentation and a complete transaction trace from each component; those references make reliable recovery a testable part of the implementation.