Temps de lecture estimé : 6 min · Publié le
Relier le retour du paiement à l’état de la commande
La page de retour, le prestataire de paiement et le système de commandes décrivent des étapes distinctes. Le mécanisme exact dépend de l’intégration retenue ; les notifications doivent être vérifiées avant de produire un effet métier.
- Commande
Le serveur établit les éléments et le montant à traiter.
- Paiement
Le prestataire traite l’opération selon son parcours.
- Rapprochement
Le site vérifie le statut et la correspondance avec la commande.
- Confirmation
Le résultat confirmé est répercuté dans le suivi de commande.
Scénarios pédagogiques fictifs à adapter à votre système. Cette page n’effectue aucune opération sur votre site.
Ouvrir la situation à vérifier
La page de retour affiche « merci »
- Ce que l’on sait
- Le texte seul ne démontre pas que le paiement a été validé.
- La vérification suivante
- Comparer la référence, le montant et le statut dans les systèmes concernés, avec les mécanismes de vérification documentés par le prestataire.
Une notification arrive deux fois
- Ce que l’on sait
- Une notification répétée ne doit pas déclencher deux fois le même effet prévu.
- La vérification suivante
- Tester ce cas dans l’environnement d’essai et contrôler l’unicité de la mise à jour, de l’expédition ou du message associé.
Le visiteur ferme l’onglet après le paiement
- Ce que l’on sait
- Le retour navigateur peut manquer alors qu’un résultat existe côté prestataire.
- La vérification suivante
- Prévoir le rapprochement du statut indépendamment de cette seule visite, puis permettre de retrouver la commande sans demander un nouveau paiement à l’aveugle.
Les notifications arrivent dans un ordre différent
- Ce que l’on sait
- L’ordre de réception ne décrit pas nécessairement l’ordre des changements chez le prestataire.
- La vérification suivante
- Tester les événements dans un autre ordre et rapprocher l’état confirmé de l’objet concerné. Ne pas déduire l’ordre fiable ou l’unicité du seul horodatage de création d’un événement.
- Trace à conserver
- Références d’événements de test, objet et commande liés, ordre reçu, état vérifié et effet produit une seule fois.
Référence technique : Stripe · Webhooks · Consultée le .
Préparer une petite matrice de commandes
Choisissez des produits représentatifs : produit disponible, variante, faible stock, article indisponible et panier avec plusieurs lignes. Ajoutez les zones et modes de livraison réellement proposés. Pour chaque scénario, écrivez le total attendu et la personne qui recevra la commande.
Vérifiez que la fiche indique les informations nécessaires à la décision et que le panier conserve variante, quantité et prix affichés. Les frais ajoutés plus tard dans le tunnel doivent rester explicables. Utilisez des données de test ou un environnement prévu à cet effet pour ne pas créer de fausses ventes.
- Produit simple, variante et rupture couverts.
- Montant et livraison attendus consignés.
- Environnement ou mode de test identifié.
Observer le paiement et ses échecs
Exécutez paiement accepté, refus et abandon avec le mode de test documenté du prestataire. Exemple fictif : le paiement réussit mais le navigateur se ferme avant le retour ; l’équipe doit retrouver la transaction et la commande sans demander un second paiement par défaut. Rejouez double clic et notification répétée, puis comparez les états client et administration. Une page de réussite ne suffit pas à valider le traitement.
Contrôlez les messages en cas d’erreur : le client doit savoir si sa commande a été créée, s’il peut réessayer et vers qui se tourner. Les justificatifs, courriels et données de paiement doivent suivre la configuration réelle du prestataire choisi, qui est à vérifier dans sa documentation actuelle.
- Succès, refus et abandon observés.
- État de commande cohérent côté client et administration.
- Aucune confirmation trompeuse après un échec.
Suivre la commande après le clic final
Testez l’avis envoyé au client, la notification à l’équipe, la préparation, le suivi de livraison et la demande d’assistance. Vérifiez qui corrige une adresse ou annule une commande, et comment la modification est tracée. Les courriels doivent refléter les conditions effectivement publiées sur le site.
Prévoyez aussi un essai de retour ou de remboursement selon les modalités de vente réellement applicables. Les règles peuvent dépendre du produit, du pays et du contrat ; faites valider les textes commerciaux et juridiques par les personnes compétentes. Le guide du catalogue aide à préparer les données en amont.
- Notifications reçues et comprises.
- Responsable de préparation et d’assistance nommé.
- Retour et remboursement essayés selon le cas.
Décider de la mise en ligne
Pour décider de publier, rapprochez chaque scénario du résultat attendu, de la preuve et du responsable de correction. Exemple fictif : un remboursement partiel est déclenché ; vérifiez montant, statut, message et éventuel effet sur le stock selon la règle définie. Une incohérence de prix, paiement, disponibilité ou confirmation doit être résolue avant d’ouvrir le parcours concerné. Les détails visuels secondaires peuvent suivre un autre calendrier.
Après publication, refaites une commande contrôlée sur le site réel si le prestataire de paiement le permet. Surveillez les premières commandes avec la personne qui les traite : des tests réussis en préproduction ne prouvent pas que les notifications et intégrations de production sont identiques.
- Grille de recette signée par la personne responsable.
- Blocages corrigés avant ouverture des ventes.
- Premier contrôle en production planifié.
Préparer quatre essais de notifications de paiement
Exemple d’intégration Stripe en environnement de test : la notification reçue sert à rapprocher un événement et une commande. Vérifiez la signature avec le corps brut de la requête et le secret de l’endpoint, selon le SDK retenu. Le seul retour du navigateur ne suffit pas à cette vérification.
Faites défiler le tableau horizontalement pour lire toutes les colonnes. Au clavier, placez le focus sur le tableau puis utilisez les flèches.
| Essai | Comportement attendu | Preuve utile |
|---|---|---|
| Signature invalide | Aucune mise à jour métier fondée sur cette notification. | Échec de vérification identifié, sans exposer le secret dans les journaux. |
| Même événement reçu deux fois | Une seule exécution de l’effet métier prévu. | Identifiant d’événement reconnu et commande non traitée deux fois. |
| Événements reçus dans un ordre différent | Le traitement ne dépend pas de leur ordre d’arrivée. | État rapproché avec l’objet pertinent chez le prestataire. |
| Onglet fermé après paiement | La commande reste vérifiable sans imposer un nouveau paiement. | Référence de commande reliée à l’état confirmé côté prestataire. |
- Stripe · Webhooks
Stripe documente les signatures, les livraisons répétées et l’absence de garantie d’ordre. Ces essais ne déclenchent ici aucune transaction et doivent être adaptés à votre intégration.
Documents de référence
- Stripe · Webhooks · Source consultée
- Stripe : Testing (exemple propre à ce prestataire)
Contenu mis à jour le