Un message « Erreur lors du traitement de la commande » ne désigne pas forcément un problème de carte bancaire. Dans WooCommerce, l’échec peut survenir avant la création de la commande, au moment de l’appel vers Stripe ou PayPal, pendant le retour du client sur le site, ou lors de la confirmation reçue par webhook. Une intervention de maintenance site WordPress efficace consiste à isoler précisément cette étape, sans désactiver au hasard les extensions ni modifier la boutique en production sans sauvegarde.
Identifier le moment exact où le paiement échoue
Commencez par reproduire le parcours avec une commande de test, sur un produit à faible prix ou dans le mode test de votre passerelle. Notez l’URL, le message affiché, le moyen de paiement concerné et l’heure exacte. Ces informations permettent de rapprocher l’incident des journaux techniques.
- Erreur avant redirection : le client clique sur « Commander », mais reste sur le paiement. La cause est souvent un champ obligatoire, un nonce expiré, une erreur JavaScript, un conflit de cache ou une requête AJAX bloquée.
- Erreur chez le prestataire : Stripe, PayPal ou Mollie affiche un refus ou un échec. Vérifiez d’abord le motif fourni dans le tableau de bord du prestataire.
- Paiement accepté mais commande échouée ou annulée : la transaction existe côté prestataire, mais WooCommerce ne reçoit pas ou ne traite pas correctement la notification.
- Commande en attente : elle a été créée, mais le règlement n’est pas confirmé. Cela peut être normal pour un virement, mais pas pour une carte déjà débitée.
Ne confondez pas une commande annulée avec une commande échouée. Une commande échouée résulte généralement d’un refus ou d’une erreur de paiement. Une commande annulée peut venir d’une annulation manuelle, d’un délai de paiement expiré ou de la logique d’une extension.
Consulter les preuves utiles dans WooCommerce
Lire les notes de commande
Dans WooCommerce > Commandes, ouvrez une commande touchée. Les notes indiquent souvent le nom de la passerelle, l’identifiant de transaction, une réponse d’API ou une tentative de paiement. Cherchez notamment des mentions telles que payment complete, authentication required, webhook, capture ou un code d’erreur du prestataire.
Si la commande est absente, le problème arrive probablement avant sa création : validation du formulaire, script JavaScript, session WooCommerce ou requête AJAX. Si elle est présente mais sans identifiant de transaction, examinez la configuration de la passerelle et ses journaux.
Exploiter les journaux sans les confondre
Allez dans WooCommerce > État > Journaux, puis sélectionnez un fichier correspondant à votre extension de paiement et à l’heure du test. Les noms varient selon le module : Stripe, PayPal, Mollie ou le nom technique de l’extension. Un journal utile contient généralement une requête, une réponse et un code HTTP.
- 401 ou 403 : clé API erronée, droits insuffisants, pare-feu ou règle de sécurité.
- 404 : URL de webhook ou de retour incorrecte, réécriture d’URL défaillante.
- 429 : limitation de requêtes par un service externe ou une protection anti-abus.
- 500, 502 ou 503 : erreur PHP, surcharge serveur, délai dépassé ou incident d’hébergement.
Contrôlez aussi WooCommerce > État > Journaux pour les erreurs fatales WordPress, ainsi que le journal PHP de l’hébergement. Une erreur du type « Allowed memory size exhausted » ou une incompatibilité de version PHP ne sera pas toujours visible dans le journal de la passerelle.
Vérifier la passerelle de paiement et ses webhooks
Dans WooCommerce > Réglages > Paiements, vérifiez que la méthode concernée est activée et que le bon environnement est sélectionné. Une clé de test associée à un mode réel, ou l’inverse, empêche les paiements d’aboutir. Vérifiez également le pays, la devise acceptée et les méthodes activées dans le compte Stripe, PayPal ou autre prestataire.
Pour les paiements par carte, le webhook est déterminant : c’est lui qui informe WooCommerce qu’un paiement a été validé, remboursé ou contesté. Dans le tableau de bord du prestataire, consultez l’historique des événements envoyés à votre site. Une livraison en échec doit être corrigée à la source :
- contrôlez que l’URL du site est en HTTPS et accessible publiquement ;
- vérifiez que le domaine configuré est le domaine canonique, avec ou sans
wwwselon votre configuration ; - supprimez les redirections excessives entre HTTP, HTTPS, www et non-www ;
- mettez à jour le secret de signature dans les réglages du plugin si vous avez recréé le webhook ;
- renvoyez un événement de test depuis le prestataire, puis vérifiez la note de commande et le journal WooCommerce.
Évitez de créer manuellement plusieurs webhooks identiques sans comprendre leur rôle : cela peut générer des notifications dupliquées et compliquer le diagnostic.
Écarter les conflits de cache, de sécurité et de formulaire
La page de commande ne doit jamais être mise en cache comme une page statique. Dans votre extension de cache, CDN ou cache serveur, excluez au minimum les pages panier, commande et compte client, ainsi que les requêtes WooCommerce dynamiques. Les cookies WooCommerce doivent également être respectés ; sinon, un client peut recevoir un nonce ou un contenu de session périmé.
Les extensions de sécurité et les pare-feu applicatifs peuvent bloquer les appels REST, AJAX ou les requêtes envoyées par les webhooks. Un test temporaire, documenté et limité dans le temps, permet de confirmer cette hypothèse. Si le paiement fonctionne après désactivation du pare-feu, créez une règle ciblée pour l’URL ou la requête concernée au lieu de laisser la protection inactive.
Ouvrez ensuite les outils de développement du navigateur, onglet Réseau, et recommencez le paiement. Une requête vers ?wc-ajax=checkout qui renvoie une erreur 403, 500 ou du HTML inattendu indique un problème côté site. Une erreur JavaScript peut aussi empêcher le bouton de paiement de déclencher correctement la demande. Les scripts d’optimisation JavaScript, la minification différée et certains bandeaux de consentement sont des causes fréquentes lorsqu’ils retardent ou modifient les scripts de la page de commande.
Contrôler la configuration WooCommerce indispensable
Dans WooCommerce > Réglages > Avancé, vérifiez que la page assignée à « Commande » est bien la page active contenant le bloc ou le shortcode de paiement attendu par votre configuration. Une page supprimée, dupliquée ou protégée par mot de passe peut casser le retour après paiement.
Vérifiez aussi les emails administrateur et client, la devise, les taxes et les règles d’expédition. Une règle de livraison sans méthode disponible peut empêcher la validation, même si le message affiché semble lié au paiement. Testez avec une adresse de livraison réaliste pour le pays concerné.
Si vous utilisez le stockage haute performance des commandes (HPOS), assurez-vous que l’extension de paiement est déclarée compatible et à jour. Ne basculez pas HPOS uniquement pour tenter de corriger un paiement : faites ce changement dans un environnement de préproduction, avec une sauvegarde et un plan de retour.
Appliquer une méthode de correction sans perdre de ventes
Avant toute mise à jour ou désactivation, réalisez une sauvegarde restaurable des fichiers et de la base de données. Reproduisez si possible l’incident sur une copie de préproduction. Mettez à jour WordPress, WooCommerce et le plugin de paiement de manière contrôlée, en vérifiant la compatibilité PHP annoncée par leurs éditeurs.
Pour isoler un conflit, désactivez temporairement les extensions non essentielles sur la préproduction, puis testez le paiement. Réactivez-les une à une jusqu’à reproduire l’erreur. Conservez le thème actif au départ ; si nécessaire, testez ensuite avec un thème WordPress standard. Cette méthode est plus fiable que la suppression immédiate d’un plugin de paiement ou la modification directe de fichiers.
Lorsque le prestataire indique une transaction réussie mais que WooCommerce ne l’enregistre pas, ne demandez pas automatiquement au client de payer une seconde fois. Recherchez l’identifiant de transaction, vérifiez le montant, la devise et l’adresse email, puis régularisez la commande selon votre procédure comptable. Une maintenance site WordPress régulière — mises à jour testées, surveillance des journaux, sauvegardes et contrôle des webhooks — réduit fortement le risque de découvrir ce type de panne au moment d’une vente.
Pourquoi une commande WooCommerce passe-t-elle en attente après un paiement par carte ?
Le statut « en attente » signifie que WooCommerce n’a pas reçu de confirmation exploitable. Vérifiez d’abord la transaction dans le tableau de bord de la passerelle, puis les événements webhook et les notes de la commande. Si le paiement est réellement capturé, le webhook, son secret de signature ou un blocage serveur est généralement à contrôler.
Comment savoir si un client a été débité deux fois ?
Ne vous fiez pas uniquement aux deux tentatives visibles dans WooCommerce. Comparez les identifiants de transaction, montants, devises et statuts dans le compte Stripe, PayPal ou du prestataire. Deux autorisations peuvent aussi apparaître sans être deux débits définitifs. Ne remboursez qu’après vérification du statut réellement capturé.
Le mode test fonctionne, mais pas le mode réel : que contrôler ?
Contrôlez les clés API de production, l’activation du compte marchand, les méthodes de paiement autorisées, la devise et les exigences de vérification du prestataire. Vérifiez aussi que le webhook de production, distinct de celui du test chez certains services, utilise la bonne URL et le bon secret.
Un certificat SSL expiré peut-il bloquer les paiements WooCommerce ?
Oui. Un certificat invalide ou une chaîne de certificats mal configurée peut empêcher le navigateur, le prestataire ou le webhook de communiquer avec le site. Vérifiez l’accès HTTPS sur la page de commande, l’absence d’alerte navigateur et le certificat présenté par le domaine canonique.
Faut-il activer WP_DEBUG pour diagnostiquer une erreur de paiement ?
WP_DEBUG peut aider à révéler une erreur PHP, mais ne l’affichez jamais aux visiteurs. Sur un site de production, enregistrez les erreurs dans un fichier plutôt que de les afficher à l’écran, et retirez les informations sensibles avant de transmettre un journal à un prestataire ou à un intervenant.