Progressive Web Apps, Teil 4: Eine Frage des Geldes
Wenn PWAs die App-Stores der Plattformen überflüssig machen, stellt sich eine zentrale Frage: Wie kommen Entwickler oder Plattformanbieter dann an ihr Geld?
- Christian Liebel
Wenn Progressive Web Apps die App-Stores der Plattformen überflüssig machen, stellt sich eine zentrale Frage: Wie kommen Entwickler oder Plattformanbieter dann an ihr Geld? Doch auch daran wurde gedacht, denn im modernen Web gibt es für fast alles eine Schnittstelle: Mit der Payment Request API sollen künftig Onlineshops, Magazine, Websites oder eben Progressive Web Apps ihre Leistungen dem Benutzer gegenüber abrechnen können.
Die Website stellt dazu einen Payment Request, der Browser zeigt eine grafische Benutzeroberfläche dafür an. Ein zentraler Vorteil dieses Vorgehens ist, dass Plattformanbieter die Zahlungsinformationen der Benutzer bereits kennen – etwa, weil sich der Anwender dort schon registriert und Bankverbindung oder Anschrift hinterlegt hat. Dadurch entfällt die zeitintensive Eingabe der Daten, die üblicherweise bei jedem Checkout-Formular eines Webshops neu erfolgen muss.
Wie die Service Worker kann die Payment Request API verständlicherweise ausschließlich über Verbindungen genutzt werden, die über das Hypertext Transfer Protocol Secure (HTTPS) abgesichert sind. Und auch das Prinzip des Progressive Enhancements kann hier Anwendung finden: Wird die Payment Request API unterstützt, wird sie genutzt, andernfalls muss die Zahlung auf herkömmliche Art und Weise abgewickelt werden, über ein Checkout-Formular und eventuell einem Roundtrip zu einem Zahlungsdienstleister. Das folgende Listing zeigt das Vorgehen:
if(window.PaymentRequest) {
const supportedPaymentMethods = [{
supportedMethods: ['basic-card'],
data: { supportedNetworks: ['mastercard', 'visa'] }
}];
const paymentDetails = {
total: {
label: 'Reiseführer "Baustellen',
amount: { currency: 'EUR', value: '47.11' }
}
};
const options = { requestPayerName: true };
const request = new PaymentRequest(supportedPaymentMethods,
paymentDetails, options);
request.show()
.then(res => {
finishPurchase(res.details.cardNumber, res.details.billingAddress)
.then(() => res.complete('success'));
})
.catch(err => console.error(err));
} else {
window.location.href = 'checkout.php';
}
Der Konstruktor des PaymentRequest nimmt drei Parameter entgegen: Einmal die unterstützten Zahlungsmittel, dann die Details zur Zahlung, sprich den Gesamtpreis und optionale Rechnungspositionen sowie weitere Konfiguration. Im vorliegenden Beispiel werden MasterCard- und Visa-Karten unterstützt. In den Zahlungsdetails wird nur die verpflichtende Gesamtposition aufgeführt. Das Konfigurationsobjekt teilt dem Browser mit, dass der Name des Zahlenden unbedingt anzugeben ist. Wichtig: Die Payment Request API führt keinerlei Plausibilitätsprüfung durch. Der Payment Request muss durch die Webanwendung bereits korrekt erstellt werden, so sind beispielsweise Einzelpositionen korrekt zum Gesamtpreis aufzuaddieren.
Durch den Aufruf der Methode show auf der erzeugten Instanz des PaymentRequest zeigt der Browser einen Zahlungsdialog an. Wird der Dialog bestätigt, stehen Entwicklern Zugriff auf die eingegebenen Daten zur Verfügung, welche diese dann an den jeweiligen Zahlungsanbieter weiterleiten und die Zahlung durchführen können. Ebenso können sich Entwickler auf die Ereignisse shippingoptionchange oder shippingaddresschange binden und die Versandkosten je nach ausgewählter Adresse oder Versandoption aktualisieren.
Unterstützt wird die Payment Request API derzeit durch Microsoft Edge, ohne Feature-Flag seit Version 15. Auf mobilen Ausgaben von Google Chrome steht die Schnittstelle seit Version 53 zur Verfügung. Die Unterstützung für Desktopausgaben von Google Chrome ohne Aktivierung eines Feature-Flag folgt mit der kommenden Version 60. Safari kennt stattdessen nur das proprietäre Apple Pay JS, für das Google einen Wrapper anbietet. Unter Firefox wird die Payment Request API ab der kommenden Version 55 hinter einem Feature-Flag eingeführt.
Mit der Payment Request API wäre also auch dieser betriebswirtschaftliche Aspekt in der Anwendungsentwicklung bedacht. Anbieter mobiler Plattformen können dem Anwender ein konsistentes Interface anbieten, das dieser auch von den nativen App-Stores kennt. Auch Anbieter von Webshops kommt diese Schnittstelle entgegen, da sie den Checkout-Prozess verkürzt. Bleibt also die Gesamtabwägung über Progressive Web Apps zu treffen. Der Abschluss der kleinen Serie rund um PWA folgt in der kommenden Woche. ()
