Quand le paiement bloque, je commence par une question un peu moins spectaculaire que « quel plugin faut-il désactiver ? » : l’argent a-t-il bougé ? Tant qu’on n’a pas la réponse, demander au client de recommencer peut transformer un incident de checkout en double paiement.
Gardez la commande et le tableau de bord de la passerelle ouverts côte à côte. Le navigateur raconte ce que le client a vu. WooCommerce raconte ce qu’il a enregistré. Le prestataire de paiement raconte ce qu’il a traité. Les trois versions ne coïncident pas toujours, et c’est justement l’écart qui nous intéresse.
Repérer à quel moment le checkout s’arrête
Reproduisez le parcours avec le même type de produit, une adresse de livraison comparable et la passerelle concernée. Notez le message exact et l’heure, avec le fuseau. Sur une préproduction configurée avec les clés de test, comparez une commande invitée et une commande avec un compte. Identifiez aussi si la boutique utilise le bloc Commande ou le checkout classique : le thème, les champs personnalisés et les extensions peuvent se comporter différemment.
Si le bouton ne répond pas, ouvrez Console et Réseau dans le navigateur. Un script absent, une requête qui échoue ou une erreur de validation pointe vers une piste différente d’un refus bancaire. Si le produit disparaît avant le paiement, passez d’abord par le diagnostic du panier WooCommerce. Évitez de désactiver les extensions de paiement sur une boutique active pour reproduire le problème.
Quatre situations qui se ressemblent côté client
Le client dit « ça ne marche pas » et il peut avoir raison dans quatre sens différents. Voici comment je trie le problème :
| Ce que vous retrouvez | Où poursuivre |
|---|---|
| Aucune commande et aucune tentative côté passerelle | Regarder le formulaire, les moyens de livraison disponibles et la requête de validation. |
| Commande créée, tentative refusée | Lire le motif chez le prestataire et vérifier si un autre moyen de paiement est possible. |
| Transaction autorisée ou capturée, commande toujours en attente | Rapprocher les références et examiner la notification serveur avant toute relance. |
| Commande et transaction cohérentes, confirmation absente | Vérifier le retour navigateur et la chaîne email plutôt que demander un autre paiement. |
Les intitulés varient d’une passerelle à l’autre. Une autorisation peut réserver le montant sans capture immédiate. Pour un paiement différé ou un moyen asynchrone, un état intermédiaire peut être normal. Comparez la commande au comportement documenté pour ce moyen de paiement précis.
Rapprocher WooCommerce et la passerelle
Dans WooCommerce, relevez le numéro, l’heure, le montant et les notes de la commande. Dans la passerelle, cherchez la transaction correspondante. Distinguez autorisation, capture, refus et absence de tentative selon le vocabulaire du prestataire. Une correspondance par montant seul est insuffisante si plusieurs clients ont payé le même prix.
Si la transaction est confirmée mais que la commande reste en attente, examinez les notifications de la passerelle et leur traitement. Vérifiez l’adresse de destination, le mode test ou production et la réponse enregistrée. Un retour réussi du navigateur n’est pas la même chose qu’une notification reçue par le serveur. Un code HTTP seul ne prouve pas non plus que l’extension a appliqué l’événement au bon objet.
Lire les notifications sans refaire la transaction
Prenons un cas fictif : une commande est en attente et le prestataire affiche une capture de 89 €. Je cherche d’abord la référence qui relie cette capture à la commande. Je vérifie ensuite les tentatives de livraison de l’événement et l’heure correspondante dans les logs WooCommerce. Si l’URL de notification a changé après une migration, le journal de livraison peut montrer que l’événement n’a jamais atteint la boutique. Si l’événement est arrivé, les journaux de l’extension peuvent indiquer pourquoi il n’a pas été appliqué.
Ne corrigez pas à la fois la configuration de la passerelle, les règles de cache et le thème. Après chaque changement, reproduisez le cas en environnement de test et comparez le résultat. Si le prestataire propose de rejouer une notification, vérifiez d’abord l’état réel et le comportement prévu par l’extension : un traitement peut avoir réussi en partie. Pour les commandes déjà touchées, gardez un relevé de ce qui a été rapproché et de la décision prise. Changer un statut peut déclencher d’autres opérations, notamment un email ou l’envoi en préparation.
Corriger une seule cause et refaire les trois scénarios
Si la passerelle indique un refus, relevez sa catégorie sans demander le numéro de carte au client. Si aucune tentative n’existe, vérifiez le formulaire, les modes proposés pour cette adresse et les journaux WooCommerce. Si un montant a déjà été capturé, ne demandez pas un second paiement : documentez l’écart et vérifiez la méthode de rapprochement de l’extension avant de changer un statut.
Validez ensuite un paiement réussi, un refus et un retour interrompu. Comparez le statut, le stock, les emails et le montant. En présence d’erreurs 502 ou 504, le diagnostic serveur pendant un pic de commandes complète cette vérification.
Préparer un signalement que l’on peut reproduire
Avant d’ouvrir un ticket, notez l’heure et le fuseau, le numéro de commande, le moyen de paiement, la version de son extension, le type de checkout et le message exact. Ajoutez le résultat côté passerelle et la dernière modification connue. Si vous fournissez un extrait de log, masquez les clés, jetons et données client. Deux lignes bien choisies valent mieux qu’un export complet qui noie l’erreur au milieu de tout le reste.
Je considère le problème réglé quand un achat réussi apparaît une seule fois dans les deux outils, qu’un refus est compréhensible et qu’un retour interrompu ne laisse pas une commande payée sans suivi. Testez au moins une fois sur téléphone, surtout si la validation fait quitter la boutique avant d’y revenir.
Quand relancer une commande échouée ?
Une relance convient à un paiement dont l’échec a été confirmé et qui n’a pas été suivi d’un règlement. Le guide SaleSaver sur les paiements échoués explique ce cas. Il ne remplace pas la correction d’une passerelle. Pour préparer l’ensemble du parcours, consultez la recette WooCommerce avant une campagne.
Références : statuts WooCommerce et dépannage de l’extension Stripe. Pour une autre passerelle, suivez sa documentation et ses journaux.
