Cycle de vie d'une transaction de paiement

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

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

Pour en savoir plus sur les avantages des paiements Web, consultez la page applications de paiement avec paiements Web.

Cet article explique comment effectuer un paiement sur le site Web d'un marchand et vous aide à comprendre comment fonctionne l'intégration des applications de paiement.

Ce processus comporte six étapes:

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

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

  4. Le navigateur lance l'application de paiement.

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

  5. Si le client modifie des détails (comme les options de livraison ou leurs ), le marchand met à jour les détails de la transaction en conséquence.

    Schéma montrant le client choisissant une autre option de livraison dans la fenêtre modale de l'application BobPay. Un second diagramme montre que le marchand met à jour le coût total affiché dans BobPay.

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

    Schéma montrant le client qui appuie sur le bouton

Étape 1: Le marchand effectue une transaction de paiement

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

  • les modes de paiement acceptés et leurs données pour traiter la transaction ;
  • Informations telles que le prix total (obligatoire) et les informations sur les articles
  • Options permettant aux marchands de demander des informations de livraison (par exemple, des informations de livraison) et une option de livraison.
  • Les marchands peuvent également demander l'adresse de facturation, le nom du payeur, son adresse e-mail et numéro de téléphone.
  • Les marchands peuvent également inclure un attribut de livraison facultatif d'entraînement (shipping, delivery ou pickup) dans le PaymentRequest. Application de paiement vous pouvez l'utiliser comme indice pour afficher les étiquettes appropriées dans son UI.
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'
});
Inclure un ID de transaction

Certains gestionnaires de paiement peuvent demander au marchand de fournir l'ID de transaction. émis à l'avance dans les informations relatives à la transaction. A L'intégration standard inclut la communication entre le marchand et le serveur du gestionnaire de paiement pour réserver le prix total. Cela empêche les logiciels malveillants les clients de manipuler le prix et de duper le marchand à la fin de la transaction.

Le marchand peut transmettre un ID de transaction dans l'événement PaymentMethodData data de l'objet.

Si les informations de transaction sont fournies, le navigateur effectue une détection des applications de paiement spécifiées dans les PaymentRequest en fonction du paiement les identifiants de méthode. 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 la section Configurer un paiement méthode.

Étape 2: Le marchand affiche un bouton de paiement

Les marchands acceptent de nombreux modes de paiement, mais ils ne doivent présenter que le mode de paiement des boutons pour ceux qu’un client peut réellement utiliser. Affichage d'un bouton de paiement qui est inutilisable est une mauvaise expérience utilisateur. Si un marchand peut prédire qu'un le mode de paiement spécifié dans l'objet PaymentRequest ne fonctionne pas au client, il peut proposer une solution de remplacement ou ne pas afficher ce bouton du tout.

À l'aide d'une instance PaymentRequest, un marchand peut demander si un client a l'application de paiement disponible.

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

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

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 le show() de l'instance PaymentRequest, qui déclenche immédiatement le lancement de l'UI de paiement.

Si le prix total final est défini de façon dynamique (par exemple, à partir d'un serveur), le marchand peut différer le lancement de l'interface utilisateur de paiement jusqu'à ce que le total soit est connue.

Reporter le lancement de l'interface utilisateur de paiement

Regardez une démonstration pour différer le paiement UI jusqu'à ce que le prix total final soit déterminé.

Pour différer l'interface utilisateur 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 le la transaction est prête à démarrer.

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 en tant qu'argument pour show(), le navigateur lancer immédiatement l'interface de paiement.

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

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

La création d'une application de paiement dépend en grande partie du développeur, mais les événements émis par et vers le marchand, ainsi que la structure des données transmis avec ces événements, sont normalisés.

Lorsque l'application de paiement est lancée, elle reçoit la transaction. informations transmis à l'objet PaymentRequest à l'étape 1, qui comprend les éléments suivants:

  • Données du mode de paiement
  • Prix total
  • Options de paiement

L'application de paiement utilise les informations de transaction pour étiqueter son UI.

Étape 5: Mettre à jour les détails de la transaction en fonction des actions du client

Les clients ont la possibilité de modifier les détails de la transaction, comme le 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 modification du 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 modification du mode de paiement

Une application de paiement peut accepter plusieurs modes de paiement, et un marchand peut proposer un une remise spéciale en fonction de la sélection du client. Pour couvrir ce cas d'utilisation, l'événement de modification du mode de paiement peut informer le marchand du nouveau paiement. pour mettre à jour le prix total avec la remise et la 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 éventuellement fournir l'adresse de livraison du client. C'est ce qui est pratique pour les clients, car ils n'ont pas à saisir manuellement les détails. dans un formulaire et enregistrer leur adresse de livraison dans le mode de paiement applications, plutôt que sur plusieurs sites marchands différents.

Si un client modifie son adresse de livraison dans une application de paiement après le la transaction a été effectuée, un événement 'shippingaddresschange' sera envoyé au marchand. Cet événement aide le marchand à déterminer les frais de port en fonction à la nouvelle adresse, mettez à jour le prix total, puis renvoyez-le dans l'application de paiement.

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

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

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

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

  • Livraison standard – Sans frais
  • Livraison express – 5 EUR

Lorsqu'un client modifie l'option de livraison dans une application de paiement, une 'shippingoptionchange' événement sera envoyé au marchand. Le marchand peut déterminez les frais de port, mettez à jour le prix total et renvoyez-le application de paiement.

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

Le marchand peut modifier les options de livraison de façon dynamique en fonction des adresse de livraison également. Cette fonctionnalité est utile lorsqu'un marchand souhaite proposer différentes 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 le flux 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'ils peuvent utiliser pour valider leur identité.

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, le mode 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, il est possible que l'interface utilisateur du navigateur affiche encore un indicateur de chargement, ce qui signifie 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 la promesse renvoyée par show() rejette et le navigateur résilie le paiement transaction.

Traitement et validation du paiement...

details dans PaymentResponse correspond à l'objet d'identifiant de paiement renvoyé. depuis 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 relancer la transaction

Une fois que le marchand a déterminé si la transaction a réussi ou échoué, il peut opter pour l'une des solutions suivantes:

  • Appelez la méthode .complete() pour terminer la transaction et ignorer la indicateur de chargement.
  • Permettez 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