Une commande WooCommerce bloquée peut prendre plusieurs formes : le client reste sur la page de paiement, le bouton « Commander » ne répond pas, le paiement est accepté mais la commande reste « En attente de paiement », ou encore le stock est réservé sans qu’aucun e-mail ne parte. Une intervention efficace ne consiste pas à modifier le statut au hasard. Pour résoudre un problème de commande WooCommerce, la priorité est d’identifier l’étape exacte où le parcours échoue, de préserver les preuves dans les journaux et de vérifier si le paiement a réellement été encaissé avant toute action sur la commande.
Si la boutique ne peut plus prendre de commandes, notre service de dépannage WooCommerce permet de faire analyser l’incident. Avant toute intervention, vérifiez avec notre guide des sauvegardes WordPress que vous disposez d’une copie exploitable des fichiers et de la base.
Identifier précisément le type de blocage
Commencez par reproduire le problème dans une fenêtre de navigation privée, avec un produit test et une adresse e-mail contrôlée. Notez l’URL, le moyen de paiement utilisé, le message affiché et l’heure exacte. Ces éléments permettront de croiser le comportement observé avec les logs WooCommerce, WordPress et ceux du prestataire de paiement.
- La page panier ou commande est inaccessible : le problème concerne souvent les permaliens, le cache, un conflit d’extension ou une erreur PHP.
- Le bouton de validation ne fait rien : recherchez une erreur JavaScript, un champ obligatoire invisible, un CAPTCHA bloqué ou une passerelle de paiement mal chargée.
- La commande est créée avec le statut « En attente de paiement » : WooCommerce attend une confirmation de paiement, généralement transmise par redirection ou webhook.
- La commande est « Échouée » : la passerelle a signalé un refus, une erreur technique ou des informations de paiement invalides.
- La commande est « En attente » : ce statut est fréquent pour un virement bancaire, un chèque ou une méthode manuelle. Il n’indique pas forcément un incident.
- Le paiement est débité mais la commande n’est pas payée : traitez ce cas en priorité en comparant l’identifiant de transaction chez le prestataire avec les notes de commande.
Dans WooCommerce > Commandes, ouvrez une commande concernée et consultez les notes à droite ou en bas de l’écran selon l’interface. Elles indiquent souvent la requête envoyée, la réponse reçue et l’identifiant de transaction. Ne passez pas manuellement une commande à « En cours » simplement parce qu’un client déclare avoir payé : vérifiez d’abord le tableau de bord Stripe, PayPal ou de la banque.
Sauvegarder et isoler avant toute correction
Avant de modifier des extensions, créez une sauvegarde exploitable des fichiers et de la base de données. Pour une boutique active, réalisez les essais sur un environnement de préproduction lorsque c’est possible. Si une correction doit être faite en production, convenez d’un créneau avec le propriétaire et préparez un test contrôlé. Ne restaurez pas une ancienne base sur la boutique active sans préserver les commandes, comptes clients et paiements intervenus depuis la sauvegarde.
Vérifiez aussi que WordPress, WooCommerce, le thème actif et la passerelle de paiement sont à jour de manière compatible. Une mise à jour ne doit pas être appliquée aveuglément pendant un incident : lisez le changelog, contrôlez les prérequis PHP et effectuez une sauvegarde préalable. Un conflit peut venir d’un plugin d’optimisation qui diffère ou combine les scripts du checkout, d’un plugin de devises, d’un système de facturation ou d’un code ajouté dans le thème enfant.
Contrôler les journaux WooCommerce et WordPress
Les logs sont le point de départ le plus fiable d’un dépannage. Accédez à WooCommerce > État > Journaux, puis sélectionnez le fichier correspondant à la passerelle concernée et à l’heure du test. Les noms varient selon l’extension : recherchez notamment les termes liés à Stripe, PayPal, paiement, fatal-errors ou webhook.
Une erreur comme cURL error 28 indique généralement un délai d’attente lors d’un appel externe. Une réponse 401 ou 403 peut signaler une clé API invalide, une authentification refusée ou un pare-feu. Une erreur PHP fatale peut empêcher WooCommerce de finaliser la commande ou d’afficher le formulaire. Si le journal n’est pas suffisant, activez temporairement le débogage dans le fichier wp-config.php, sans afficher les erreurs aux visiteurs :
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/chemin/prive/wordpress-debug.log');
define('WP_DEBUG_DISPLAY', false);
Adaptez le chemin du journal à un répertoire privé, hors de la racine web et accessible en écriture à PHP. Ne dupliquez pas des constantes déjà définies. Les journaux peuvent contenir des données sensibles : limitez leur accès et leur conservation. Désactivez ce débogage après l’analyse. Sur un site en production, ne laissez jamais WP_DEBUG_DISPLAY activé : des informations techniques pourraient apparaître au public.
Vérifier la passerelle de paiement et les webhooks
Une commande peut être créée avant que WooCommerce ne reçoive la confirmation définitive du prestataire. C’est le rôle du webhook : le prestataire appelle une URL de votre site pour signaler un paiement validé, remboursé ou échoué. Dans les réglages de l’extension de paiement et dans le tableau de bord du prestataire, vérifiez les tentatives de webhook à l’heure du problème.
- Contrôlez que l’URL de destination utilise bien le domaine public en HTTPS, sans redirection vers une ancienne adresse ou une version non-www.
- Vérifiez le code de réponse : un webhook doit normalement recevoir une réponse HTTP 2xx. Une réponse 301, 302, 403, 404 ou 500 demande une investigation.
- Comparez les clés API et les secrets de signature entre le mode test et le mode production. Des clés de test sur une boutique en direct empêchent la validation réelle.
- Assurez-vous que l’horloge du serveur est correcte. Une heure très décalée peut invalider la vérification de signature de certains webhooks.
- Excluez les URL de webhook des protections trop agressives : authentification HTTP, règle de pare-feu, géoblocage ou challenge anti-bot.
Pour Stripe, consultez les événements et les tentatives de livraison dans son tableau de bord. Pour PayPal, vérifiez l’historique des transactions et les notifications reçues par le site. Si le prestataire confirme le paiement mais que le webhook échoue, corrigez l’accès au site puis relancez l’événement depuis le prestataire lorsque cette fonction est disponible. Contrôlez ensuite les notes de la commande avant de modifier son statut.
Éliminer les blocages du checkout côté navigateur
Ouvrez les outils de développement du navigateur, onglet Console, puis rechargez la page de commande. Une erreur JavaScript provenant d’un thème ou d’une extension peut empêcher la mise à jour des frais de livraison, le chargement des moyens de paiement ou l’envoi du formulaire. Dans l’onglet Réseau, examinez les requêtes lancées au clic sur « Commander » : une réponse 400, 403 ou 500 apporte souvent une piste plus concrète qu’un message générique côté client.
Vérifiez également les réglages de WooCommerce : pages attribuées au panier et à la commande dans WooCommerce > Réglages > Avancé, devise, pays de vente, zones de livraison et méthodes de livraison. Une méthode de paiement peut disparaître si elle est conditionnée à un pays, une devise, un montant ou un type de produit. Testez avec une adresse située dans une zone de livraison réellement configurée.
Les extensions de cache, de minification JavaScript et les CDN doivent exclure le panier, la commande et le compte client du cache de page. Les pages WooCommerce utilisent des données de session et des nonces ; servir une page mise en cache à un autre visiteur peut provoquer un panier incohérent ou l’échec d’une validation. Après avoir configuré les exclusions, videz le cache de l’extension, du serveur et du CDN avant un nouveau test.
Examiner les tâches planifiées et les e-mails
Certaines actions WooCommerce sont exécutées en arrière-plan via Action Scheduler. Dans Outils > Actions programmées ou WooCommerce > État > Actions programmées, recherchez les actions échouées ou en attente liées à la passerelle, aux abonnements ou aux e-mails. Une accumulation d’actions échouées peut révéler un problème de cron, une limite de ressources serveur ou une extension défaillante.
Un e-mail de commande absent ne prouve pas qu’une commande est bloquée. Vérifiez d’abord son statut, ses notes et le paiement. Ensuite, contrôlez les réglages dans WooCommerce > Réglages > E-mails, l’adresse expéditrice et les logs du service SMTP si le site en utilise un. Un SMTP correctement configuré améliore la délivrabilité, mais il ne corrigera pas une transaction de paiement refusée.
Tester les conflits sans interrompre les ventes
Sur une préproduction, activez temporairement un thème WordPress par défaut et désactivez les extensions non indispensables, en conservant WooCommerce et la passerelle de paiement. Effectuez une commande test, puis réactivez les éléments un par un jusqu’à reproduire le défaut. Cette méthode identifie un conflit sans supposition.
Sur un site en production, utilisez plutôt un environnement de staging ou un outil de dépannage qui n’affecte que votre session administrateur. Ne désactivez pas globalement la passerelle de paiement ni un plugin de cache en pleine activité sans mesure de l’impact. Une fois la cause corrigée, réalisez un test complet : ajout au panier, calcul de livraison, paiement, retour sur la page de confirmation, changement de statut, réception de l’e-mail et vérification de la commande dans le back-office.
Documenter la résolution du blocage de commande
Conservez dans votre journal de maintenance WooCommerce la cause identifiée, les versions des extensions, l’erreur de log, la correction appliquée et le résultat du test. Ajoutez une surveillance des erreurs PHP et des échecs de webhook, ainsi qu’un contrôle périodique des mises à jour sur préproduction. Cette documentation évite de répéter les mêmes investigations et permet de traiter rapidement une nouvelle commande bloquée sans risquer de valider un paiement non confirmé.
Peut-on modifier manuellement le statut d’une commande WooCommerce bloquée ?
Oui, mais seulement après avoir vérifié le paiement dans le tableau de bord du prestataire et dans les notes de commande. Modifier le statut ne déclenche pas forcément les actions attendues par la passerelle et peut conduire à expédier une commande non payée.
Pourquoi une commande reste-t-elle en attente de paiement après un paiement par carte ?
WooCommerce n’a généralement pas reçu ou validé la confirmation de la passerelle. Vérifiez les journaux de l’extension, l’identifiant de transaction et les livraisons de webhook. Un pare-feu, une mauvaise clé API ou une URL de site redirigée peut bloquer cette confirmation.
Un cache peut-il empêcher un client de finaliser sa commande ?
Oui. Le panier, la commande et le compte client ne doivent pas être mis en cache comme des pages publiques. Excluez-les du cache de page, de la minification problématique et, si nécessaire, des règles du CDN, puis purgez tous les niveaux de cache.
Comment savoir si le problème vient de WooCommerce ou de l’hébergeur ?
Les logs permettent de l’orienter : erreurs PHP, manque de mémoire, erreurs 500, délais cURL ou échecs de cron peuvent nécessiter une intervention côté hébergement. Une erreur d’API, de signature ou de configuration de paiement concerne plus souvent l’extension ou la passerelle.
Faut-il créer une nouvelle commande après un paiement validé mais non enregistré ?
Évitez de créer une seconde commande avant d’avoir recherché la transaction avec son identifiant chez le prestataire et dans WooCommerce. Corrigez d’abord le webhook ou la cause technique, puis mettez à jour la commande existante si le paiement est confirmé afin d’éviter un doublon.