Die Daten im World Wide Web Consortium (W3C)
Das am 1. Oktober 1994 gegründete World Wide Web Consortium (W3C), ist ein Gremium, das die Hoheit über fast alle Techniken hat, die im Web eine Rolle spielen um somit vereinfachte Strukturen für alle zu schaffen. Das World Wide Web Consortium (W3C) fördert Standards für das World Wide Web (WWW) im Internet. Doch was haben unsere eigentlich hinterlegten Daten im Browser mit einem neuen Standardisierungsvorhaben zu tun und was bedeutet das letztlich für den Kunden? Wir haben dazu mal einige Fragen in den Raum geworfen.
Eine neue Standardisierung als Vorhaben
Doch das mit dem W3C ist so eine Sache. Viele Standardisierungsvorhaben, diese dann oft nicht nahe an der Realität und man fragt sich an mancher Stelle: “Warum kümmern die sich eigentlich darum?” bzw. “was ist deren Mehrwert“? Diesen Kontext und die Fragen greift folgender Artikel von Onlinehändler News auf, der auch Grundlage dieser Überlegungen sein soll. Laut Artikel soll es eine neue Payment Request API geben, „die das Bezahlen im digitalen Raum mithilfe eines standardisierten Checkout-Prozesses vereinfachen soll.“ Weiter heißt es ebenfalls:„die technische Entwicklung der Standards, an denen Microsoft, Google, Facebook, Apple und Mozilla mitgearbeitet haben, seien soweit abgeschlossen, dass sie implementiert werden können.“Weitere Artikel dazu gibt es hier:
- https://www.w3.org/TR/payment-request/ oder das etwas besser lesbar von Google
- https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/
- Adrian Bateman, Microsoft Corporation
- Zach Koch, Google
- Roy McElmurry, Facebook
- Domenic Denicola, Google
- Marcos Cáceres, Mozilla
- Der Browser soll als “Intermediary” dienen zwischen Merchant, Endkunde & Payment Methode
- Die klassische Payment Page soll verschwinden
- Der Payment Flow soll standardisiert werden.
- Was bedeutet das für normale Checkouts ? ==> sie sollen verschwinden
- Wer muss das eigentlich technologisch umsetzen ? ==> der Merchant bzw. dann sein PSP oder er integriert direkt
- Konversion: Der Treiber im Online Payment – gut, schlecht, weiß nicht ?
- Welchen Vorteil hat der der Endkunde ? ==> er muss sich nicht an unterschiedliche Checkout Forms gewöhnen. Eingabe der Daten im Browser und seamless “no click” checkout…
- Was sagt PCI dazu ? ==> nix… Kartenstorage im Browser gibt es schon… und das senden von CC PAN an die PaymentRequest API wird vermutlich über PCI compliant Dienstleister = PSP erfolgen
- Wird hier nicht ein Sicherheitsloch aufgemacht ? ==> nicht unwahrscheinlich, der Client ist oft Einfallstor und bekommt hierdurch “mehr Macht”
- Ist das ein weiterer Schritt den Browser zum “Fat Client” zu machen?
- Was bedeutet das für Apps & Konsorten?
- Und für den Kanal Mobile ? ==> für Mobile an sich eigentlich wenig, es stärkt etwas den Browser auch im Mobilen Umfeld (und damit werden ggf. einige Payment Transaktionen nicht mehr über die Infrastruktur von Apple oder Google gehen; ob das ins Gewicht fällt, glaube ich nicht); ich gehe nicht davon aus, dass der “App Trend” nachhaltig beeinflusst wird.
- Was muss ein Händler tun ? Wird es einen parallelen Betrieb von Payment Page und Payment API geben ? ==> vemrutlich ja, v.a. weil nicht jeder Browser in derselben Version alles kann
Fazit
Das Ziel hinter der Initiative ist klar. Checkout Forms eliminieren, den Browser als Anwendung stärken (Revieval des Fat Clients). Es geht auch etwas gegen die Mobilen Apps. Und gegen die Zahlmethodenvielfalt. Eine Standardisierung des “Flows” bedeutet auch, dass Unterschiede in den Zahlmethoden verschwinden (müssen) und damit auch („mögliche”) Differenzierungsmerkmale. Das stützt auch unsere These, am Ende will der Kunde “einfach nur zahlen”, wie ist eigentlich nicht so wichtig. Wie ist eure Meinung zu dem Thema? Freuen uns über einen regen Austausch… Sammlung:- The World Wide Web Consortium (W3C) with the help of Microsoft, Google, Facebook, Apple and Mozilla initiated the project in 2013.
- Users will then be able to choose from a drop-down menu of available payment methods supported, a kind of expansion on the auto-fill feature already widely enabled at checkout.
- At this stage, customers will need to download the browser extension and signal
3 Kommentare
Hi Ben, ich würde die API nun nicht als neue Zahlart sehen, aber du hast recht, das Thema ist sehr US getrieben und damit vermutlich mit einem Kreditkarten (und gegen PayPal) Fokus – meine Annahme war, dass über die Integration die Zahlartenauswahl gesteuert wird, da am Ende immer noch der Händler die Verträge mit den Zahlarten hält (und nicht der Browser). aber klar, es ist ein versuch den Kunden „mehr und mehr zu ownen“, weg vom Händler – hin zu den Plattformen mit Hilfe des Browsers
18. Oktober 2017
Also mehr als 50% aller Zahlungen weltweit laufen über Alternative Zahlmethoden. Rechnung, Zahlung über das Konto (Klarna & Co.), Carrier-Billing, etc…
Oder anders formuliert, die „Payment Page“ werden wir nicht los. Selbst dort wo der Checkout schon optimiert wurde – Apple Pay über Safari – hört man leider wenig Neues. Und das gilt auch für Apple Pay in Apps.
Überfordern wir (das Payment Ecosystem) die Händler (und die Kunden) mit zu vielen verschiedenen Optionen?
9. November 2017
Hier wurden einige Sachen ausser Acht gelassen. Kommt der Mehrwert für einen Merchant „nur“ durch einen „vereinfachten“ Flow für den Endkunde? Ist es nicht ein Versuch, dass Browserhersteller den Kunden nicht nur vorne im Funnel „ownen“ (sprich Google/Facebook Advertising) sondern nun auch hinten raus. Damit würde die Merchants nur noch auf die Logistic für anonyme Kunden reduziert (überspitzt). Auffällig ist, dass kein Merchant vertreten ist. Wer entscheidet über die Zahlarten, die dann auf der Payment Page angeboten werden? In unseren Diskussionen mit Google und Microsoft hat man sich bisher gar keine gedanken gemacht (es gibt durch eh nur Kreditkarte (in den USA)). Hier wird auch verschwiegen, dass eine neue API wie alle neuen Zahlarten mit dem Henne/Ei Problem kämpft – die grossen Merchants entscheiden welche Zahlarten erfolgreich sind.