ZAHLUNGSABWICKLUNG FÜR PLATTFORMEN & MARKTPLÄTZE

Die Ausgangslage

In einem gewöhnlichen Onlineshop fließt Geld von einem Kunden an einen Händler. Bei einer Bestellplattform sind an jeder Zahlung drei Parteien beteiligt: die bestellende Person, das Restaurant, das die Leistung erbringt, und die Plattform, die den Umsatz vermittelt.

Daraus folgt eine Frage, die vor der ersten Zeile Code beantwortet werden muss: Wo liegt das Geld zwischen Zahlung und Auszahlung, und wer ist dafür verantwortlich?

Warum nicht einfach ein Händlerkonto

Der naheliegende Weg ‒ die Plattform vereinnahmt alle Zahlungen auf dem eigenen Konto und überweist den Restaurants ihren Anteil ‒ ist aufwendiger, als er aussieht. Wer dauerhaft Geld entgegennimmt, das wirtschaftlich anderen zusteht, bewegt sich im Bereich regulierter Finanzdienstleistungen. Dazu kommt der laufende Betrieb: Abrechnung je Betrieb, Überweisungen, Belege, Abstimmung bei Rückfragen.

EAT-TAXI nutzt Stripe Connect

Stripe Connect ist für genau diesen Fall gebaut. Das Modell: Die Plattform bleibt der technische und kaufmännische Rahmen, aber jeder Leistungserbringer bekommt ein eigenes, mit der Plattform verbundenes Konto beim Zahlungsdienstleister.

Stripe ist einer der führenden Payment Provider weltweit. Unser Team hat Stripe bereits erfolgreich in verschiedenen Projekten eingesetzt.

Der Aufbau bei EAT-TAXI

EAT-TAXI ist in dieser Struktur die Plattform. Jedes angeschlossene Restaurant hat ein eigenes verbundenes Konto.

Das hat drei konkrete Folgen:

• Die Aufnahme eines Restaurants läuft über Stripe

  Firmendaten, Identitätsnachweise und Bankverbindung werden dort erfasst und geprüft ‒ die gesetzlich vorgeschriebene Identitätsprüfung übernimmt der Zahlungsdienstleister, nicht die Plattform.

• Jede Zahlung ist einem Konto zugeordnet

  Eine Bestellung bei Restaurant A landet auf dem Konto von Restaurant A, der Plattformanteil wird dabei einbehalten. Es gibt keinen Sammeltopf, der später aufgeteilt werden muss.

• Die Auszahlungen steuert Stripe

  Sie laufen nach festem Plan auf das hinterlegte Bankkonto des Betriebs. Bei EAT-TAXI löst niemand Überweisungen aus und pflegt keine Auszahlungslisten.

Für die Restaurants heißt das: nachvollziehbare Beträge zu planbaren Terminen. Für die Plattform: Der Verwaltungsaufwand wächst nicht mit der Zahl der angeschlossenen Betriebe. Das fünfzigste Restaurant verursacht denselben Aufwand wie das fünfte.

Die Zahlung

Jede Bestellung erzeugt einen Zahlungsvorgang, in der Stripe-Terminologie einen Payment Intent. Dieser Vorgang hat einen Zustand ‒ er wartet auf Bestätigung, scheitert oder schließt erfolgreich ab ‒, und dieser Zustand ist der führende Stand für die gesamte Bestellabwicklung.

Bezahlt wird direkt beim Bestellen. Die Bestellung erreicht die Küche also erst, wenn die Zahlung bestätigt ist. Das Restaurant muss nicht prüfen, ob am Ende auch gezahlt wird. Bei Bedarf können die angeschlossenen Restaurants aber auch Bar-Zahlungen erlauben. Diese werden dann sofort als bestätigt, aber offen im System hinterlegt, so dass der Fahrer  oder das Restaurant informiert ist, bei welchem Kunden noch eine Barzahlung vor Ort aussteht.

Vielfältige Zahlarten

Zum Start verfügbar sind bei EAT-TAXI Kreditkarte, PayPal, Klarna, Amazon Pay, Google Pay, Apple Pay und Barzahlung.

Alle Zahlarten laufen über dasselbe technische System, die Stripe Connect API. Weitere Zahlarten können im Stripe Management Board einfach per Klick aktiviert werden. So ist unser Kunde EAT-TAXI flexibel und kann schnell von neue,n beliebten Zahlungsmethoden profitieren.

Die Barzahlung ist in gewisser Weise ein Sonderfall und technisch der interessanteste: Hier entsteht eine vollständige Bestellung, ohne dass jemals ein echter Zahlungsvorgang beim Dienstleister existiert. Die Bestellabwicklung darf deshalb nicht am Zahlungsstatus hängen, sondern muss beide Wege kennen. Für eine Plattform, die lokal antritt, ist das ein wichtiger Punkt.

Weniger als eine Sekunde pro Zahlvorgang

Durch die Nutzung des Payment-Intent-Modells von Stripe dauert eine Zahlung in der EAT-TAXI-App im Durchschnitt nur etwa eine halbe Sekunde ‒ gemessen von der Bestätigung durch den Nutzer bis zur Rückmeldung in der App.

Das ist aus drei Gründen mehr als eine Randnotiz. Erstens ist die Kasse der Punkt, an dem Bestellungen abgebrochen werden: Wer wartet, ohne zu wissen worauf, schließt die App. Zweitens erzeugt genau diese Wartezeit die unangenehmsten Fehlerfälle ‒ es wird erneut getippt, zurückgewischt, die Seite neu geladen usw. Je kürzer der Vorgang, desto seltener entsteht die Situation überhaupt. Und drittens kommt die Bestellung in der Küche eher an. Bei einer Lieferzeit, die ohnehin knapp kalkuliert ist, zählt jeder Schritt, der nicht wartet.

Starke Kundenauthentifizierung

Onlinezahlungen unterliegen in Europa der Pflicht zur starken Kundenauthentifizierung ‒ zum Beispiel der Rückfrage über die Banking-App oder die Authentifizierung bei PayPal und Co. Stripe wickelt diese Prüfung ab und wendet die zulässigen Ausnahmen an, etwa bei niedrigen Beträgen. Für die Integration heißt das vor allem: Der Bestellablauf muss einen Zwischenschritt vertragen, bei dem der Nutzer nicht die App verlassen muss, sondern alles komfortabel in einer Oberfläche beident.

Was wir vor dem Start getestet haben

Im Testbetrieb von Stripe lassen sich die Fälle auslösen, die im Echtbetrieb selten und genau deshalb unangenehm sind: abgelehnte Karten, abgebrochene Authentifizierung, mehrfach zugestellte Ereignismeldungen, Verbindungsabbruch während der Bestätigung, Barbestellung bei zwischenzeitlich geänderter Bestellung. Jeder dieser Fälle wurde einmal durchgespielt, bevor die erste echte Zahlung lief.