Toon een balie- of terminalbetaling alleen wanneer de ordercontext bij de fysieke locatie past. Gebruik een expliciete vestigings- of afhaalkeuze, niet alleen het IP-adres, de gebruiker of een algemeen beschikbare betaalmethode. Zo voorkom je dat een thuisbesteller een betaaloptie kiest die alleen naast een terminal kan worden voltooid.
Beschikbaarheid is een zakelijke regel. De methode kan afhangen van verzendwijze, gekozen afhaallocatie, rol van de medewerker en geconfigureerde terminal. Al die voorwaarden horen server-side opnieuw te worden gecontroleerd, ook als JavaScript de optie al uit het scherm verbergt.
Definieer één bron voor locatiecontext
Kies welk gegeven bepaalt waar de betaling plaatsvindt. Bij click-and-collect is dat meestal de gekozen afhaallocatie. Bij een door personeel aangemaakte order kan het een expliciete vestiging zijn. Een medewerkersaccount kan als extra controle dienen, maar iemand kan tijdelijk in een andere winkel werken; rol of profiel alleen is daarom niet altijd voldoende.
Koppel per locatie een herkenbare lijst van terminals. Toon geen technisch ID aan de medewerker, maar een duidelijke naam en eventueel positie. Wanneer er precies één beschikbaar apparaat is, kan dat vooraf gekozen worden. Bij meerdere apparaten is een bewuste keuze veiliger.
| Voorwaarde | Terminalbetaling tonen? | Reden |
|---|---|---|
| Afhalen op locatie met actief apparaat | Ja | Klant en terminal komen fysiek samen |
| Thuisbezorging vanuit gewone checkout | Nee | Terminal is niet bereikbaar voor klant |
| Afhaallocatie zonder configuratie | Nee | Geen betrouwbaar apparaat gekozen |
| Onbevoegde medewerker | Nee | Starten van baliebetaling is beperkt |
| Locatie verandert tijdens checkout | Opnieuw beoordelen | Oude terminalkeuze is niet meer geldig |
Controleer opnieuw op het moment van starten
Een zichtbare betaalmethode is nog geen toestemming. Tussen tonen en klikken kan de verzendmethode wijzigen of een terminal worden uitgeschakeld. Laat de server daarom bij starten order, locatie, terminal en bevoegdheid opnieuw valideren. Geef bij afwijzing een begrijpelijke route: kies een andere methode of vraag een bevoegde medewerker.
Verwijder een eerdere terminalkeuze wanneer de klant wisselt van afhalen naar bezorgen of van vestiging. Anders kan verborgen sessiedata later opnieuw verschijnen. Hetzelfde geldt bij een gekopieerde order of terugkeer via de browsergeschiedenis. De actuele ordercontext moet telkens leidend zijn.
Definieer gedrag bij een tijdelijke storing los van configuratie. “Terminal bestaat niet voor deze locatie” vraagt beheer; “apparaat momenteel niet bereikbaar” kan een tijdelijke operationele keuze vragen. Toon klanten geen interne apparaatstatussen. Een baliemedewerker mag meer context zien, maar ook daar is een concrete vervolgstap belangrijker dan een ruwe providermelding.
Fictief voorbeeld: drie winkels, vijf terminals
Outdoorwinkel Kompas heeft drie vestigingen. Rotterdam heeft twee terminals, Delft één en Leiden tijdelijk geen. Een klant kiest ophalen in Delft. De checkout toont baliebetaling als optie, maar start de betaling nog niet; dat gebeurt pas wanneer de klant bij de balie staat en een medewerker de order opent.
Een dag later verandert de klant telefonisch de afhaallocatie naar Leiden. De oude terminalkeuze wordt verwijderd en de methode verdwijnt, omdat die vestiging geen actief apparaat heeft. De medewerker biedt een andere ondersteunde betaalroute. Het systeem doet geen aannames op basis van de oorspronkelijke selectie.
Kompas registreert per terminal alleen de operationeel nodige identificatie en locatie. De publieke checkout krijgt nooit een lijst met alle apparaten of interne labels. In beheer kan een bevoegde gebruiker een terminal deactiveren zonder historische orderreferenties te verwijderen. Zo blijven oude transacties uitlegbaar terwijl nieuwe betalingen de gewijzigde configuratie respecteren.
Wanneer locatie, order en voorraad ook in andere systemen worden beheerd, leg dan per gegeven de bron vast. De uitleg over webshop en ERP betrouwbaar koppelen laat zien waarom expliciet eigenaarschap fouten voorkomt.
Locatiegerichte acceptatietest
- Test iedere vestiging met actieve, inactieve en ontbrekende terminal.
- Wissel tussen bezorgen en afhalen nadat de checkout geladen is.
- Wissel afhaallocatie en controleer dat oude sessiedata verdwijnt.
- Probeer starten met een klantaccount en onbevoegde medewerker.
- Schakel een terminal uit terwijl de orderpagina openstaat.
- Controleer mobiel, desktop en het echte balieapparaat.
- Maak foutmeldingen specifiek zonder technische configuratie prijs te geven.
- Documenteer wie terminals per vestiging beheert.
Houd locatiebeheer centraal en klein. Vrije tekstvelden voor vestigingsnamen leiden snel tot varianten die niet meer aan een terminal te koppelen zijn. Gebruik stabiele interne identificaties en toon gebruikers herkenbare labels. Voor verdere integratie van order- en vestigingscontext kan Yindle Connect de procesgrenzen expliciet maken.
Plan daarnaast een periodieke controle met de mensen op locatie. Een technisch actieve terminal kan fysiek zijn verplaatst, vervangen of niet meer bij de bedoelde balie staan. Laat vestigingsverantwoordelijken de herkenbare namen bevestigen en verwijder ongebruikte configuraties gecontroleerd. De softwarekaart blijft zo aansluiten op de werkelijkheid.
Laat Yindle de beschikbaarheidsregels voor jouw baliebetaling uitwerken.