Een klant heeft al een onbetaalde weborder en wil bij afhalen aan de terminal betalen. De winkel wil die bestaande order gebruiken, zodat productkeuze en klantcontext bij elkaar blijven. Dat vraagt om een bewust ontworpen route van ordercontrole naar betaalpoging. Een terminalfunctie in de gewone checkout bewijst niet automatisch dat iedere bestaande of handmatig aangemaakte order via dezelfde knop kan worden afgerekend.
Controleer eerst welke orderroute van toepassing is
In een fictieve webshop plaatst een klant een bestelling met een afgesproken betaalmoment aan de balie. Een andere klant heeft een eerder afgebroken online betaling. Beide komen ophalen, maar hun betaalhistorie verschilt. De medewerker moet daarom de bestaande order en eventuele eerdere pogingen beoordelen. Het doel is vaststellen welke actie nog nodig is. Alleen een zichtbare openstaande status is onvoldoende wanneer de informatie over een eerdere poging nog moet worden gecontroleerd.
De bestaande Yindle-terminalbouwsteen kan servergestuurde terminalbetalingen vanuit een afgebakende WooCommerce-flow ondersteunen. De precieze route voor een bestaande order, beheerscherm of betaalpagina moet afzonderlijk worden bevestigd en getest. Begin met één toegestane ordersoort. Leg vast in welke fase de order moet staan, wie haar mag openen en waar de medewerker de actuele betaalcontext ziet. Een beperkte eerste toepassing maakt het makkelijker om de volledige handeling te beoordelen.
Houd bestelling en betaalpoging herkenbaar verbonden
Laat de medewerker vóór het verzoek de orderreferentie, de relevante inhoud en het bedoelde bedrag controleren. Wanneer de klant nog een artikel wil toevoegen, moet eerst de daarvoor afgesproken orderwijzigingsprocedure worden gevolgd. Een lopende poging mag niet ongemerkt een andere bestelling gaan vertegenwoordigen. Het betaalbedrag en de valuta moeten bij de vastgelegde ordercontext passen, en de order wordt pas als betaald behandeld na de juiste geverifieerde provideruitkomst.
Maak duidelijk wat na de betaling gebeurt met afgifte. Betaald zijn en goederen meegegeven hebben zijn verschillende feiten. De balie moet kunnen zien welke stap is afgerond en welke nog volgt. Voorkom dat het systeem dezelfde bestaande order nogmaals als nieuwe verkoop aanmaakt alleen om een betaalroute te openen. De gewenste koppeling tussen order en poging moet binnen de implementatie zijn uitgewerkt; een medewerker hoort dit niet met handmatige kopieën op te lossen.
Test de complete balieroute met drie fictieve orders
Gebruik een order zonder eerdere betaalpoging, een order met een verklaard afgebroken poging en een order waarvan de uitkomst nog beoordeling vraagt. Laat een medewerker per geval de juiste route kiezen. Controleer of hij weet wanneer een terminalverzoek mogelijk is en wanneer eerst onderzoek nodig is. Bekijk ook de informatie die na afloop in de orderweergave staat. Een collega moet de betaalcontext kunnen volgen zonder bij het oorspronkelijke gesprek aanwezig te zijn.
Controleer tijdens de proef ook de zoekroute voor een klant zonder geopende bevestigingsmail. De medewerker moet de bedoelde order volgens de eigen procedure kunnen vinden zonder een nieuwe bestelling te maken om verder te kunnen.
Bewaar de toegestane route en de uitzonderingen in een korte werkinstructie. Voor de aansluiting met ordercontext en uitvoering kun je Yindle Connect verkennen. De concrete toepassing voor bestaande weborders kun je via Yindle bespreken. Het resultaat is dat een klant zijn bestaande bestelling aan de balie kan laten beoordelen voor de afgesproken terminalroute, met behoud van herkenbare order- en betaalhistorie.