A customer already has an unpaid online order and wants to pay at the terminal on collection. The shop wants to use that existing order so product choices and customer context stay together. This requires a deliberately designed route from order checking to a payment attempt. A terminal function in the ordinary checkout does not automatically prove that every existing or manually created order can be paid through the same button.
First check which order flow applies
In a fictional online store, a customer places an order with an agreed payment point at the counter. Another customer has an earlier abandoned online payment. Both arrive to collect, but their payment histories differ. The employee therefore needs to review the existing order and any earlier attempts. The aim is to establish which action is still needed. A visible outstanding status alone is insufficient when information about an earlier attempt still needs checking.
The existing Yindle terminal component can support server-controlled terminal payments from a scoped WooCommerce flow. The exact route for an existing order, admin screen or payment page needs separate confirmation and testing. Start with one permitted order type. Record which stage the order must be at, who may open it and where the employee sees the current payment context. A limited initial application makes it easier to assess the complete task.
Keep the order and payment attempt clearly connected
Before the request, have the employee check the order reference, relevant contents and intended amount. If the customer wants to add another item, first follow the agreed order-change procedure. An ongoing attempt must not quietly come to represent a different order. The payment amount and currency must match the recorded order context, and the order is treated as paid only after the correct verified provider outcome.
Make clear what happens to handover of the goods after payment. Being paid and having handed over goods are different facts. The counter needs to see which step is complete and which comes next. Prevent the system from recreating the same existing order as a new sale just to open a payment route. The intended connection between order and attempt needs to be developed within the implementation; an employee should not solve this through manual copies.
Test the complete counter journey with three fictional orders
Use an order without a previous payment attempt, one with an explained abandoned attempt and one whose outcome still needs assessment. Let an employee choose the correct route for each case. Check whether they know when a terminal request is possible and when investigation is needed first. Also review the information shown in the order view afterwards. A colleague needs to follow the payment context without having been present for the original conversation.
During the trial, also check how to find an order for a customer without an open confirmation email. The employee needs to find the intended order using the shop’s procedure without creating a new order just to continue.
Keep the permitted route and exceptions in a short work instruction. The connection with order context and operations through Yindle Connect can be explored. The specific application for existing online orders can be discussed with Yindle. The result is that a customer can have their existing order reviewed at the counter for the agreed terminal route, while retaining a recognisable order and payment history.