Tenez-vous informé des nouveautés des paiements sur le Web.
Les paiements Web sont accessibles au public dans les navigateurs depuis 2016. La fonctionnalité de base, l'API Payment Request, est désormais disponible dans plusieurs navigateurs : Chrome, Safari, Edge et bientôt Firefox. Si vous ne connaissez pas encore 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, un certain nombre de modifications ont été apportées à leurs spécifications respectives. Ces modifications ne perturberont pas votre code, mais nous vous recommandons de les surveiller. Cet article résume ces mises à jour et continuera d'accumuler ces modifications d'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 de l'instrument de paiement de l'utilisateur. Dans une mise à jour récente de la spécification, canMakePayment() a été remplacé par hasEnrolledInstrument() sans modifier sa fonctionnalité.
La méthode hasEnrolledInstrument() est consensuelle pour tous les principaux navigateurs.
Chrome l'a implémenté dans la version 74. Webkit et Gecko présentent des bugs de suivi, mais n'ont pas encore implémenté la méthode en juin 2019.
Pour utiliser la nouvelle méthode hasEnrolledInstrument(), remplacez le code suivant:
// 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
Comme 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. Veillez à vérifier si 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é(e) de basic-card mode de paiement
PaymentAddress.languageCode a été supprimé des adresses de livraison et de facturation pour basic-card. Les adresses de facturation des autres modes de paiement (comme Google Pay) ne sont pas concernées.
Ce changement a été implémenté dans Chrome 74, Firefox et Safari.
PaymentRequest.show() utilise 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 le detailsPromise avant 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é PaymentRequestEvent.changePaymentMethod() de l'API Payment Handler 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 une réponse du marchand avec des informations sur les prix mises à jour (par exemple, un nouveau calcul des taxes).
PaymentRequestEvent.changePaymentMethod() et l'événement paymentmethodchange sont disponibles dans Chrome 76, et Webkit a implémenté l'événement paymentmethodchange dans son aperçu technologique.
// 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 de 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 apporte deux petites améliorations pour 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'option --unsafely-treat-insecure-origin-as-secure=<origin> pour que Chrome traite l'origine HTTP comme HTTPS.