Tenez-vous au courant des nouveautés des paiements Web.
Les paiements Web sont disponibles dans les navigateurs depuis 2016. Sa fonctionnalité principale, l'API Payment Request, est désormais disponible sur plusieurs navigateurs: Chrome, Safari, Edge et bientôt Firefox. Si vous n'avez jamais utilisé les paiements Web, consultez la présentation des paiements Web pour commencer.
Depuis le lancement de l'API Payment Request et de l'API Payment Handler, de nombreuses modifications ont été apportées à leurs spécifications respectives. Ces modifications n'affecteront pas votre code, mais nous vous recommandons de les surveiller. Cet article récapitule ces mises à jour et continuera à accumuler les modifications apportées à l'API.
Nouvelle méthode: hasEnrolledInstrument()
Dans la version précédente de l'API Payment Request, canMakePayment() était utilisé pour vérifier la présence du mode de paiement de l'utilisateur. Dans une récente mise à jour de la spécification, canMakePayment() a été remplacé par hasEnrolledInstrument() sans modifier ses fonctionnalités.
La méthode hasEnrolledInstrument() est consensuelle de la part de tous les principaux navigateurs.
Chrome l'a implémentée dans la version 74, et Webkit et Gecko présentent des bugs de suivi, mais n'ont pas encore implémenté cette méthode depuis juin 2019.
Pour utiliser la nouvelle méthode hasEnrolledInstrument(), remplacez le code qui se présente comme suit:
// Checking for instrument presence.
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
Avec un code semblable à celui-ci:
// Checking for instrument presence.
if (request.hasEnrolledInstrument) {
// hasEnrolledInstrument() is available.
request.hasEnrolledInstrument().then(handleInstrumentPresence).catch(handleError);
} else {
request.canMakePayment().then(handleInstrumentPresence).catch(handleError);
}
canMakePayment() ne vérifie plus la présence d'instruments
Étant donné que hasEnrolledInstrument() gère désormais la vérification du mode de paiement de l'utilisateur, canMakePayment() a été mis à jour pour ne vérifier que la disponibilité de l'application de paiement.
Cette modification de canMakePayment() est liée à l'implémentation de hasEnrolledInstrument(). Depuis juin 2019, elle est implémentée dans Chrome 74, mais pas dans les autres navigateurs. Assurez-vous que la méthode hasEnrolledInstrument() est disponible dans le navigateur de l'utilisateur avant d'essayer de l'utiliser.
// 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 supprimé du mode de paiement basic-card
PaymentAddress.languageCode a été supprimé des adresses de livraison et de facturation pour basic-card. Les adresses de facturation des autres modes de paiement (tels que Google Pay) ne sont pas affectées.
Ce changement a été implémenté dans Chrome 74, Firefox et Safari.
PaymentRequest.show() accepte désormais un detailsPromise facultatif
PaymentRequest.show() permet à un marchand de présenter une UI de demande de paiement avant que le total final ne soit connu. Le marchand dispose de 10 secondes pour résoudre l'erreur detailsPromise avant l'expiration du délai. Cette fonctionnalité est destinée à un aller-retour rapide côté serveur.
Cette fonctionnalité est disponible dans Chrome 75 et Safari.
// 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()
La fonctionnalité de l'API Payment Handler PaymentRequestEvent.changePaymentMethod() permet aux gestionnaires de paiement (par exemple, Google Pay) pour déclencher le gestionnaire d'événements onpaymentmethodchange. changePaymentMethod() renvoie une promesse qui se résout en réponse du marchand avec des informations de prix mises à jour (par exemple, un recalcul des taxes).
PaymentRequestEvent.changePaymentMethod() et l'événement paymentmethodchange sont tous deux disponibles dans Chrome 76, et Webkit a implémenté l'événement paymentmethodchange dans sa technologie Preview.
// 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);
});
}));
});
Exemple pour un marchand:
if (request.onpaymentmethodchange === undefined) {
// Feature not available in this browser.
return;
}
request.addEventListener('paymentmethodchange', (evt) => {
evt.updateWith(updateDetailsBasedOnPaymentMethod(evt, paymentDetails));
});
Amélioration du développement local
Chrome 76 ajoute deux petites améliorations pour améliorer la productivité des développeurs. Si votre environnement de développement local utilise un certificat autosigné, vous pouvez désormais utiliser l'indicateur de ligne de commande --ignore-certificate-errors pour que Chrome autorise les API Web Payments dans votre environnement de développement. Si vous développez à l'aide d'un serveur Web local non compatible avec HTTPS, vous pouvez également utiliser l'indicateur --unsafely-treat-insecure-origin-as-secure=<origin> pour que Chrome traite l'origine HTTP comme HTTPS.