Benzigo

Das Problem

Benzigo verkauft Tankkarten an Unternehmen mit Fuhrpark: eine Karte je Fahrzeug, Ausgabenlimits, Rabatte an fünftausend Stationen. Geht eine Karte verloren, verlässt ein Fahrer das Unternehmen oder bleibt eine Rechnung offen, muss diese Karte gesperrt oder eingefroren werden — sofort, nicht morgen.

Das Portal des Kraftstoffanbieters ist für einen Menschen gebaut, der sich durchklickt. Benzigos CRM erzeugt solche Vorgänge zu Tausenden. Dazwischen saß jemand und erledigte das von Hand — und einen Vorgang falsch zu machen kostet auf die direkteste denkbare Weise Geld: Eine Karte, die eingefroren sein müsste und es nicht ist, tankt weiter, und der Kunde zahlt die Rechnung.

Was ich gebaut habe

Die Kundenoberfläche: eine Vue-Anwendung, mit Capacitor für Android paketiert und als Progressive Web App ausgeliefert — ein Fuhrparkleiter installiert sie direkt aus dem Browser.

Darin die Kartenzahlung offener Rechnungen. Die Zahlseite liegt bei der Bank, Kartendaten erreichen Benzigo also nie — aber das CRM hatte für Acquiring nur einen Stub, der Rest war meiner: die Zustandsmaschine der Aufträge, eine je Versuch eindeutige Nummer, damit eine von der Bank abgelehnte Rechnung erneut bezahlt werden kann, und der Aufschlag, der vor der Weiterleitung angezeigt wird, weil der belastete Betrag nicht der eingetippte ist. Der Kunde wollte die Bank abfragen statt ihren Callback empfangen, also ist die Buchung über die Auftrags-ID der Bank idempotent — wer zuerst ankommt, schreibt die Zahlung.

Und einen autonomen Bot in Go, der nicht Dateien weiterreicht, sondern die Arbeit erledigt: Er authentifiziert sich am Portal des Anbieters, hält das JWT in Redis, holt XML-Aufgaben vom FTP und führt jede Operation über die API des Portals aus — Karten finden und prüfen, sperren, entsperren, einfrieren, auftauen, den Vertragssaldo lesen. Einfrieren gibt es dort nicht als Schaltfläche. Es muss über das Limit-System der Plattform ausgedrückt werden, also bearbeitet der Bot Limit-Datensätze, um einen Zustand herzustellen, den das Portal begrifflich nicht kennt.

Die defensiven Teile zahlen sich aus: Nach einem Fehlschlag prüft der Bot den tatsächlichen Limit-Zustand der Karte nach, statt ihn anzunehmen, und ein fehlgeschlagener Saldo-Abruf wird nie als 0,00 ₽ gemeldet — die Ergebnisdatei ist das, was das CRM glaubt. Die meisten der 36 Tests existieren, um genau das zu schützen. Er läuft als Verbund von Docker-Instanzen, jede mit eigenen Portal-Zugangsdaten, und der Kunde betreibt mehrere parallel.

Das Ergebnis

Tausende Kartenvorgänge laufen unbeaufsichtigt durch — gegen ein Portal, das nie dafür gedacht war, von etwas anderem als einem Menschen bedient zu werden. Benzigo gibt an, über tausend Firmenkunden an mehr als fünftausend Partnerstationen zu bedienen.

Zur Genauigkeit gehört der Zuschnitt: Das CRM stammt größtenteils von einem anderen Team — darin ist das Acquiring-Modul meines. Ebenso die Anwendung, die die Kunden benutzen, und die Automatisierung, die in ihrem Namen im System des Anbieters handelt.

Stack

Beteiligte Leistungen