A terminal pilot can begin with full payments at one counter. Yet a customer may soon ask for a refund. Before the first practical phase, the store needs to decide how such a request is handled and which parts are technically supported. Having a payment feature does not prove a complete returns and refund route. A clear pilot scope helps employees hand over a request correctly without promising a feature that has not been developed.
Describe the customer request and the technical action separately
In a fictional store, a customer returns an unused component that belonged to a larger order. The store first needs to assess what happens to the item under its own service policy. A payment action may follow after that. This article does not provide legal advice on returns. The technical design needs to follow the authorised employee’s decision and show which payment belongs to the correct order. The service decision and execution of a refund are separate steps.
At provider level, Mollie describes options for refunds of terminal payments. That does not mean a particular WooCommerce plugin already supports the entire route. The Yindle terminal component is already used on live projects; a complete end-to-end refund flow needs to be configured and accepted separately. Make that boundary clear in the internal scope. Employees need to know which feature is available and who takes over a refund request outside that feature.
Choose the first supported situations deliberately
Start with recognisable examples: a full refund of one verified payment, a partial request and an order with a different payment route. Decide for each example whether it falls within the pilot. An unsupported case needs a clear existing service procedure, rather than improvisation at the terminal. Also record which order information and decisions are needed before the technical operator may continue. The request then remains traceable for customer and employee.
Consider what the customer sees after an action and which information order administration needs. A button that submits a request is not proof that the final outcome is known. Define the status checks and handover required for the chosen route. Keep the scope small enough to test those steps fully. A pilot with fewer types of payment action can be operationally clearer than a broad interface with unresolved exceptions.
Practise the handover without processing real amounts
Use fictional orders and have a counter employee receive a return enquiry. Check whether they find the correct order, refer the service decision to the appropriate colleague and recognise the supported payment route. Include a request outside the pilot scope. The exercise needs to show that the customer still receives a clear next step. Test technical refund processing only through the agreed separate test procedure; a training question is not a reason to make a real payment or refund.
Also let the employee practise explaining a request outside the pilot’s scope. A clear handover to the existing service procedure helps the customer more than a technical feature name or an unclear promise about automated processing.
Record the findings before expanding the pilot. For operational handling, you can discuss Yindle Desk as an option. The terminal application’s scope and next steps can be assessed through Yindle with Yindle. The result is a pilot in which employees know which refund route is supported and every other request reaches a clearly responsible person.
A refund during a terminal pilot needs a separate scope decision. Read the boundaries of Yindle Terminal Payments and test the return flow separately from payment confirmation.