Hier erfährst du, was es Neues bei Web Payments gibt.
Web Payments ist seit 2016 in Browsern öffentlich verfügbar. Die Kernfunktion – die Payment Request API – ist jetzt in mehreren Browsern verfügbar: Chrome, Safari, Edge und demnächst auch Firefox. Wenn du noch nie mit Webzahlungen gearbeitet hast, lies dir zuerst die Übersicht über Webzahlungen durch.
Seit der Einführung der Payment Request API und der Payment Handler API wurden einige Änderungen an den jeweiligen Spezifikationen vorgenommen. Durch diese Änderungen wird Ihr Arbeitscode nicht beeinträchtigt, aber wir empfehlen Ihnen, auf sie zu achten. In diesem Beitrag werden diese Aktualisierungen zusammengefasst und es werden diese API-Änderungen weiterhin gesammelt.
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. Bei einer kürzlichen Aktualisierung der Spezifikation wurde canMakePayment() durch hasEnrolledInstrument() ersetzt, ohne dass sich die Funktionalität ändert.
Die Methode hasEnrolledInstrument() ist in allen gängigen Browsern einvernehmlich.
Chrome hat sie in Version 74 implementiert und sowohl Webkit als auch Gecko haben Tracking-Fehler, sie wurde jedoch im Juni 2019 noch nicht implementiert.
Ersetzen Sie Code, der so aussieht, um die neue Methode hasEnrolledInstrument() zu verwenden:
// Checking for instrument presence.
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
Mit Code, der so aussieht:
// 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, ob ein Zahlungsmittel vorhanden ist
Da hasEnrolledInstrument() jetzt die Prüfung des Zahlungsmittels des Nutzers übernimmt, wurde canMakePayment() so aktualisiert, dass nur die Verfügbarkeit von Zahlungs-Apps geprüft wird.
Diese Änderung von canMakePayment() ist an die Implementierung von hasEnrolledInstrument() gebunden. Seit Juni 2019 ist sie in Chrome 74 implementiert, aber in keinen anderen Browsern. Prüfen Sie, ob die Methode hasEnrolledInstrument() im Browser des Nutzers verfügbar ist, bevor Sie sie 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 Versandadressen und Rechnungsadressen für basic-card entfernt. Die Rechnungsadressen anderer Zahlungsmethoden (z. B. Google Pay) sind nicht betroffen.
Diese Änderung wurde in Chrome 74, Firefox und Safari implementiert.
PaymentRequest.show() verwendet jetzt eine optionale detailsPromise
Mit PaymentRequest.show() kann ein Händler eine Benutzeroberfläche für Zahlungsaufforderungen anzeigen, bevor die endgültige Gesamtsumme bekannt ist. Der Händler hat zehn Sekunden Zeit, das Problem detailsPromise vor einer Zeitüberschreitung zu beheben. Diese Funktion ist für einen schnellen serverseitigen Wechsel gedacht.
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()
Die Payment Handler API-Funktion PaymentRequestEvent.changePaymentMethod() ermöglicht Zahlungs-Handlern (z.B. Google Pay), um den Ereignis-Handler onpaymentmethodchange auszulösen. changePaymentMethod() gibt ein Promise zurück, das zu einer Händlerantwort mit aktualisierten Preisinformationen (z.B. einer Steuerneuberechnung) aufgelöst wird.
Sowohl PaymentRequestEvent.changePaymentMethod() als auch das Ereignis paymentmethodchange sind in Chrome 76 verfügbar und Webkit hat das Ereignis paymentmethodchange in der Technologievorschau 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);
});
}));
});
Händlerbeispiel:
if (request.onpaymentmethodchange === undefined) {
// Feature not available in this browser.
return;
}
request.addEventListener('paymentmethodchange', (evt) => {
evt.updateWith(updateDetailsBasedOnPaymentMethod(evt, paymentDetails));
});
Verbesserte lokale Entwicklung
In Chrome 76 gibt es zwei kleine Verbesserungen, mit denen Entwickler produktiver arbeiten können. Wenn in deiner lokalen Entwicklungsumgebung ein selbst signiertes Zertifikat verwendet wird, kannst du jetzt mit dem Befehlszeilen-Flag --ignore-certificate-errors festlegen, dass Chrome Web Payments APIs in deiner Entwicklungsumgebung zulässt. Wenn du für die Entwicklung einen lokalen Webserver verwendest, der HTTPS nicht unterstützt, kannst du auch das Flag --unsafely-treat-insecure-origin-as-secure=<origin> verwenden, damit Chrome den HTTP-Ursprung als HTTPS behandelt.