© Ozz Design/Shutterstock.com
Payment Request API mit PHP

Bezahlen im Browser


PayPal, giropay, Kreditkarte, Lastschrift oder Rechnungskauf – jedes Bezahlverfahren ist in der User Journey unterschiedlich umgesetzt. Jeder Shop implementiert einen anderen Check-out-Prozess, der Bezahlvorgang wird teilweise zusätzlich durch involvierte Zahlungsdienstleister beeinflusst. Adress- und Bezahldaten müssen bei jedem Onlineshop separat eingegeben werden. Eine einheitliche User Experience im E-Commerce ist so unmöglich. Eine W3C Candidate Recommendation verspricht Abhilfe.

Der Einkaufswagen ist bis obenhin gefüllt, beflügelt vom Einkaufserlebnis und in größter Vorfreude auf die erworbenen Artikel geht es zur Kasse. Nur eine ist besetzt, das Band prall gefüllt, unzählige Menschen stehen bereits in der Schlange. Der Prozess kommt durch das Durchsuchen sämtlicher Hand-, Jacken- und Hosentaschen nach dem Geldbeutel sichtlich ins Stocken. Selbst der letzte Rest Konsumeuphorie wird durch die Gewissheit geraubt, dass weitere Time-outs drohen: „Warten Sie, ich hab’s passend …“

Der Weg zur Kasse birgt eine Spannung in sich, auf die man doch gerne verzichten würde. Im E-Commerce ist der Weg dorthin schneller: ein Klick. Die Spannung indes bleibt. Wie kann ich wohl bezahlen? Wird mein bevorzugtes Bezahlverfahren unterstützt? Muss ich mir unter Umständen doch noch bei einem bekannten Onlinebezahldienst einen Account anlegen? Kreditkarte griffbereit? IBAN auswendig gelernt? Ist diese Hürde genommen, geht es weiter: Versandpartner auswählen, Adresse eingeben – leider ist die Auto-Fill-Funktion nicht korrekt umgesetzt, die Postleitzahl steht in der Hausnummer. Also doch alles eintippen …

Im stationären Handel ist der Bezahlvorgang durch weitere Kassen horizontal skalierbar und lediglich durch die verfügbare Ladenfläche begrenzt. Für den Kunden ist die Kasse, häufig schon die Selbstzahlerkasse, ein Konzept mit hohem Wiedererkennungswert. Das Stehenlassen des vollen Einkaufswagens ist eher selten. Im Onlinehandel ist dieser Wiedererkennungseffekt geringer, Abbrüche kurz vor dem Bezahlen entsprechend häufiger. Die Ursache dafür ist nicht selten, dass sich der Kunde kurz vor dem Ziel im Check-out-Prozess des Onlineshops „verläuft“.

Die W3C-Payment-Request-API-Spezifikation adressiert diese Problematik und überträgt dem Browser die Verwaltung der Adress- und Bezahldaten. Der Check-out-Prozess wird vollständig durch den Browser implementiert und garantiert so eine Konsistenz über verschiedene Shops. Das Credentials-Management einiger Browser bietet darüber hinaus die Möglichkeit, Daten wie Lieferadresse auch über die Devicegrenze hinaus zu nutzen. Einziger Wermutstropfen: Eine breite Unterstützung bieten die Browser aktuell nur für Kreditkarten. Die Spezifikation setzt aber auf Erweiterbarkeit. Händler – oder ein Payment-Service-Provider (PSP) – können beliebige Zahlungsarten integrieren.

Bezahlen in a Nutshell

Der Bezahlvorgang im klassischen Einzelhandel ist denkbar einfach und kommt, insbesondere beim Bargeldaustausch, mit nur zwei Beteiligten aus. Im E-Commerce ist dieser Vorgang deutlich komplexer. Es steigt nicht nur die Anzahl der Prozessschritte, sondern insbesondere auch die der beteiligten Akteure. Neben dem Shop und dem Käufer sind weiterhin der Browser, der Server des Onlineshops und in der Regel mindestens ein (wenn nicht mehrere) Serviceprovider an einer einzigen Zahlungstransaktion beteiligt. Abbildung 1 zeigt exemplarisch die Beteiligten einer Zahlung per Kreditkarte. Der Kunde kauft in einem Onlineshop und bezahlt die Ware mit der Kreditkarte des Issuers, also der Bank bzw. des Instituts, das die Kreditkarte ausgegeben hat. Für die Verarbeitung von Kreditkartentransaktionen und insbesondere das Handling der besonders sensiblen Daten wie Kartennummer und CV-Code wird meist ein entsprechend autorisierter Payment-Service-Provider integriert. Über diesen können die Kreditkartendaten, meist per iframe, direkt an den Acquirer geleitet werden, ohne einen Umweg über die Systeme des Shopbetreibers. Die Transaktion wird vom Server des Onlineshops beziehungsweise des PSP über den Acquirer zum Issuer geroutet. Dieser initiiert daraufhin unmittelbar oder nach einem gewissen Zeitraum den Transfer des Geldes. Da die beteiligten Parteien sich nicht direkt gegenüberstehen, müssen während dieses Vorgangs unterschiedliche Sicherheitsmerkmale (mindestens der CVC, im Rahmen von 3D Secure häufig noch ein zusätzlicher Faktor) ausgetauscht werden, um die Autorisierung der Zahlung durch den tatsächlichen Eigentümer des Zahlungsmittels sicherzustellen.

dorsch_payment_1.tif_fmt1.jpgAbb. 1: Prozess Kreditkartenzahlung

Neben der Kreditkarte gibt es eine Vielzahl weiterer gängiger Zahlungsmittel, deren Anzahl stetig wächst. Will ein E-Commerce-Händler wettbewerbsfähig bleiben, so steht er vor der Aufgabe, all diese Verfahren zu implementieren, beziehungsweise über einen PSP zu integrieren. Die Bezahlung muss dennoch konsistent über die unterschiedlichen Bezahlverfahren in den Check-out-Prozess integriert werden. Unter Umständen sind so größere Aufwände notwendig, um für den Käufer eine optimale Usability zu gewährleisten. Genau hier setzt die W3C Payment Request API Specification [1] an, um auch den Kunden kleinerer Händler (ohne eigene Entwicklungsabteilungen oder entsprechendes Budget) einen umfangreichen und dennoch einfach zu bedienenden Check-out zu ermöglichen. Der Bezahlvorgang wird so über die Grenzen eines einzelnen Shops hinaus harmonisiert.

Payment Request API

Die W3C Payment Request API Specification ist keine vollständige Implementierung für den Bezahlvorgang. Sie definiert ein standardisiertes API, das ein Payment-Method-Provider implementieren kann, um auf diese Weise Händlern eine standardisierte Integration von Bezahlverfahren zu ermöglichen. Der Händler beziehungsweise der Onlineshop ist also der Nutzer des API. Dahinter verbirgt sich der Anbieter eines Bezahlverfahrens, der Payment-Method-Provider. Theoretisch ist es dem Händler so möglich, unterschiedliche Bezahlverfahren, wie Kreditkarte, Lastschrift oder PayPal, in seinem Shop hinter einem einheitlichen API zu verbergen. Die aus der Diversität im Payment-Segment resultierende Komplexität, einzelne Verfahren anzubinden, bleibt jedoch bestehen. Häufig erfolgt daher die Anbindung über einen Payment-Service-Provider, der die unterschiedlichen Verfahren in der Rolle eines Payment-Method-Providers abstrahiert. Implementiert dieser das Payment Request API, kann der Shop, auch bei einem Anbieterwechsel, dem Kunden weiterhin ein einheitliches Check-out-Erlebnis mit einer entsprechend großen Auswahl an Bezahlverfahren bieten. Soll nur eine geringe Breite unterschiedlicher Bezahlverfahren angeboten werden, kann es auch eine Option sein, die Payment-Method-Provider ohne PSP direkt anzubinden. Zumindest sofern diese das Payment Request API unterstützen oder man auf einen klassischen, proprietären Check-out-Prozess setzt.

Das Payment Request API aus Abbildung 2 strukturiert sich entsprechend den am Bezahlprozess beteiligten Entitäten. Der Händler tritt in die Rolle des Payee, bezahlt durch den Endkunden, den Payer. Die Vermittlung der Bezahlung erfolgt durch die Payment Method/den Payment-Method-Provider. Im Kontext der in Abbildung 1 gezeigten Kreditkartenzahlung übernimmt ein PSP oder der Acquirer der Händlerbank diese Rolle. Auch wenn die Kreditkartenzahlung international betrachtet die erste Wahl bei Zahlungen im E-Commerce und entsprechend derzeit als einzige im Payment Request API voll unterstützt ist, ist sie operativ die komplexeste. Der Umgang mit Kreditkartendaten setzt eine Zertifizierung nach PCI DSS voraus. Die Anbindung erfolgt somit meistens über einen PSP. Nimmt ein PSP die Rolle des Payment-Me...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang