Suspendre la relance et préciser ce qui est réellement payé
Un client indique avoir payé, le prestataire affiche une opération réussie, mais WooCommerce conserve En attente de paiement. Avant de modifier la commande, rapprochez les deux enregistrements. Le résultat recherché est un suivi fidèle d’un seul paiement, avec le stock et la préparation de commande cohérents. Une nouvelle tentative de paiement ne doit pas servir à vérifier la première.
Une ligne bancaire visible chez le client peut correspondre à une autorisation, c’est-à-dire une réservation de fonds, plutôt qu’à une capture. La capture est l’encaissement effectif par le prestataire ; le versement ultérieur vers le compte bancaire du commerçant constitue encore une autre étape. Ces états ne se déduisent pas du seul écran de remerciement ou d’une capture envoyée par le client.
Ce guide concerne une boutique utilisant déjà WooCommerce et une passerelle de paiement. Il faut un administrateur ou gestionnaire de boutique autorisé à lire les commandes, ainsi qu’un accès au bon compte du prestataire. Les modifications de connexion peuvent demander des droits supplémentaires. Sur un réseau multisite, vérifiez aussi le site de la boutique et non seulement l’identité du réseau. Sur WordPress.com, partez de WP Admin si la boutique y est installée ; les droits et fonctions de la passerelle restent ceux de cette boutique, sans accès automatique aux réglages serveur.
WooCommerce 11.2.1, gratuit et édité par Automattic, est la version examinée. Les minima déclarés sont WordPress 7.0 et PHP 7.4, avec un test jusqu’à WordPress 7.1.4. Les commandes et paiements relèvent de cette extension et de la passerelle, pas des fonctions natives de WordPress seul. Le guide ne demande aucune installation supplémentaire pour commencer. Ces minima techniques ne conseillent pas l’usage d’une ancienne version PHP.
Choisir entre confirmation normale, notification manquante et correction exceptionnelle
Ouvrez la commande concernée et l’opération du prestataire côte à côte. Vérifiez d’abord le montant, la devise, la date, le compte marchand et la référence. Un même numéro de commande peut exister sur une autre boutique ou une copie de test. Le nom du client et le montant seuls ne suffisent pas à établir un rapprochement certain.
Si le prestataire indique une autorisation non capturée, ne transformez pas la commande en paiement confirmé pour faire disparaître l’attente. Suivez le traitement documenté de ce paiement avec la personne responsable. Ce scénario se distingue du paiement déjà capturé visé ici. Un moyen à confirmation différée peut également attendre normalement un résultat bancaire.
Si la capture est confirmée sur le bon achat, examinez comment la passerelle transmet cette confirmation à WooCommerce. Le retour du navigateur et la notification entre serveurs sont deux échanges différents. Un client peut fermer l’onglet ou perdre sa connexion tandis que le prestataire poursuit le traitement. La commande doit donc être rapprochée indépendamment de son seul parcours visuel.
Privilégiez la remise en état du mécanisme de confirmation, puis vérifiez les commandes affectées. Une modification manuelle peut exceptionnellement rétablir l’organisation commerciale d’une commande bien identifiée ; elle ne répare pas le transport des notifications pour les suivantes et ne reproduit pas nécessairement toutes les opérations techniques de la passerelle.
Lisez le libellé exact : En attente de paiement ou Pending payment n’est pas En attente ou On hold, qui peut correspondre à une confirmation différée normale. Un brouillon de commande du parcours par blocs n’est pas non plus une preuve de capture. Conservez ce statut initial dans le dossier avant de choisir une action.
- Paiement non capturé ou encore en traitement : conserver un état fidèle et suivre la procédure propre au moyen utilisé.
- Paiement capturé et référence certaine : rechercher la confirmation reçue, refusée ou différée.
- Paiement capturé mais rapprochement incertain : conserver le dossier en vérification sans réclamer un second débit.
- Commande remboursée, annulée ou litigieuse : examiner cette situation avant toute remise en préparation.
Parcours 1 : établir le rapprochement dans la commande
Dans WooCommerce, Commandes, recherchez l’entrée à partir des informations convenues, puis ouvrez-la. Relevez son numéro, son total, sa devise, le moyen utilisé et l’identifiant de transaction lorsqu’il est enregistré. Lisez les Notes de commande dans l’ordre : elles peuvent distinguer demande de paiement, autorisation, capture, refus et changements de statut.
Dans l’espace du prestataire, sélectionnez le bon compte et le bon environnement, réel ou test. Ouvrez la transaction correspondante et cherchez sa référence de commande ou ses métadonnées. Vérifiez le montant capturé, pas seulement le montant initial demandé. Contrôlez aussi un éventuel remboursement déjà effectué ou une autre commande associée au même achat.
Dans Notes de commande, saisissez une note de rapprochement avec la référence, le montant et la devise vérifiés, l’heure de contrôle et le résultat. Dans la liste de type de note, choisissez Note privée ou Private note, puis Ajouter ou Add. Ne choisissez pas Note au client pour vos éléments internes, et ne consignez ni numéro complet de carte ni secret de connexion.
Si plusieurs commandes semblent correspondre au même achat, identifiez laquelle porte la transaction avant de modifier les autres. Une commande en attente et une commande payée peuvent résulter d’une seconde tentative. Les passer toutes deux en préparation créerait un risque de double expédition, même s’il n’existe qu’un seul encaissement.
Le résultat attendu est un lien explicite entre la bonne commande et la bonne opération. Ce parcours de lecture n’a pas de changement de statut à annuler. Si le rapprochement n’est pas certain, gardez les références disponibles et faites clarifier le cas par le responsable du compte marchand. N’utilisez ni Capturer ni Rembourser comme boutons de diagnostic.
Retrouver la confirmation entrante et son traitement
Une notification entrante, souvent appelée webhook, est un message envoyé par le prestataire vers votre boutique pour signaler un événement de paiement. Elle ne se configure pas nécessairement dans WooCommerce, Réglages, Avancé, Webhooks : cette zone sert aux notifications que la boutique envoie à d’autres systèmes. Créer un webhook de commande sortant n’apprend pas à WooCommerce qu’un prestataire a encaissé.
Chez Stripe, ouvrez Workbench > Webhooks, sélectionnez la destination de cette boutique puis Event deliveries. Ouvrez l’événement correspondant pour relever son identifiant, le code HTTP et les tentatives de livraison. Vérifiez le compte, le mode et l’URL de destination. Avec une autre passerelle, utilisez son journal d’événements équivalent. Une protection par mot de passe, une URL ancienne ou une redirection peut bloquer la réception ; ouvrir l’URL dans votre navigateur ne reproduit pas la notification signée.
Dans WooCommerce, État, Journaux, ouvrez le fichier de la passerelle à l’heure concernée, puis les erreurs fatales si nécessaire. Recherchez une signature refusée, une commande introuvable, un verrouillage ou un traitement différé. Les journaux ne peuvent pas reconstituer des événements antérieurs à leur activation. Gardez les secrets et données client hors d’un rapport public.
Une réponse HTTP réussie ne prouve pas une validation commerciale. Dans l’extension Stripe 11.1.1 examinée, certains refus de validation peuvent recevoir 204, et un événement destiné à un autre compte peut être ignoré avec 200. D’autres événements sont traités plus tard. Croisez donc livraison, journal et commande. Si le journal cite un traitement différé, ouvrez WooCommerce > État > Actions planifiées et recherchez l’action correspondante, par exemple wc_stripe_deferred_webhook. N’exécutez pas toute la file et n’effacez pas les échecs.
Le résultat attendu est de savoir si la confirmation n’a jamais atteint le site, a été refusée ou attend un traitement. Si une règle réseau est en cause, faites corriger sa portée sur la destination documentée de la passerelle. Ne retirez pas la validation des signatures et ne désactivez pas tout le pare-feu pour accepter n’importe quel message.
Parcours 2 : vérifier la connexion de l’extension Stripe existante
Cet exemple concerne précisément WooCommerce Stripe Payment Gateway, éditée par WooCommerce, version vérifiée 11.1.1. Sa fiche déclare WordPress 6.9, PHP 7.4 et un test jusqu’à WordPress 7.1.4. L’extension est gratuite ; l’usage du service de paiement possède ses propres conditions et frais. Elle ne doit pas être installée pour remplacer une autre passerelle pendant ce diagnostic.
Avec les droits nécessaires, ouvrez WooCommerce > Réglages > Paiements > Stripe > Settings. Dans Account details, cliquez Configure connection. Examinez Live pour le mode réel et Test pour le mode d’essai : le statut de configuration attendu est Configured. Vérifiez que le compte connecté porte la transaction. Ce libellé indique une configuration présente, pas le traitement réussi de chaque événement passé.
Si les notifications de cette extension ont été supprimées ou sont mal configurées, la commande Reconfigure webhooks permet de les recréer dans le mode sélectionné. Cette opération remplace les anciennes destinations pointant vers le site. Relevez la configuration avant d’agir et n’utilisez cette commande qu’après identification de la bonne boutique et du bon compte.
Ne supprimez pas toutes les destinations du compte Stripe : d’autres applications peuvent les utiliser. L’extension documente une adresse de type https://boutique.exemple/?wc-api=wc_stripe, à comparer à l’adresse réellement générée pour votre installation. Cet exemple n’est pas une destination à copier. Un sous-dossier ou un autre hôte doit être pris en compte. Préférez le parcours de reconfiguration propre à l’extension à une liste d’événements et un secret repris d’un autre environnement.
Le résultat attendu est une connexion correcte pour cette boutique et ce mode. Reconfigurer les notifications ne garantit pas la récupération automatique de tous les anciens paiements. Il faut encore contrôler les commandes touchées. En cas d’erreur de compte ou de destination, faites rétablir la configuration propre à cette intégration ; une ancienne clé de signature remplacée ne se répare pas par une simple annulation visuelle.
Relancer une notification précise sans relancer le paiement
Après correction de la réception, un prestataire peut permettre une nouvelle livraison du même événement. Cette opération diffère d’une nouvelle tentative d’encaissement. Elle peut néanmoins déclencher des changements de commande et des automatisations : vérifiez le statut actuel juste avant, pour éviter d’agir sur une commande remboursée ou déjà traitée entre-temps.
Stripe permet actuellement Resend depuis le détail d’un événement jusqu’à quinze jours après sa création dans le tableau de bord. Si l’événement n’est plus disponible ou si la bonne destination ne peut pas être établie, faites examiner une récupération adaptée par le responsable de l’intégration. N’utilisez pas Send test event pour prétendre reconstituer un ancien encaissement réel.
Une nouvelle livraison manuelle n’annule pas nécessairement les tentatives automatiques déjà prévues par le prestataire. Attendez le résultat et relisez les notes de commande avant toute autre action. Les intégrations doivent gérer des notifications répétées, mais une automatisation personnalisée peut encore produire un effet indésirable ; ne multipliez pas les clics pour accélérer la réponse.
Le résultat attendu est la réception puis le traitement de la confirmation connue, sans nouvelle opération de paiement. Vérifiez le statut, la référence de transaction et les actions différées éventuelles. Si la livraison est acceptée mais que l’état reste incohérent, conservez la réponse et le journal : une nouvelle livraison identique n’est pas une réparation universelle d’une erreur interne.
Le retour arrière porte sur la configuration corrigée si elle était inadaptée. Il n’existe pas de bouton qui annule tous les effets d’une notification déjà traitée. C’est pourquoi le contrôle de la commande et de ses automatisations précède cette relance ciblée.
- Dans le bon compte et le bon mode Stripe, ouvrez Workbench > Webhooks, la destination exacte, puis Event deliveries.
- Ouvrez l’événement déjà rapproché et comparez de nouveau sa transaction avec l’état actuel de la commande. Arrêtez-vous si elle a été remboursée, annulée ou si les références diffèrent.
- Utilisez Resend une seule fois pour cette livraison autorisée, puis attendez son résultat. Ne relancez pas le paiement et ne recréez pas un événement au contenu modifié.
- Relisez le journal de la passerelle, les notes et le statut de commande ; contrôlez aussi l’action différée identifiée, s’il y en a une.
Parcours 3 : corriger un statut seulement après confirmation certaine
Cette voie convient à une commande dont l’encaissement complet est établi et dont le traitement automatique ne peut pas être rétabli assez vite, avec l’accord du responsable commercial. Avant tout changement, vérifiez de nouveau qu’aucun remboursement, litige ou changement récent n’a modifié la situation. Contrôlez aussi la possibilité de livraison et l’état du stock.
Dans WooCommerce > Commandes, ouvrez uniquement la commande rapprochée. Conservez le statut initial, les notes et la référence. Dans les détails de commande, choisissez En cours ou Processing pour une commande payée restant à préparer, puis Mettre à jour ou Update dans Actions de commande. Ne choisissez Terminée que si elle est réellement achevée. N’utilisez pas l’action de capture du paiement : ce parcours concerne un encaissement déjà confirmé.
Ajoutez une note privée précisant la raison de la correction, la preuve de rapprochement et la personne qui l’a autorisée. Ne modifiez pas le montant ou les produits pour faire correspondre artificiellement une transaction différente. Une différence de montant, de devise ou de référence doit être résolue avant de déclarer l’ensemble payé.
Changer le statut peut déclencher des courriers, des mises à jour de stock et des automatisations. Cela n’équivaut pas nécessairement à l’appel technique complet de validation de paiement de la passerelle. Vérifiez si l’identifiant de transaction, la date de paiement et les traitements propres à l’intégration sont présents ; signalez les champs manquants au responsable plutôt que de les inventer.
Le résultat attendu est un suivi commercial cohérent pour cette commande précise. Vérifiez l’inventaire et les éventuelles notifications une seule fois. Si vous avez sélectionné le mauvais statut, ne le faites pas osciller entre plusieurs valeurs : revenir à la valeur précédente ne retire pas les courriers déjà partis ni toutes les actions déclenchées. Documentez l’erreur et faites corriger les effets concernés avant une nouvelle transition.
Surveiller les annulations et les commandes voisines
Une commande longtemps laissée en attente peut être annulée selon les règles de stock. Une confirmation tardive exige alors une nouvelle vérification avant toute relivraison ou remise en préparation. L’extension Stripe examinée possède un traitement pouvant rembourser un paiement tardif sur une commande annulée. Contrôlez donc l’état actuel chez le prestataire et les actions différées ; ne désactivez pas ce comportement par un extrait pour forcer l’issue souhaitée.
Établissez la période affectée à partir de la première erreur connue et de la remise en état. Examinez les commandes correspondantes individuellement, puis rapprochez chacune avec le prestataire. Le fait qu’un exemple soit payé ne permet pas d’approuver en bloc toute la liste En attente de paiement. Certaines commandes sont simplement abandonnées ou réellement impayées.
Ne déclenchez pas un remboursement réflexe pour simplifier le dossier : un remboursement est une opération commerciale réelle. De même, changer une commande en Annulée ne garantit pas le retour des fonds. Vérifiez le résultat financier dans le prestataire et le résultat de suivi dans WooCommerce, avec une référence commune.
Pour les clients concernés, faites communiquer une information exacte par la personne chargée du suivi : paiement en vérification, encaissement confirmé ou autre état établi. Évitez une demande automatique de second paiement pendant le rapprochement. Les messages déjà envoyés par des automatisations doivent être pris en compte pour ne pas contredire le suivi manuel.
Confirmer que les prochaines commandes suivent le bon chemin
Validez le mécanisme sur une copie isolée avec base distincte, destinataires de test et intégrations commerciales réelles neutralisées. Configurez le compte de paiement en mode test ainsi que sa notification entrante vers cette copie. Si sa protection d’accès bloque le prestataire, faites autoriser uniquement le point d’entrée nécessaire tout en conservant la validation de signature et la protection des autres pages. Ne rendez pas une copie contenant des données client entièrement publique.
Commencez par une commande de test du scénario défini : création, confirmation du prestataire, réception de la notification puis statut attendu. Contrôlez les actions différées éventuelles. Ce résultat ne valide pas tous les moyens de paiement ; examinez les autres variantes affectées séparément. Gardez secrets, destinations et comptes propres à chaque mode : un événement de test livré au site réel ne prouve pas le fonctionnement du mode réel.
La réparation est complète lorsque les commandes touchées ont été rapprochées, que la cause de réception ou de traitement est corrigée et que le parcours de contrôle termine correctement. Conservez les références des cas exceptionnels et les effets vérifiés sur stock et notifications.
Si la commande est déjà correctement payée dans WooCommerce mais que seul le courrier manque, passez au diagnostic de confirmation électronique. Si la page ne termine pas son chargement avant toute création, reprenez le diagnostic de la requête de commande. Ces problèmes voisins ne justifient pas de changer un statut de paiement déjà exact.
