Cycle de vie d'une transaction de paiement

Découvrez comment les marchands intègrent des applications de paiement et comment les transactions de paiement fonctionnent avec l'API Payment Request.

Les API Web Payments sont des fonctionnalités de paiement dédiées intégrées au navigateur pour la première fois. Avec les paiements Web, l'intégration des marchands aux applications de paiement devient plus simple, tandis que l'expérience client est simplifiée et sécurisée.

Pour en savoir plus sur les avantages de l'utilisation des paiements Web, consultez Faciliter les paiements dans les applications avec les paiements Web.

Cet article vous explique comment se déroule une transaction de paiement sur le site Web d'un marchand et vous aide à comprendre le fonctionnement de l'intégration d'une application de paiement.

Ce processus comprend six étapes:

  1. Le marchand lance une transaction de paiement.
  2. Le marchand affiche un bouton de paiement.
  3. Le client appuie sur le bouton de paiement.

    Schéma d'un site Web de fromagerie avec un bouton BobPay (application de paiement).

  4. Le navigateur lance l'application de paiement.

    Diagramme du site Web de la fromagerie avec l'application BobPay lancée dans une fenêtre modale. La fenêtre modale affiche les options de livraison et le coût total.

  5. Si le client modifie des informations (par exemple, les options de livraison ou son adresse), le marchand met à jour les détails de la transaction pour refléter le changement.

    Diagramme montrant le client choisissant une autre option de livraison dans la fenêtre modale de l'application BobPay. Deuxième diagramme montrant le marchand mettant à jour le coût total affiché dans BobPay.

  6. Une fois que le client a confirmé l'achat, le marchand valide le paiement et finalise la transaction.

    Schéma illustrant le client appuyant sur le

Étape 1: Le marchand lance une transaction de paiement

Lorsqu'un client décide d'effectuer un achat, le marchand lance la transaction de paiement en créant un objet PaymentRequest. Cet objet inclut des informations importantes sur la transaction:

  • Modes de paiement acceptés et données associées pour traiter la transaction
  • des informations, telles que le prix total (obligatoire) et des informations sur les articles.
  • Options dans lesquelles les marchands peuvent demander des informations de livraison, telles qu'une adresse de livraison et une option de livraison.
  • Les marchands peuvent également demander l'adresse de facturation, le nom, l'adresse e-mail et le numéro de téléphone du payeur.
  • Les marchands peuvent également inclure un type de livraison facultatif (shipping, delivery ou pickup) dans PaymentRequest. L'application de paiement peut utiliser cela comme indice pour afficher les libellés appropriés dans son interface utilisateur.
const request = new PaymentRequest([{
  supportedMethods: 'https://bobpay.xyz/pay',
  data: {
    transactionId: '****'
  }
}], {
  displayItems: [{
    label: 'Anvil L/S Crew Neck - Grey M x1',
    amount: { currency: 'USD', value: '22.15' }
  }],
  total: {
    label: 'Total due',
    amount: { currency: 'USD', value : '22.15' }
  }
}, {
  requestShipping: true,
  requestBillingAddress: true,
  requestPayerEmail: true,
  requestPayerPhone: true,
  requestPayerName: true,
  shippingType: 'delivery'
});

Certains gestionnaires de paiement peuvent demander au marchand de fournir l'ID de transaction qu'il a émis à l'avance dans les informations de transaction. Une intégration typique inclut la communication entre le serveur du marchand et celui du processeur de paiement pour réserver le prix total. Cela empêche les clients malveillants de manipuler le prix et de tromper le marchand avec une validation à la fin de la transaction.

Le marchand peut transmettre un ID de transaction dans la propriété data de l'objet PaymentMethodData.

Une fois les informations de transaction fournies, le navigateur effectue un processus de découverte des applications de paiement spécifiées dans le PaymentRequest en fonction des identifiants de mode de paiement. De cette façon, le navigateur peut déterminer l'application de paiement à lancer dès que le marchand est prêt à effectuer la transaction.

Pour en savoir plus sur le fonctionnement du processus de découverte, consultez Configurer une méthode de paiement.

Étape 2: Le marchand affiche un bouton de paiement

Les marchands peuvent accepter de nombreux modes de paiement, mais ne doivent présenter que les boutons de paiement pour ceux qu'un client peut réellement utiliser. Afficher un bouton de paiement inutilisable est une mauvaise expérience utilisateur. Si un marchand peut prévoir qu'un mode de paiement spécifié dans l'objet PaymentRequest ne fonctionnera pas pour le client, il peut fournir une solution de remplacement ou ne pas afficher ce bouton du tout.

À l'aide d'une instance PaymentRequest, un marchand peut interroger un client pour savoir s'il dispose de l'application de paiement.

Le client dispose-t-il de l'application de paiement ?

La méthode canMakePayment() de PaymentRequest renvoie true si une application de paiement est disponible sur l'appareil du client. "Disponible" signifie qu'une application de paiement compatible avec le mode de paiement est détectée, que l'application de paiement spécifique à la plate-forme est installée ou que l'application de paiement basée sur le Web est prête à être enregistrée.

const canMakePayment = await request.canMakePayment();
if (!canMakePayment) {
  // Fallback to other means of payment or hide the button.
}

Étape 3: Le client appuie sur le bouton de paiement

Lorsque le client appuie sur le bouton de paiement, le marchand appelle la méthode show() de l'instance PaymentRequest, ce qui déclenche immédiatement le lancement de l'UI de paiement.

Si le prix total final est défini de manière dynamique (par exemple, récupéré à partir d'un serveur), le marchand peut différer le lancement de l'UI de paiement jusqu'à ce que le total soit connu.

Différer le lancement de l'UI de paiement

Découvrez une démonstration de la différaction de l'interface utilisateur de paiement jusqu'à ce que le prix total final soit déterminé.

Pour différer l'UI de paiement, le marchand transmet une promesse à la méthode show(). Le navigateur affiche un indicateur de chargement jusqu'à ce que la promesse soit résolue et que la transaction soit prête à commencer.

const getTotalAmount = async () => {
  // Fetch the total amount from the server, etc.
};

try {
  const result = await request.show(getTotalAmount());
  // Process the result…
} catch(e) {
  handleError(e);
}

Si aucune promesse n'est spécifiée comme argument pour show(), le navigateur lance immédiatement l'UI de paiement.

Étape 4: Le navigateur lance l'application de paiement

Le navigateur peut lancer une application de paiement spécifique à la plate-forme ou une application Web. (Pour en savoir plus sur la manière dont Chrome détermine l'application de paiement à lancer, consultez cette page.)

La manière dont l'application de paiement est créée dépend principalement du développeur, mais les événements émis et reçus par le marchand, ainsi que la structure des données transmises avec ces événements, sont standardisés.

Lorsque l'application de paiement est lancée, elle reçoit les informations de transaction transmises à l'objet PaymentRequest à l'étape 1, y compris les éléments suivants:

  • Données sur le mode de paiement
  • Prix total
  • Options de paiement

L'application de paiement utilise les informations de transaction pour ajouter des libellés à son interface utilisateur.

Étape 5: Comment un marchand peut-il mettre à jour les détails de la transaction en fonction des actions du client ?

Les clients peuvent modifier les détails de la transaction, tels que le mode de paiement et l'option de livraison, dans l'application de paiement. Pendant que le client apporte des modifications, le marchand reçoit les événements de modification et met à jour les détails de la transaction.

Un marchand peut recevoir quatre types d'événements:

  • Événement de changement de mode de paiement
  • Événement de modification de l'adresse de livraison
  • Événement de modification de l'option de livraison
  • Événement de validation du marchand

Événement de changement de mode de paiement

Une application de paiement peut prendre en charge plusieurs modes de paiement, et un marchand peut proposer une remise spéciale en fonction du mode de paiement sélectionné par le client. Pour couvrir ce cas d'utilisation, l'événement de modification du mode de paiement peut informer le marchand du nouveau mode de paiement afin qu'il puisse mettre à jour le prix total avec la remise et le renvoyer à l'application de paiement.

request.addEventListener('paymentmethodchange', e => {
  e.updateWith({
    // Add discount etc.
  });
});

Événement de modification de l'adresse de livraison

Une application de paiement peut fournir l'adresse de livraison du client en option. Cette fonctionnalité est pratique pour les clients, car ils n'ont pas besoin de saisir manuellement des informations dans un formulaire et peuvent stocker leur adresse de livraison dans leurs applications de paiement préférées plutôt que sur plusieurs sites Web de marchands différents.

Si un client modifie son adresse de livraison dans une application de paiement après le lancement de la transaction, un événement 'shippingaddresschange' est envoyé au marchand. Cet événement aide le marchand à déterminer les frais de port en fonction de la nouvelle adresse, à mettre à jour le prix total et à le renvoyer à l'application de paiement.

request.addEventListener('shippingaddresschange', e => {
  e.updateWith({
    // Update the details
  });
});

Si le marchand ne peut pas expédier la commande à l'adresse mise à jour, il peut envoyer un message d'erreur en ajoutant un paramètre d'erreur aux détails de la transaction renvoyés à l'application de paiement.

Événement de modification de l'option de livraison

Un marchand peut proposer plusieurs options de livraison au client et peut déléguer ce choix à l'application de paiement. Les options de livraison s'affichent sous la forme d'une liste de prix et de noms de services parmi lesquels le client peut choisir. Exemple :

  • Livraison standard : sans frais
  • Livraison express : 5 USD

Lorsqu'un client modifie l'option de livraison dans une application de paiement, un événement 'shippingoptionchange' est envoyé au marchand. Le marchand peut ensuite déterminer les frais de port, mettre à jour le prix total et le renvoyer à l'application de paiement.

request.addEventListener('shippingoptionchange', e => {
  e.updateWith({
    // Update the details
  });
});

Le marchand peut également modifier de manière dynamique les options de livraison en fonction de l'adresse de livraison du client. Cette fonctionnalité est utile lorsqu'un marchand souhaite proposer différents ensembles d'options de livraison pour les clients nationaux et internationaux.

Événement de validation du marchand

Pour plus de sécurité, une application de paiement peut effectuer une validation du marchand avant de passer au parcours de paiement. La conception du mécanisme de validation dépend de l'application de paiement, mais l'événement de validation du marchand sert à informer le marchand de l'URL qu'il peut utiliser pour se valider.

request.addEventListener('merchantvalidation', e => {
  e.updateWith({
    // Use `e.validateURL` to validate
  });
});

Étape 6: Le marchand valide le paiement et finalise la transaction

Lorsque le client autorise le paiement, la méthode show() renvoie une promesse qui se résout en PaymentResponse. L'objet PaymentResponse inclut les informations suivantes:

  • Détails du résultat du paiement
  • Adresse de livraison
  • Option de livraison
  • Coordonnées

À ce stade, l'UI du navigateur peut toujours afficher un indicateur de chargement, ce qui signifie que la transaction n'est pas encore terminée.

Si l'application de paiement est arrêtée en raison d'un échec ou d'une erreur de paiement, la promesse renvoyée par show() est rejetée et le navigateur arrête la transaction de paiement.

Traitement et validation du paiement

details dans PaymentResponse est l'objet d'identifiant de paiement renvoyé par l'application de paiement. Le marchand peut utiliser les identifiants pour traiter ou valider le paiement. Le fonctionnement de ce processus essentiel dépend du gestionnaire de paiement.

Finaliser ou réessayer la transaction

Une fois que le marchand a déterminé si la transaction a réussi ou échoué, il peut:

  • Appelez la méthode .complete() pour finaliser la transaction et ignorer l'indicateur de chargement.
  • Demandez au client de réessayer en appelant la méthode retry().
async function doPaymentRequest() {
  try {
    const request = new PaymentRequest(methodData, details, options);
    const response = await request.show();
    await validateResponse(response);
  } catch (err) {
    // AbortError, SecurityError
    console.error(err);
  }
}

async function validateResponse(response) {
  try {
    const errors = await checkAllValuesAreGood(response);
    if (errors.length) {
      await response.retry(errors);
      return validateResponse(response);
    }
    await response.complete("success");
  } catch (err) {
    // Something went wrong…
    await response.complete("fail");
  }
}
// Must be called as a result of a click
// or some explicit user action.
doPaymentRequest();

Étapes suivantes