Een webshoporder kan aan een fysieke betaalterminal worden afgerekend als order, terminal en providerbetaling expliciet aan elkaar worden gekoppeld. De medewerker start de betaling vanuit de order, de klant rekent op het apparaat af en de webshop verwerkt de betaalovergang pas nadat de provider de juiste betaling met het juiste bedrag bevestigt.
Dit is iets anders dan een losse pintransactie naast WooCommerce. Zonder koppeling weet de order niet of betaling gelukt is, kan een medewerker de verkeerde order openen en wordt reconciliatie handmatige verwerking. Ontwerp de terminal daarom als één kanaal binnen het orderproces, inclusief mislukken, annuleren en opnieuw proberen.
Leg vier identificaties aan elkaar vast
Een robuuste stroom kent ten minste de WooCommerce-order, de gekozen vestiging, de fysieke terminal en de providerbetaling. Bewaar providerreferenties bij de order, maar toon in beheer alleen wat medewerkers nodig hebben. Een terminalnaam als “Balie Utrecht links” is bruikbaarder dan een technische apparaatcode.
De medewerker moet vóór starten ordernummer, te betalen bedrag en terminal zien. Laat de server controleren of de order nog betaalbaar is en of de terminal voor deze locatie beschikbaar is. Start daarna één concrete betaalpoging. Hergebruik een lopende poging niet stil voor een andere order en maak duidelijk wanneer opnieuw proberen veilig is.
Ontwerp de statussen voor de balie
| Situatie | Wat de medewerker ziet | Wat het systeem doet |
|---|---|---|
| Wacht op klant | Terminal en bedrag, met annuleren | Order blijft onbetaald |
| Betaling bevestigd | Geslaagd met providerreferentie | Controleert bedrag en verwerkt betaling eenmaal |
| Geweigerd of geannuleerd | Begrijpelijke uitkomst | Laat gecontroleerd opnieuw proberen |
| Status onbekend | Niet opnieuw laten betalen | Vraagt actuele providerstatus op |
| Terminal onbereikbaar | Apparaat niet beschikbaar | Behoudt order en biedt passend alternatief |
Gebruik niet alleen een draaiende indicator. Benoem wat de klant of medewerker nu moet doen. Een transactie kan op het apparaat klaar zijn terwijl het browservenster nog geen update heeft ontvangen. De webshop hoort daarom een actuele status bij de provider te kunnen ophalen en ook een latere providerbevestiging te verwerken.
Maak annuleren tweezijdig. Alleen het browservenster sluiten beëindigt de opdracht op de terminal mogelijk niet; alleen de terminal annuleren laat de webshop misschien wachten. Stuur daarom een annulering waar mogelijk naar de provider en vraag daarna de definitieve status op. Een timeout betekent “uitkomst nog onbekend”, niet automatisch “mislukt”. Houd de order in die toestand buiten fulfilment totdat de status betrouwbaar is vastgesteld.
Fictief voorbeeld: afhalen bij een showroom
Interieurwinkel Vormkracht laat klanten online bestellen en in de showroom betalen. Medewerker Inez opent order 1842, ziet het openstaande totaal en kiest “Showroom begane grond”. De terminal toont het bedrag. Terwijl de klant pint, loopt de tabletverbinding kort vast. Inez drukt niet nogmaals op starten; het scherm meldt dat de uitkomst wordt gecontroleerd.
Na herstel haalt de webshop de actuele betaalstatus op. De provider bevestigt dezelfde orderreferentie en hetzelfde bedrag. De betaling wordt één keer verwerkt en WooCommerce zet de order volgens product- en procesconfiguratie in de passende betaalde status. Bij fysieke producten is “Processing” doorgaans nog geen vervulde order; magazijn en levering volgen daarna. Als het bedrag niet overeenkwam, blijft de order in een controletoestand.
Moeten verkoop, voorraad en administratie daarna ook worden bijgewerkt, ontwerp dan de volledige gegevensstroom. Een WooCommerce-AFAS-koppeling is bijvoorbeeld meer dan één export; ook fouten en herstelacties hebben een eigenaar nodig.
Vormkracht beperkt terminalknoppen bovendien tot medewerkers van de betreffende vestiging. Een webshopbeheerder kan apparaten configureren, terwijl een baliemedewerker alleen een betaling voor een open order mag starten. Het systeem registreert wie de actie begon, maar toont geen volledige betaalgegevens in gewone ordernotities. Zo ondersteunt logging onderzoek zonder een nieuw privacy- of beveiligingsrisico te creëren.
Checklist voor terminalacceptatie
- De medewerker ziet order, bedrag, vestiging en terminal vóór starten.
- Alleen bevoegde rollen kunnen een betaalpoging beginnen of annuleren.
- De order kan niet tegelijk via twee terminalacties worden afgerond.
- Browserpolling en providerberichten leiden tot dezelfde eindstatus.
- De server controleert providerreferentie, muntsoort en bedrag.
- Een onbekende status vraagt controle en geen tweede betaling.
- De interface werkt op het apparaat dat werkelijk bij de balie ligt.
- Logboeken bevatten referenties en uitkomsten, geen onnodige betaalgegevens.
Maak ook een korte balieprocedure voor stroomuitval, een defect apparaat en een klant die wegloopt tijdens de betaling. Techniek kan de status betrouwbaar vastleggen; medewerkers hebben daarnaast een helder handelingsperspectief nodig. Lees meer over betrouwbare ketens tussen webshop en ERP.
Bespreek met Yindle hoe terminalbetaling in jouw orderproces past.
Voor een uitgewerkte WooCommerce-terminalflow met geautoriseerde orders, providerverificatie en showroomtoegang, zie Yindle Terminal Payments en de gids Mollie POS-terminalbetalingen voorbereiden.