WooCommerce : paiement échoué mais client débité

Symptômes

• Le tableau de bord du prestataire affiche un paiement réussi ; la commande WooCommerce est En attente de paiement, Échouée ou Annulée.
• Le client a été débité mais n’a jamais reçu l’e-mail de confirmation de commande, ou la commande n’existe pas.
• Les commandes passent En cours des heures plus tard, ou seulement quand le client se manifeste.
• Le client a été débité deux fois et il existe deux commandes, dont une seule payée.

Causes les plus fréquentes

1. La notification n’a jamais atteint la boutique. Le callback ou webhook de serveur à serveur du prestataire a été bloqué par un pare-feu, un WAF, la protection anti-bots de la CDN, une authentification basique, une extension de mode maintenance ou un blocage géographique.
2. La notification a été redirigée. Une redirection de HTTP vers HTTPS ou de www vers sans www sur l’URL de callback. Beaucoup de prestataires considèrent une redirection comme une livraison échouée.
3. La notification a été rejetée. Un secret de webhook ou une clé de signature erronés, par exemple après la recréation du point d’accès du webhook ou en mélangeant clés de test et de production.
4. La boutique a échoué en la traitant. Une erreur PHP dans le code exécuté quand une commande est payée (stock, e-mails, synchronisation ERP) a interrompu la mise à jour.
5. La commande n’était plus en attente. Le délai de retenue du stock l’a annulée avant l’arrivée d’une confirmation tardive, ou le client a payé depuis un ancien onglet.
6. La redirection était la seule confirmation. Le client a fermé la fenêtre après le paiement ou après 3D Secure, et la boutique dépendait de la redirection du navigateur au lieu d’une notification serveur.
7. La commande n’a pas pu être retrouvée. Des numéros de commande personnalisés, un multisite ou une référence de commande modifiée empêchent l’extension de passerelle de retrouver la commande.

Diagnostic

1. Choisissez une commande concernée et reconstituez sa chronologie

À partir de trois sources, notez chaque événement avec son heure exacte :

Le premier événement présent chez le prestataire mais absent de la boutique est l’endroit où la confirmation s’est perdue.

2. Consultez le journal de livraison du prestataire

La plupart des prestataires affichent chaque tentative de notification ou de webhook avec son code de réponse. Lisez-les :

• Timeout ou erreur de connexion : la boutique n’a pas répondu à temps, ou la requête n’est jamais arrivée.
• 3xx : l’URL de callback redirige ; remplacez-la par l’URL finale.
• 401 / 403 : l’authentification, une extension de sécurité ou un WAF l’a bloquée.
• 400 : l’extension de passerelle l’a rejetée, souvent à cause d’une signature ou d’un secret non conformes.
• 500 : PHP a échoué pendant le traitement. Cherchez une erreur fatale à cette heure-là.

3. Confirmez que la requête a atteint le serveur

Cherchez dans le journal d’accès du serveur web les requêtes vers l’URL de callback aux heures indiquées par le prestataire. L’URL dépend de l’extension de passerelle : souvent une URL ?wc-api= ou un point d’accès REST. S’il n’y a aucune entrée, la requête a été bloquée avant d’atteindre PHP : CDN, WAF ou pare-feu.

4. Cherchez des erreurs pendant le traitement de la commande

Si la notification a atteint la boutique et a été acceptée, regardez ce qui s’est passé ensuite : une entrée fatal-errors, une erreur PHP ou une action planifiée échouée dans la même minute. Le code branché sur woocommerce_payment_complete ou sur les changements de statut s’exécute dans la requête de notification ; s’il échoue, la commande peut ne jamais être enregistrée comme payée.

Journaux et vérifications techniques

• Prestataire : journal d’événements et historique de livraison des webhooks ou notifications des paiements concernés.
• WooCommerce → État → Journaux : la source de journal de la passerelle et fatal-errors.
• Journaux d’accès et d’erreurs du serveur web pour l’URL de callback.
• WooCommerce → Réglages → Produits → Inventaire : le délai de retenue du stock qui annule les commandes impayées.
• Outils → Actions planifiées : actions échouées ou en attente créées autour de l’heure du paiement.
• Journaux de l’extension de sécurité, de la CDN et du WAF pour les requêtes bloquées vers l’URL de callback.

Solutions

• Rendez l’URL de callback accessible : excluez-la des défis WAF, de la protection anti-bots, du mode maintenance, de l’authentification basique et du cache. Utilisez l’URL finale, sans redirection.
• Corrigez le secret du webhook dans les réglages de la passerelle pour qu’il corresponde au point d’accès configuré chez le prestataire, séparément pour les modes test et production.
• Corrigez le code en échec pendant le traitement du paiement, et déplacez le travail lent (synchronisations ERP, appels externes) vers des tâches en arrière-plan pour que la requête de notification se termine vite.
• Vérifiez que les notifications serveur sont activées, pour que la commande ne dépende pas du retour du navigateur du client.
• Régularisez les commandes concernées : pour chaque paiement réussi sans commande payée, vérifiez le montant, la devise et le client, puis finalisez ou recréez la commande avec les outils normaux de la passerelle ou de WooCommerce, avec une note décrivant la vérification.

Ce qu’il ne faut pas faire

• Ne désactivez pas la vérification de signature « pour que ça marche ». N’importe qui pourrait marquer des commandes comme payées.
• Ne supprimez pas les commandes échouées ou annulées : ce sont les preuves et le lien avec le paiement.
• Ne remboursez pas et ne redébitez pas les clients avant d’avoir rapproché les deux côtés.
• N’augmentez pas le délai de retenue du stock comme solution. Cela masque les confirmations tardives au lieu de les corriger.

Quand faire appel à un expert

Faites appel à un ingénieur quand les débits sans commande continuent, quand vous ne savez pas quelles commandes sont concernées, quand les journaux de l’extension de passerelle ne montrent rien, ou quand l’échec se trouve dans du code sur mesure exécuté après le paiement.

Problèmes liés

• WooCommerce / Intégrations Webhooks WooCommerce en échec : comment les diagnostiquer Journaux de livraison, codes de réponse, signatures, et pourquoi WooCommerce désactive un webhook après plusieurs livraisons échouées d’affilée. →
• WooCommerce / Checkout Le checkout WooCommerce ne fonctionne pas : trouver la cause racine Déterminez d’abord si l’échec se produit avant la requête de commande, pendant celle-ci ou après la réponse de la passerelle. Le panneau Réseau et les journaux PHP montrent généralement quelle couche casse. →
• WooCommerce / Commandes Commandes WooCommerce manquantes ou incorrectes Avant de considérer une commande comme perdue, vérifiez tous les statuts, les brouillons et le prestataire de paiement. Les totaux faux viennent souvent des taxes, frais, codes promo ou recalculs. →
• WooCommerce / Performance Problèmes d’Action Scheduler dans WooCommerce Actions planifiées en retard, échouées et bloquées : comment la file fonctionne, pourquoi elle s’arrête et comment la réparer sans perdre de travail en attente. →

Questions fréquentes