Bleiben Sie über die neuesten Entwicklungen bei Webzahlungen auf dem Laufenden.
Webzahlungen sind seit 2016 öffentlich in Browsern verfügbar. Die Hauptfunktion – die Payment Request API – ist jetzt in mehreren Browsern verfügbar: Chrome, Safari, Edge und bald auch Firefox. Wenn Sie noch keine Webzahlungen eingerichtet haben, sehen Sie sich den Hilfeartikel Webzahlungen – Übersicht an.
Seit der Einführung der Payment Request API und der Payment Handler API wurden an den jeweiligen Spezifikationen einige Änderungen vorgenommen. Diese Änderungen beeinträchtigen Ihren funktionierenden Code nicht, wir empfehlen Ihnen aber, sie zu beachten. In diesem Beitrag werden diese Updates zusammengefasst. Wir werden diese API-Änderungen kontinuierlich hinzufügen.
Neue Methode: hasEnrolledInstrument()
In der vorherigen Version der Payment Request API wurde canMakePayment() verwendet, um zu prüfen, ob das Zahlungsmittel des Nutzers vorhanden ist. In einem kürzlich erfolgten Update der Spezifikation wurde canMakePayment() durch hasEnrolledInstrument() ersetzt, ohne dass sich die Funktionalität geändert hat.
Die Methode hasEnrolledInstrument() wird von allen gängigen Browsern unterstützt.
Chrome hat sie in Version 74 implementiert. Sowohl Webkit als auch Gecko haben Tracking-Fehler, haben die Methode aber Stand Juni 2019 noch nicht implementiert.
Wenn Sie die neue Methode hasEnrolledInstrument() verwenden möchten, ersetzen Sie Code, der in etwa so aussieht:
// Checking for instrument presence.
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
Mit folgendem Code:
// Checking for instrument presence.
if (request.hasEnrolledInstrument) {
// hasEnrolledInstrument() is available.
request.hasEnrolledInstrument().then(handleInstrumentPresence).catch(handleError);
} else {
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
}
canMakePayment() prüft nicht mehr auf Vorhandensein eines Zahlungsmittels
Da hasEnrolledInstrument() jetzt die Prüfung des Zahlungsmittels des Nutzers übernimmt, wurde canMakePayment() aktualisiert, sodass nur noch die Verfügbarkeit der Zahlungs-App geprüft wird.
Diese Änderung an canMakePayment() ist an die Implementierung von hasEnrolledInstrument() gebunden. Seit Juni 2019 ist sie in Chrome 74 implementiert, jedoch nicht in anderen Browsern. Prüfen Sie, ob die hasEnrolledInstrument()-Methode im Browser des Nutzers verfügbar ist, bevor Sie versuchen, sie zu verwenden.
// Checking for payment app availability without checking for instrument presence.
if (request.hasEnrolledInstrument) {
// `canMakePayment()` behavior change corresponds to
// `hasEnrolledInstrument()` availability.
request.canMakePayment().then(handlePaymentAppAvailable).catch(handleError);
} else {
console.log("Cannot check for payment app availability without checking for instrument presence.");
}
languageCode von basic-card Zahlungsmethode entfernt
PaymentAddress.languageCode wurde aus den Versand- und Rechnungsadressen für basic-card entfernt. Die Rechnungsadressen anderer Zahlungsmethoden (z. B. Google Pay) sind davon nicht betroffen.
Diese Änderung wurde in Chrome 74, Firefox und Safari implementiert.
PaymentRequest.show() verwendet jetzt einen optionalen detailsPromise
Mit PaymentRequest.show() kann ein Händler eine Zahlungsanfrage-Benutzeroberfläche anzeigen, bevor der endgültige Gesamtbetrag bekannt ist. Der Händler hat zehn Sekunden Zeit, um das detailsPromise zu beheben, bevor ein Zeitlimit erreicht wird. Diese Funktion ist für einen schnellen serverseitigen Roundtrip vorgesehen.
Diese Funktion ist in Chrome 75 und Safari verfügbar.
// Not implemented in Chrome 74 and older.
// There's no way to feature-detect this, so check a few
// older versions of Chrome that you're seeing hit your servers.
if (/Chrome\/((6[0-9])|(7[0-4]))/g.exec(navigator.userAgent) !== null) {
return;
}
// Supported in Chrome 75+.
request.show(new Promise(function(resolveDetailsPromise, rejectDetailsPromise) {
// Find out the exact total amount and call
// `resolveDetailsPromise(details)`.
// Use a 3 second timeout as an example.
window.setTimeout(function() {
resolveDetailsPromise(details);
}, 3000); // 3 seconds.
}))
.then(handleResponse)
.catch(handleError);
PaymentRequestEvent.changePaymentMethod()
Mit der Payment Handler API-Funktion
PaymentRequestEvent.changePaymentMethod() lassen sich Zahlungsabwickler (z.B. Google Pay) auslösen, um den Ereignis-Handler onpaymentmethodchange auszulösen. changePaymentMethod() gibt ein Versprechen zurück, das zu einer Händlerantwort mit aktualisierten Preisinformationen führt (z.B. Neuberechnung der Steuern).
Sowohl das Ereignis PaymentRequestEvent.changePaymentMethod() als auch das Ereignis paymentmethodchange sind in Chrome 76 verfügbar. Webkit hat das Ereignis paymentmethodchange in der Technology Preview implementiert.
// In service worker context, `self` is the global object.
self.addEventListener('paymentrequest', (evt) => {
evt.respondWith(new Promise((confirmPaymentFunction, rejectPaymentFunction) => {
if (evt.changePaymentMethod === undefined) {
// Not implemented in this version of Chrome.
return;
}
// Notify merchant that the user selected a different payment method.
evt.changePaymentMethod('https://paymentapp.com', {country: 'US'})
.then((responseFromMerchant) => {
if (responseFromMerchant === null) {
// Merchant ignored the 'paymentmethodchange' event.
return;
}
handleResponseFromMerchant(responseFromMerchant);
})
.catch((error) => {
handleError(error);
});
}));
});
Beispiel für einen Händler:
if (request.onpaymentmethodchange === undefined) {
// Feature not available in this browser.
return;
}
request.addEventListener('paymentmethodchange', (evt) => {
evt.updateWith(updateDetailsBasedOnPaymentMethod(evt, paymentDetails));
});
Verbesserte lokale Entwicklung
Chrome 76 bietet zwei kleine Verbesserungen für die Produktivität von Entwicklern. Wenn in Ihrer lokalen Entwicklungsumgebung ein selbst signiertes Zertifikat verwendet wird, können Sie jetzt mit dem Befehlszeilenflag --ignore-certificate-errors festlegen, dass Chrome Web Payments APIs in Ihrer Entwicklungsumgebung zulässt. Wenn Sie mit einem lokalen Webserver entwickeln, der kein HTTPS unterstützt, können Sie auch das Flag --unsafely-treat-insecure-origin-as-secure=<origin> verwenden, damit Chrome den HTTP-Ursprung als HTTPS behandelt.