A customer changes their mind after the terminal request has started: they want to add an accessory or remove an item. The shop must prevent the order from changing while the payment attempt in progress still represents the previous amount. A terminal pilot should explicitly cover this situation in the working instructions. First establish what happens to the existing attempt; then the intended new order can proceed through the supported route.
Record when the change occurs
In a fictional showroom, a customer wants to take an extra chair while paying by card. The employee has already checked the order and sent the request to the terminal. Adding an order line is now more than a catalogue action. The existing attempt belongs to an earlier order context. Have the employee recognise the request and follow the agreed procedure, rather than changing amounts on different screens midway through.
The exact options for stopping, cancelling and recovering must be established for your implementation. The existing Yindle terminal component provides a basis for order-linked payment processing, but does not offer a general guarantee for every change during an ongoing transaction. Make clear in advance which stages support a change and which require assessment first. Employees need to know whom to involve when the existing attempt's outcome is still unclear.
Assess the existing attempt before issuing a new instruction
Check the technical status using verified provider information. The amount and currency must match the correct recorded order context before treating the payment as processed. Returning to a counter screen or changing an order line does not prove that an earlier attempt has disappeared. The pilot procedure should identify the source supporting the outcome and how that outcome becomes visible to the employee helping the customer.
Once the existing attempt has been handled through the supported route, the new configuration can be assessed again. Show the customer and employee the same revised order overview. Check the product, quantity and intended total before starting another payment action. This article does not prescribe financial handling; the shop should use its own approved procedure for differences and follow-up actions. The technical design should support that procedure in a traceable way.
Practise the same customer request at three different stages
Use fictional orders and introduce the request for an accessory before the payment request, during the attempt and after payment has been verified. Employees should be able to explain why the next step differs at each stage. Observe whether they find the existing attempt rather than immediately starting again. Training where the change always happens at the easiest moment does not adequately prepare the counter team for a real conversation.
After the exercise, have the person playing the customer describe the revised order again. This checks that the conversation and final order describe the same new item and quantity, rather than merely a changed total.
For each exercise, record which information the employee needed and which step remained unclear. Use those findings to improve the supported route and screen explanations. To handle these questions operationally, you can explore Yindle Desk as an option. A tailored order and payment interface fits within custom software. The result is that a customer's change is first reconciled with the existing payment attempt and then proceeds as a clearly checked new order.