Die Zahlungsmethode wird normalerweise als Präferenz diskutiert und ist eigentlich eine Architekturentscheidung. Jede Option stellt unterschiedliche Anforderungen an die Ladegerät-Hardware, das Backend und den Treiber und schlägt auf unterschiedliche Weise fehl.
Die meisten Netzwerke unterstützen letztendlich mehr als einen, da die von ihnen bedienten Fahrerpopulationen nicht dieselben sind.
Was jede Methode voraussetzt
- RFID setzt eine im Voraus ausgestellte Karte und ein Lesegerät im Ladegerät voraus. Schnell, funktioniert offline mit einer zwischengespeicherten Liste und ist für einen Erstbesucher nutzlos.
- Die App geht davon aus, dass der Treiber vor dem Laden Software installiert. Reichhaltige Erfahrung, hohe Abbruchquote beim ersten Einsatz, wertvoll für Wiederholungsfahrer.
- QR und mobiles Bezahlen setzt ein Smartphone und eine Bezahl-App voraus, über die der Fahrer bereits verfügt. Niedrigste Barriere für einen Besucher, abhängig von der Konnektivität.
- Plug and Charge setzt fahrzeugseitige Identität voraus. Beste Erfahrung, engste Fahrzeugunterstützung, größtmögliche Infrastruktur zum Aufbau.
Das Offline-Verhalten unterscheidet sich stark
RFID gegen eine zwischengespeicherte Autorisierungsliste ist die einzige Methode, die ohne Konnektivität sauber funktioniert, weshalb sie in Flotten- und Arbeitsplatzbereitstellungen bestehen bleibt, obwohl sie die am wenigsten moderne ist.
Mobile Zahlungsmethoden sind am stärksten von der Konnektivität abhängig, da die Zahlung selbst das Netzwerk benötigt. Eine Website mit unzuverlässiger Konnektivität und ausschließlich mobiler Bezahlung verliert Sitzungen, die der Betreiber nie sieht.
Hardware-Konsequenzen
Ein Lesegerät erhöht die Kosten für jede Einheit, unabhängig davon, ob sie verwendet wird oder nicht. Ein Display, das einen dynamischen Code anzeigen kann, erhöht die Kosten und stellt eine Fehlerquelle dar. Wenn Sie sich nach der Hardware-Auswahl für eine Zahlungsmethode entscheiden, müssen Sie entweder für Funktionen bezahlen, die Sie nicht nutzen, oder feststellen, dass Sie das, was Sie benötigen, nicht unterstützen können.
Dies ist ein Fall, in dem eine kommerzielle Entscheidung vor einer Hardware-Entscheidung erfolgen sollte, was jedoch häufig nicht der Fall ist.
Mit wem der Fahrer eine Beziehung hat
Eine App macht den Fahrer zu Ihrem Kunden. Eine von einem Mobilitätsanbieter ausgestellte Karte macht ihn zum Kunden des Anbieters und Roaming auf Ihrer Infrastruktur. Mobiles Bezahlen macht sie zum Kunden von niemandem, zu einem Besucher, der einmal eine Transaktion durchführt.
Dieser Unterschied bestimmt, ob Sie an sie vermarkten können, ob Sie wissen, dass sie zurückgekehrt sind und wer die Supportlast trägt, wenn etwas fehlschlägt. Es handelt sich um eine strategische Entscheidung, die als Zahlungsentscheidung dargestellt wird.
Die Unterstützungslast variiert
Kartenprobleme lassen sich in der Regel aus der Ferne lösen. App-Probleme führen zu Supportgesprächen über Geräte und Konten. Bei Problemen mit dem mobilen Bezahlen handelt es sich um einen Dritten, den Sie nicht kontrollieren können, und der Fahrer wird Sie trotzdem kontaktieren.
Die Dimensionierung der Unterstützung anhand des Zahlungsmixes und nicht nur anhand des Sitzungsvolumens führt zu genaueren Betriebskosten.
Ein praktikabler Standard
Öffentliche Websites benötigen im Allgemeinen eine Methode, die für Erstbesucher ohne vorherige Beziehung funktioniert, sowie eine Methode, die für Wiederholungsbesucher funktioniert. Für Privat-, Arbeitsplatz- und Flottenstandorte ist häufig nur der Zugriff mit zwischengespeicherten Anmeldeinformationen erforderlich, und die Hinzunahme öffentlicher Zahlungen ist mit Kosten ohne Nutzen verbunden.
Durch die Entscheidung nach Site-Typ und nicht nach Netzwerkrichtlinien wird vermieden, dass für Funktionen bezahlt wird, die bestimmte Sites niemals nutzen werden.