De betaalmethode wordt meestal als voorkeur besproken en is eigenlijk een architectuurbeslissing. Elke optie stelt andere eisen aan de hardware van de lader, de backend en de driver, en elke optie faalt op een andere manier.
De meeste netwerken ondersteunen er uiteindelijk meer dan één, omdat de bestuurderspopulaties die zij bedienen niet dezelfde zijn.
Wat elke methode veronderstelt
- RFID gaat uit van een vooraf uitgegeven kaart en een lezer in de oplader. Snel, werkt offline met een lijst in de cache en nutteloos voor een eerste bezoeker.
- De app gaat ervan uit dat de driver software installeert voordat hij wordt opgeladen. Rijke ervaring, hoge mate van verlating bij het eerste gebruik, waardevol voor terugkerende bestuurders.
- QR en mobiel betalen gaan uit van een smartphone en een betaalapp die de bestuurder al heeft. Laagste drempel voor een bezoeker, afhankelijk van connectiviteit.
- Plug and Charge neemt de identiteit aan de voertuigzijde aan. Beste ervaring, smalste voertuigondersteuning, meeste infrastructuur om op te zetten.
Offline gedrag verschilt sterk
RFID tegen een in de cache opgeslagen autorisatielijst is de enige methode die netjes werkt zonder connectiviteit. Daarom blijft deze methode bestaan in wagenpark- en werkplekimplementaties, ondanks dat deze de minst moderne is.
Mobiele betaalmethoden zijn het meest afhankelijk van connectiviteit, omdat de betaling zelf het netwerk nodig heeft. Een site met onbetrouwbare connectiviteit en alleen mobiel betalen zal sessies verliezen die de operator nooit ziet.
Hardware-gevolgen
Een lezer voegt kosten toe aan elke eenheid, of deze nu wordt gebruikt of niet. Een display dat een dynamische code kan weergeven, zorgt voor extra kosten en een storingspunt. Als u na de hardwareselectie een betalingsmethode kiest, betekent dit dat u moet betalen voor mogelijkheden die u niet gebruikt, of dat u ontdekt dat u niet kunt ondersteunen wat u nodig heeft.
Dit is een geval waarin een commerciële beslissing vooraf moet gaan aan een hardwarebeslissing, en dat gebeurt vaak niet.
Met wie de bestuurder een relatie heeft
Een app maakt van de chauffeur uw klant. Een kaart uitgegeven door een mobiliteitsaanbieder maakt hem/haar klant van de aanbieder en roamt op uw infrastructuur. Door mobiel betalen zijn ze niemands klant, een bezoeker die één keer een transactie doet.
Dat verschil bepaalt of je ze op de markt kunt brengen, of je weet dat ze zijn teruggekeerd en wie de steunlast draagt als er iets mislukt. Het is een strategische keuze die wordt gepresenteerd als een betalingskeuze.
De ondersteuningslast varieert
Kaartproblemen zijn doorgaans op afstand op te lossen. App-problemen genereren ondersteuningsgesprekken over apparaten en accounts. Bij problemen met mobiele betalingen is er een derde partij betrokken waarover u geen controle heeft, en de chauffeur zal nog steeds contact met u opnemen.
Het afstemmen van de ondersteuning op de betalingsmix, in plaats van alleen op het sessievolume, levert nauwkeurigere bedrijfskosten op.
Een werkbare standaard
Openbare sites hebben over het algemeen een methode nodig die werkt voor een nieuwe bezoeker zonder eerdere relatie, plus een methode die werkt voor terugkerende bezoekers. Privé-, werkplek- en wagenparksites hebben vaak alleen toegang tot in de cache opgeslagen toegangsgegevens nodig, en het toevoegen van openbare betalingen brengt kosten zonder voordelen met zich mee.
Door te beslissen op basis van het type site in plaats van op basis van netwerkbeleid, vermijdt u dat u moet betalen voor mogelijkheden die bepaalde sites nooit zullen gebruiken.