Mises à jour des API Web Payments

Tenez-vous informé des nouveautés des paiements sur le Web.

Danyao Wang
Danyao Wang
Rouslan Solomakhin
Rouslan Solomakhin

Les paiements Web sont disponibles publiquement 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 les paiements Web, consultez la présentation des paiements Web pour vous lancer.

Depuis le lancement de l'API Payment Request et de l'API Payment Handler, leurs spécifications respectives ont subi de nombreuses modifications. 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ée 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 de l'instrument

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 d'autres navigateurs. Assurez-vous de vérifier si la méthode hasEnrolledInstrument() est disponible dans le navigateur de l'utilisateur avant 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 (comme Google Pay) ne sont pas affecté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 auto-signé, vous pouvez désormais utiliser l'indicateur de ligne de commande --ignore-certificate-errors pour autoriser Chrome à accepter les API Web Payments dans votre environnement de développement. Si vous effectuez le développement à l'aide d'un serveur Web local qui n'est pas 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.