Un problème de paiement est le plus coûteux de tous les bogues : le client était décidé, il avait sa carte en main, et quelque chose l’a arrêté. Pire, ces incidents sont souvent invisibles — vous ne voyez pas les commandes qui n’ont pas eu lieu.
Sur WooCommerce, ces problèmes se concentrent dans quelques mécanismes précis : les conditions d’affichage des passerelles, les notifications serveur à serveur, les zones de livraison, et les conflits d’extensions dans le tunnel.
Voici comment je les isole, et ce que je trouve le plus souvent.
Réponse rapide
Commencez par identifier si le problème touche tous les clients ou seulement certains : un moyen de paiement qui disparaît dépend généralement d’une condition — zone de livraison non couverte, montant minimum, devise, catégorie de produit. Une commande qui reste « en attente de paiement » alors que le client a payé signale presque toujours une notification serveur à serveur qui n’arrive pas : vérifiez l’adresse configurée chez le prestataire, les journaux de la passerelle, et que rien côté sécurité ou cache ne bloque ces requêtes. Consultez enfin les journaux WooCommerce (WooCommerce → État → Journaux), où la plupart des passerelles écrivent le détail des échanges.
Première question : tous les clients, ou seulement certains ?
Cette distinction oriente tout le diagnostic.
Tous les clients : la cause est globale. Passerelle mal configurée, clés en mode test alors que la boutique est en production, extension récemment mise à jour, certificat expiré, erreur JavaScript qui bloque la validation du formulaire.
Certains clients seulement : la cause est conditionnelle. Et c’est le cas le plus fréquent, comme le plus sournois — parce que vos propres tests, faits depuis votre adresse et avec votre panier habituel, ne reproduisent pas le problème.
Les conditions qui font disparaître un moyen de paiement :
- Le pays ou le code postal du client n’est couvert par aucune zone de livraison.
- Le montant du panier est sous le minimum de la passerelle, ou au-dessus de son plafond.
- Le panier contient un produit d’une catégorie exclue.
- La devise ne correspond pas à celles acceptées.
- Un produit virtuel ou téléchargeable modifie les règles appliquées.
Pour tester : simulez une commande avec l’adresse d’un client concerné. Si le moyen de paiement réapparaît en changeant le code postal, vous avez votre réponse.
Les commandes bloquées « en attente »
Le client a payé, sa banque a débité, mais la commande reste en attente dans votre back-office. C’est le symptôme d’une notification serveur à serveur non reçue.
Le principe : après le paiement, le prestataire envoie une requête directe à votre site pour confirmer. Cette requête ne passe pas par le navigateur du client. Si elle n’arrive pas, votre boutique ignore que le paiement a eu lieu.
Les causes habituelles :
Une adresse de notification erronée chez le prestataire. Cela arrive après un changement de domaine, le passage en HTTPS, ou une migration depuis une préproduction — l’adresse configurée pointe encore vers l’ancienne.
Un pare-feu ou une extension de sécurité qui bloque ces requêtes parce qu’elles viennent d’une adresse inconnue et n’ont pas de session utilisateur. Il faut autoriser explicitement les adresses du prestataire.
Un cache qui intercepte la requête et renvoie une réponse en cache au lieu de laisser WooCommerce la traiter. Les points d’entrée de paiement doivent toujours être exclus du cache.
Une erreur PHP pendant le traitement : la notification arrive bien, mais le code échoue. Les journaux de la passerelle, dans WooCommerce → État → Journaux, le montrent.
Vérification rapide : la plupart des prestataires conservent l’historique des notifications envoyées, avec le code de réponse de votre serveur. Un 200 signifie que votre site a bien reçu et accusé réception ; tout autre code, ou un échec de connexion, désigne l’origine du problème.
Le checkout qui refuse de se valider
Le client remplit tout, clique, et rien ne se passe — ou un message d’erreur apparaît sans explication.
Une erreur JavaScript
Une extension qui plante bloque la validation du formulaire. Ouvrez la console du navigateur sur la page de commande : une erreur en rouge au moment du clic désigne le script responsable.
Le conflit blocs / formulaire classique
WooCommerce propose deux implémentations du panier et du checkout : les blocs et l’ancien formulaire par code court. Certaines extensions ne sont compatibles qu’avec l’une des deux. Symptôme typique : un champ personnalisé ou un mode de livraison qui n’apparaît pas avec les blocs mais fonctionne avec le formulaire classique. Vérifiez quelle version vos pages utilisent réellement.
Des champs obligatoires invisibles
Un champ requis masqué par du CSS, ou situé dans une section repliée : le formulaire refuse de se valider sans que le client comprenne pourquoi. Le message d’erreur est parfois affiché hors de l’écran visible.
Une session perdue
Panier vidé au moment du paiement, client déconnecté en cours de route : souvent un cache mal configuré qui sert une page mise en cache à un visiteur identifié. Panier, commande et compte doivent être exclus du cache, sans exception.
La méthode que j’applique
- Reproduire. Avec les conditions exactes d’un client concerné : même pays, même type de produit, même montant. Sans reproduction, pas de diagnostic fiable.
- Activer les journaux de la passerelle. La plupart ont un mode de journalisation. Les échanges avec le prestataire y sont consignés, avec les codes d’erreur réels.
- Regarder la console du navigateur pendant le parcours de commande.
- Vérifier les notifications côté prestataire : historique des envois et codes de réponse.
- Tester avec un thème par défaut et sans extensions annexes si le doute persiste — sur une préproduction, jamais en production.
- Contrôler les exclusions de cache : panier, commande, compte, points d’entrée de paiement.
- Passer une vraie commande de bout en bout après correction, jusqu’à l’email de confirmation.
Les erreurs qui coûtent cher
Tester uniquement depuis son propre compte. Vous êtes connecté, vous avez peut-être un rôle particulier, votre adresse est en France, votre panier est habituel. Vous ne reproduisez pas les conditions de vos clients.
Laisser les clés en mode test. Cela arrive après une phase de recette. Symptôme : les commandes passent, mais aucun paiement n’arrive jamais sur le compte.
Ignorer les commandes en attente. Chaque commande bloquée est un client qui a payé sans recevoir de confirmation — et qui vous écrira, ou demandera un remboursement à sa banque.
Empiler les extensions dans le tunnel. Chaque ajout au checkout augmente la surface de conflit. C’est l’endroit du site où la sobriété rapporte le plus.
Modifier le checkout en production. Une erreur sur cette page n’est pas un défaut d’affichage : c’est un arrêt des ventes.
Checklist
- Déterminer si le problème touche tous les clients ou certains seulement
- Reproduire avec les conditions exactes d’un client concerné
- Vérifier les zones de livraison et les restrictions de la passerelle
- Activer les journaux de la passerelle et les lire
- Contrôler l’adresse de notification configurée chez le prestataire
- Vérifier l’historique des notifications et les codes de réponse
- Exclure panier, commande, compte et points de paiement du cache
- Ouvrir la console du navigateur pendant le parcours de commande
- Confirmer par une commande réelle, jusqu’à l’email de confirmation
Questions fréquentes
Mes commandes restent en attente alors que les clients ont payé.
C’est le scénario type d’une notification serveur à serveur qui n’arrive pas. Vérifiez l’adresse configurée chez votre prestataire, puis l’historique des notifications de son côté : le code de réponse de votre serveur vous dira si la requête arrive et ce qu’elle produit.
Un moyen de paiement a disparu pour certains clients.
Cherchez la condition : pays ou code postal hors zone de livraison, montant minimum, catégorie de produit exclue, devise. Simulez une commande avec l’adresse d’un client concerné, le moyen de paiement réapparaît généralement dès qu’on change le paramètre en cause.
Faut-il utiliser les blocs ou le formulaire classique ?
Les blocs sont la direction prise par WooCommerce et apportent de meilleures performances. Mais si une extension indispensable à votre activité n’est compatible qu’avec le formulaire classique, restez-y en attendant sa mise à jour : un checkout fonctionnel vaut mieux qu’un checkout moderne et cassé.
Combien de commandes est-ce que je perds ?
Impossible à connaître directement — les clients bloqués ne laissent pas de trace. Un indice utile : comparez le nombre d’entrées dans le tunnel de commande avec le nombre de commandes abouties. Un écart anormal sur un segment précis (un pays, un appareil) signale un blocage technique.
Pouvez-vous intervenir rapidement ?
Sur un paiement cassé, oui, dans la mesure de ma disponibilité — ces cas passent en priorité. Écrivez-moi sur WhatsApp avec le symptôme et le prestataire concerné.