Die Anzahl an Kunden-Frontends, für die Payment-Lösungen benötigt werden, wächst rasant. Der Lösungsweg für zukunftsgerichtete Payment-Services ist die konsequente Trennung von Frontend und Backend, um ein positives Kundenerlebnis zu erzeugen.
Die Anzahl der Frontends zum Kunden wächst ständig weiter, die bestehenden Kunden-Frontends sterben aber nicht in gleicher Geschwindigkeit aus! Es ist weder wirtschaftlich sinnvoll noch ressourcenseitig machbar, jeweils neue Backend-Prozesse und -netzwerke für die Zahlungen zu entwickeln.
Ein Ende dieser Entwicklung ist noch lange nicht in Sicht, doch es lässt sich schon jetzt etwas sehr Wichtiges für die Zukunft daraus ableiten: Die Anzahl der Frontends zum Kunden wächst ständig weiter, die bestehenden Kunden-Frontends sterben aber nicht in gleicher Geschwindigkeit aus!
Im ersten Teil der zweiteiligen Kurzserie über das „Bezahlen von morgen – und was sich der Kunde vorstellt“ wurde eine Überblick über Payment-Entwicklungen am PoS und im E-Commerce der letzten 30 Jahre gegeben und festgestellt, dass Payment-Innovationen aus Kundensicht primär im Frontend umgesetzt wurden. Im zweiten Teil geht es nun um den Lösungsweg für zukunftsgerichtete Payment-Services, bei dem ein positives Kundenerlebnis im Vordergrund steht.
Kunden erwarten unterschiedliche Payment-Optionen
Die im ersten Teil genannten „Functions On Demand“ (FOD) für Incar-Payments lassen sich zukünftig idealerweise bei laufender Fahrt aus dem Auto dazu buchen, aber auch genauso aus der Hersteller-App oder ‑Webseite. Der Kunde will gar nicht unterscheiden, ob er etwa die Mautzahlungen auf dem Weg in den Urlaub im Voraus per Web oder spontan vor Ort per Auto bezahlen kann – die eine Kundin möchte dies im Voraus planen und bezahlen, der andere Kunde entdeckt die Vorteile erst bei der ersten Mautstation vor Ort. Aber beide wollen die „Fastlane“ an der Mautstation!
Deswegen sprechen alle Autohersteller (OEMs) mit den Card Schemes und weiteren Payment-Anbietern, um beispielsweise mittels „Delegated Authentication“ dieses Kundenerlebnis auch bequem im Auto zu ermöglichen. Die bewährten Backend-Prozesse dieser Anbieter werden jedoch weitgehend gleich bleiben.
Anzahl und Komplexität der Payment-Frontends wachsen exponentiell
Und genauso, wie es Amazon, Zalando, PayPal und Co. vorgemacht haben, das jeweilige Frontend aus Kundensicht optimal zu bespielen, müssen wir als Kreditwirtschaft uns auf die Zukunft des Bezahlens vorbereiten. Die Anzahl der Frontends wächst exponentiell (Mediakanäle x Hardware-Devices x Kundensegmente) und es ist weder wirtschaftlich sinnvoll noch ressourcenseitig machbar, jeweils neue Backend-Prozesse und -netzwerke für die Zahlungen zu entwickeln.
Dieser Trend ist im E-Commerce schon länger zu beobachten: Zunächst mit der Optimierung des eigenen Digitalkanals von Computer Desktop zu Mobile Desktop (also für den mobilen Browser optimiert) und dann zur eigenen App. Viele Anbieter haben jedoch auch den „responsiven“ Weg gewählt. Also einen Webauftritt, der sich dem jeweiligen Device inklusive Bildschirmgröße anpasst und nicht für jedes Device einen eigenen Auftritt. Weiter ging die Entwicklung auf Händlerseite unter den Schlagwörtern „Headless Commerce“ bzw. „Composable Commerce“, da die zunehmende Plattformisierung des Handels schon lange nicht mehr nur den eigenen Webshop oder die eigene App des Handlers im Fokus hat.
Ein Händler muss auf Marktplätzen wie Amazon, eBay etc. genauso präsent sein und zuverlässig anbieten wie im eigenen Shop – auch wenn wesentliche Teile des Prozesses nicht mehr der Kontrolle des Händlers unterliegen. Die klassische Fokussierung auf den eigenen Shop als einziger „Head“ gegenüber dem Kunden hat sich dadurch als inhärenter Nachteil herausgestellt. Aber auch hier sind auf Händlerseite weiterhin die bewährten Enterprise Resource Planning (ERP) Systeme von SAP, Microsoft etc. im Einsatz – unabhängig vom Frontend!
Praxisbeispiel BNPL: Apple Pay und Expresskredit
Viel konnten wir nach der Ankündigung Anfang Juni 2022 über die Relevanz, Motivation und das technische Setup von Buy-now-pay-later (BNPL) bei Apple Pay für die USA in den gängigen Fachmedien lesen. Im Kontext dieses Artikels sehen wir auch hier eine klare Trennung von Frontends und Backends – soweit von außen sichtbar beziehungsweise man den Artikeln entnehmen konnte, setzt Apple auch im Backend auf bewährte Komponenten von Mastercard und Goldmann Sachs, während die eigentliche Innovation im Frontend bei Apple Pay stattfindet.
Ähnlich ist unser Setup für den „Expresskredit“, der Sparkassenkunden am POS einen Ratenkauf ermöglicht, ohne zuvor in eine Filiale zu gehen oder mit einem Berater zu sprechen. Direkt aus der App „Mobiles Bezahlen“ startet der Kunde den Ratenkauf, die eigentliche Bezahlung erfolgt über die Girocard Funktion der Sparkassen Card. Im Hintergrund sind bewährte Prozesse für Ratenkredite aus dem Kernbanken-System respektive des Verbunddienstleisters S-Kreditpartner aktiv.
„Und nu?“
Als Banken und Payment-Anbieter müssen wir also konsequent die Frontends von den Backends trennen und davon ausgehen, dass wir die Fülle an Frontend-Use Cases auch nur mit Partnern bedienen können (zumindest wenn der gesamte Markt angesprochen werden soll).
Dies bedeutet, dass StartUps und FinTechs, die auf der grünen Wiese und nur mit ausgewählten Zielgruppen und/oder Use Cases anfangen, zunächst im Vorteil sind. Dieser Vorteil stößt aber sehr schnell an seine Grenzen, sobald das Zielsegment größer wird oder die gewonnenen Kunden mit Cross-/Upselling weiterentwickelt werden sollen oder müssen. Schon Akteure wie Klarna und N26 sind auf erhebliche Herausforderungen bei der Skalierung gestoßen und auch alle anderen Player wird es ab einer gewissen Größe und Marktabdeckung treffen.
Für Kunden relevant bleiben
Sicherlich werden auch neue Akteure im Markt auf etablierte Payment-Prozesse und Schemes setzen, um im Frontend Innovation und positives Kundenerlebnis zu erzeugen. Das kostet diese Marge auf der einen Seite und bedeutet Abhängigkeit auf der anderen Seite.
Etablierte Banken müssen weiter daran arbeiten, die Fähigkeiten im Frontend kontinuierlich zu erweitern, denn das Meistern hochskalierter Backendprozesse mit wenigen einfachen Frontends war bislang die Stärke vieler Banken. Deswegen sitzen hier alle Marktakteure im gleichen Boot und jeder muss daran arbeiten, wenn man weiterhin für den Kunden relevant bleiben (werden) will.