Erreurs WooCommerce : panier, checkout, paiement bloqués

Panier vide, checkout cassé : chaque bug WooCommerce coûte une vente

Un client ajoute trois produits au panier, arrive sur la page de paiement, et là : le panier est vide. Ou pire, la page checkout affiche un écran blanc, ou la passerelle refuse la carte alors qu’elle est valide. Ce ne sont pas des détails techniques abstraits : ce sont des ventes perdues, en direct, sans que tu le voies passer dans les stats (le client abandonne, point final, aucune erreur ne remonte dans Google Analytics).

La bonne nouvelle : la grande majorité des pannes WooCommerce viennent d’un nombre limité de causes, souvent cumulées. On peut les diagnostiquer méthodiquement, sans tout casser. Ce guide couvre les quatre familles de bugs qui reviennent le plus souvent — panier qui se vide, checkout cassé, passerelle qui refuse, e-mails de commande absents — avec pour chacune une résolution concrète, du réglage le plus simple au plus technique.

Pourquoi ça arrive

Avant de foncer dans les solutions, comprendre les causes évite de tourner en rond pendant des heures.

• Cache trop agressif : un plugin de cache (ou le cache serveur/CDN) sert une version figée de la page panier ou checkout, qui ne reflète plus la session réelle du visiteur.
• Conflit thème/plugin : une mise à jour de WooCommerce, du thème ou d’une extension (moyens de paiement, calcul de frais de port, pop-up promo) casse un hook ou un script JS nécessaire au checkout.
• Sessions et cookies mal gérés : hébergement mutualisé avec une configuration de sessions PHP défaillante, ou cookies bloqués par un plugin de consentement RGPD trop strict.
• Directives PHP sous-dimensionnées : mémoire ou temps d’exécution insuffisants quand le panier contient beaucoup de variations, de règles de prix ou de plugins tiers actifs au checkout.
• SSL ou contenu mixte : un certificat expiré, mal configuré, ou des ressources chargées en HTTP sur une page HTTPS bloquent silencieusement les scripts de paiement.
• Passerelle mal configurée : clés API de test au lieu de production, webhook non déclaré, devise incompatible, 3D Secure mal implémenté.
• SMTP absent ou cassé : les e-mails de confirmation partent du serveur avec la fonction mail() native de PHP, systématiquement filtrés en spam ou jamais délivrés.

1. Vérifier le cache (cause n°1 du panier qui se vide)

C’est le premier réflexe, et il résout une bonne partie des cas. Le panier WooCommerce dépend d’une session PHP unique par visiteur : si une page de cache sert un contenu statique sur /panier/ ou /checkout/, le panier apparaît vide ou incohérent d’un rechargement à l’autre.

• Exclue explicitement les pages Panier, Commande et Mon compte du cache, dans les réglages de ton plugin de cache. Ce point est détaillé dans notre guide sur les meilleurs plugins de cache WordPress.
• Si un CDN (Cloudflare, etc.) met en cache le HTML de ces pages, ajoute une règle de contournement (“bypass cache”) sur ces URLs.
• Vide le cache serveur (souvent nommé “object cache” ou “page cache” dans le panel de l’hébergeur) après chaque modification.

Un site généralement lent aggrave aussi ce symptôme : si les requêtes AJAX du panier mettent plusieurs secondes à répondre, WooCommerce peut afficher un état transitoire incohérent. Notre article sur accélérer un site WordPress lent détaille le diagnostic complet.

2. Isoler un conflit thème/plugin sur le checkout

Écran blanc, bouton “Passer la commande” qui ne réagit plus, champs de facturation qui disparaissent : ce sont les signatures classiques d’un conflit JavaScript ou PHP.

Méthode par élimination :

1. Active le thème par défaut de WordPress (Twenty Twenty-Four) temporairement, en environnement de test si possible.
2. Désactive tous les plugins sauf WooCommerce et la passerelle de paiement.
3. Réactive un par un, en testant le checkout à chaque étape.
4. Note le plugin fautif : c’est souvent un plugin de pop-up, de tracking, ou une extension de champs de checkout personnalisés qui charge un script en double.

Si le problème est apparu juste après une mise à jour automatique, consulte notre guide sur le plugin cassé après mise à jour et le rollback propre : c’est exactement le même protocole de diagnostic. Un écran totalement blanc sur /checkout/ répond au même mécanisme qu’un écran blanc de la mort WordPress classique.

3. Régler les directives PHP qui bloquent les gros paniers

Un panier avec beaucoup de variations produit, des règles de remise complexes, ou plusieurs plugins actifs simultanément au moment du checkout consomme davantage de ressources serveur que la moyenne. Si les directives PHP sont trop basses, le checkout timeout ou plante silencieusement.

• memory_limit : la mémoire allouée à PHP pour exécuter le script. Trop basse, elle provoque une erreur “Allowed memory size exhausted” au moment du calcul du panier. Valeur de départ raisonnable : 256M, à monter à 512M sur un catalogue volumineux avec beaucoup d’extensions.
• max_execution_time : le temps maximum qu’un script PHP peut tourner. Trop bas, le calcul des frais de port ou l’appel à la passerelle est interrompu en cours de route, laissant le client sur une page qui charge indéfiniment. Valeur de départ : 60 secondes minimum au checkout.
• max_input_vars : le nombre de champs de formulaire que PHP accepte de recevoir. Un checkout avec beaucoup de champs personnalisés (facturation, livraison, options produit) peut dépasser la limite par défaut et perdre silencieusement des données. Valeur conseillée : 3000.
• post_max_size et upload_max_filesize : pertinents si le processus de commande inclut un upload (justificatif, personnalisation). Une valeur trop basse déclenche une erreur 413.

Ces réglages se font dans wp-config.php (via ini_set), dans le php.ini de l’hébergement, ou dans le panel de gestion PHP si ton hébergeur en propose un (Hostinger, IONOS, Plesk…). Le détail complet, avec les syntaxes exactes selon l’endroit où tu interviens, est dans notre guide sur les directives PHP WordPress. Une erreur générique de type “erreur critique” au checkout mérite aussi de lire notre guide sur la résolution de l’erreur critique WordPress.

4. Vérifier le SSL et le contenu mixte

Une passerelle qui refuse systématiquement le paiement, alors que la carte est valide, cache parfois un problème de certificat plutôt qu’un vrai refus bancaire.

• Vérifie que le certificat SSL est valide et à jour. Un certificat expiré déclenche NET::ERR_CERT_DATE_INVALID et bloque les scripts de paiement embarqués (Stripe Elements, PayPal SDK). Voir notre guide dédié : certificat SSL expiré.
• Traque le contenu mixte : une ressource (image, script) chargée en HTTP sur une page HTTPS fait planter les navigateurs modernes qui bloquent l’exécution des scripts de paiement par sécurité. Le guide complet : corriger le contenu mixte WordPress.
• Si le checkout redirige en boucle vers la page de paiement sans jamais aboutir, vérifie aussi les règles de redirection HTTP/HTTPS : ce symptôme ressemble à celui décrit dans notre article sur ERR_TOO_MANY_REDIRECTS.

5. Diagnostiquer la passerelle elle-même

Si le SSL est propre et qu’aucun conflit plugin n’apparaît, le problème vient souvent de la configuration de la passerelle (Stripe, PayPal, CB en direct) :

• Clés API : vérifie que tu n’utilises pas des clés de test en environnement de production (erreur fréquente après une migration).
• Webhooks : Stripe et PayPal ont besoin d’un webhook correctement déclaré pour confirmer la commande côté serveur. Sans lui, le paiement passe mais la commande WooCommerce reste “en attente” indéfiniment.
• Devise et pays : un mismatch entre la devise configurée dans WooCommerce et celle acceptée par le compte marchand bloque silencieusement certaines transactions.
• Logs : chaque passerelle sérieuse expose des logs de transaction (dans WooCommerce > Statut du système > Logs, ou dans le dashboard Stripe/PayPal). C’est là que se trouve la vraie raison du refus, pas dans un message générique côté client.

6. Réparer les e-mails de commande absents

Le paiement passe, mais ni le client ni toi ne recevez de confirmation : c’est un problème d’envoi d’e-mail, pas de WooCommerce lui-même. Par défaut, WordPress envoie via la fonction mail() de PHP, systématiquement mal notée par les filtres anti-spam.

La solution durable : configurer un envoi via SMTP authentifié (Resend, ou ton fournisseur d’e-mail pro). Deux guides couvrent ce point en détail selon ta situation : configurer Resend pour l’envoi d’e-mail et réparer les e-mails WordPress qui n’arrivent pas. Si tu utilises un formulaire de contact en parallèle du tunnel de vente, le même souci touche souvent Contact Form 7. Vérifie aussi tes enregistrements SPF, DKIM et DMARC : sans eux, même un SMTP bien configuré peut finir en spam, comme expliqué dans notre guide sur la délivrabilité e-mail.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Ces réglages résolvent la majorité des blocages courants. Mais si le problème touche simultanément plusieurs de ces symptômes (panier instable, e-mails absents, paiement refusé par intermittence), c’est souvent le signe d’un socle technique fragile — hébergement sous-dimensionné, plugins accumulés sans cohérence, ou migration bâclée d’une agence à l’autre. À ce stade, un audit complet du taux de conversion et de la stabilité technique vaut mieux qu’un rustinage plugin par plugin : c’est le rôle d’une maintenance structurée, plutôt que des correctifs isolés qui reviennent chaque trimestre.