Lorsqu’un client ne peut plus commander sur PrestaShop, le problème peut apparaître à des endroits très différents : bouton d’ajout au panier inactif, panier qui se vide, transporteur absent, paiement refusé ou retour vers la page de commande sans création de commande. Le bon réflexe n’est pas de modifier des réglages au hasard, mais d’identifier précisément l’étape qui bloque, de reproduire le parcours et de consulter les erreurs techniques. Ce guide permet de diagnostiquer une commande PrestaShop impossible, sans confondre un incident de paiement, de livraison, de stock ou d’affichage.
Commencer par localiser l’étape exacte du blocage
Effectuez un test comme un visiteur, dans une fenêtre privée du navigateur et sans être connecté au compte administrateur. Ajoutez un produit simple au panier, créez une adresse de test, choisissez un transporteur, puis lancez le paiement. Notez l’URL, le message affiché et le moment précis où le parcours échoue. Faites aussi le test sur mobile : certains modules ou scripts de consentement ne produisent l’erreur que sur un format d’écran.
- Le produit ne s’ajoute pas au panier : recherchez une erreur JavaScript, un conflit de thème ou un jeton de sécurité invalide.
- Le panier se vide ou ne conserve pas l’adresse : contrôlez les cookies, le domaine, le HTTPS et les mécanismes de cache.
- Aucun transporteur ou moyen de paiement n’est proposé : vérifiez les restrictions de zone, groupe client, devise, poids, prix et pays.
- Le paiement est accepté mais aucune commande n’apparaît : examinez le module de paiement, ses journaux et le retour serveur (callback ou webhook).
- Une erreur 500, 403 ou page blanche s’affiche : traitez d’abord l’erreur serveur ou PHP avant de toucher à la configuration commerciale.
Vérifier que la boutique est réellement accessible à l’achat
Mode maintenance et accès catalogue
Dans le back-office, ouvrez les paramètres de maintenance, généralement accessibles depuis Paramètres de la boutique > Paramètres généraux > Maintenance. Une boutique en maintenance peut rester accessible à certaines adresses IP autorisées alors que tous les clients voient une page de fermeture. Désactivez la maintenance si elle n’est pas volontaire, ou ajoutez seulement votre IP pour vos tests. Vérifiez aussi que le catalogue et les produits concernés sont actifs sur la bonne boutique dans un contexte multiboutique.
Sur une fiche produit, contrôlez le statut actif, la visibilité, les déclinaisons par défaut et les associations de boutique. Un produit peut être visible mais impossible à commander si sa déclinaison obligatoire n’est pas disponible ou si les quantités autorisées ne le permettent pas.
Stock, quantités minimales et paramètres de commande
Dans la fiche produit, regardez la quantité disponible, le comportement en cas de rupture et la quantité minimale de commande. Une quantité minimale réglée à 2 empêchera par exemple de commander une seule unité. Pour les produits à déclinaisons, la quantité se contrôle souvent au niveau de chaque combinaison, pas uniquement au niveau du produit principal.
Les préférences de commande peuvent également interdire la commande si aucun produit n’est en stock. Ce réglage peut être pertinent pour éviter les ventes non livrables, mais il doit être cohérent avec votre gestion de stock. Testez avec un produit en stock réel plutôt qu’avec un article de démonstration.
Diagnostiquer les transporteurs absents à la commande
Un transporteur n’apparaît que si toutes ses conditions correspondent au panier et à l’adresse. Dans Livraison > Transporteurs, vérifiez qu’il est actif et associé à la boutique concernée. Contrôlez ensuite ses zones de livraison, ses tranches de prix ou de poids, et les groupes clients autorisés.
Un cas fréquent est une adresse française associée à une zone non couverte, ou un panier dont le poids dépasse la dernière tranche définie. Si les frais sont calculés au poids, créez une tranche qui couvre le poids maximal possible. Si les frais sont calculés au prix, assurez-vous qu’aucun intervalle ne laisse un trou entre deux tranches. Vérifiez aussi les dimensions et le poids des produits : une valeur incohérente peut faire sortir le panier des règles prévues.
Les modules de points relais ajoutent leurs propres contraintes. Un module peut afficher le transporteur, mais empêcher la validation tant qu’un point relais n’a pas été sélectionné. Testez son sélecteur avec l’adresse du client et vérifiez les clés API, l’environnement activé et les éventuelles erreurs retournées par le transporteur.
Contrôler les paiements sans supposer que PayPal ou Stripe est en cause
Un moyen de paiement peut être masqué par ses restrictions, même si le module est installé. Dans les réglages du module, vérifiez les devises, pays, groupes clients et transporteurs autorisés. Une restriction sur le transporteur est particulièrement facile à oublier après l’ajout d’un nouveau mode de livraison.
Vérifiez les identifiants API, les clés de signature et le mode utilisé : des identifiants de test ne fonctionnent pas en production, et inversement. Consultez les journaux du module ainsi que la liste des commandes : une commande peut avoir été créée avec un statut en attente, alors que le client croit avoir échoué après un retour mal configuré.
Les paiements redirigés reposent souvent sur une notification serveur envoyée par le prestataire vers votre site. Si cette URL de notification renvoie une erreur, est protégée par une authentification, redirige vers un autre domaine ou est bloquée par un pare-feu, le paiement peut être débité sans mise à jour correcte de la commande. Ne désactivez pas la sécurité globalement : autorisez uniquement les requêtes légitimes nécessaires et vérifiez les réponses HTTP dans les logs du serveur.
Repérer les erreurs techniques : logs, navigateur et mode debug
Pour une erreur visible ou silencieuse, consultez d’abord les journaux d’erreurs PHP et du serveur web auprès de l’hébergeur. Recherchez l’heure exacte du test, puis le message associé : dépassement de mémoire, erreur fatale PHP, fichier manquant, droit d’écriture ou blocage de règle de sécurité. Une erreur 500 n’est pas un problème de commande à régler dans le back-office ; elle nécessite d’abord son message technique.
Le mode debug de PrestaShop peut afficher le détail d’une exception. Activez-le temporairement dans un environnement de préproduction lorsque c’est possible. Sur une boutique en production, activez-le seulement pendant un test court et contrôlé : une trace peut révéler des chemins de fichiers ou des informations techniques aux visiteurs. Désactivez-le immédiatement après l’analyse.
Dans les outils de développement du navigateur, l’onglet Console révèle les erreurs JavaScript et l’onglet Réseau permet d’identifier une requête en échec. Une réponse 403 sur un fichier JavaScript, une erreur CORS sur un service externe ou une requête AJAX en 500 peut suffire à bloquer le bouton de commande. Testez après avoir désactivé temporairement les optimisations JavaScript du thème ou du module de cache, puis réactivez-les une par une.
Écarter les conflits de thème, modules et cache
Une mise à jour de module, de thème, de PHP ou de PrestaShop peut casser le tunnel de commande sans modifier les données produits. Commencez par relever les changements récents. Videz le cache PrestaShop depuis le back-office et, si votre infrastructure en utilise un, purgez aussi le cache CDN ou serveur. Un cache ne doit jamais servir les pages panier, commande, connexion ou compte client comme des pages publiques identiques pour tous.
Pour isoler un conflit, faites les essais sur une copie de préproduction avec une sauvegarde de fichiers et de base de données. Désactivez provisoirement les modules non essentiels intervenant dans le panier ou le checkout : paiement express, fidélité, relance panier, consentement, livraison, personnalisation ou optimisation. Réactivez-les un par un en refaisant le même parcours. Évitez de modifier directement les fichiers du cœur ou d’un module : la correction serait écrasée à la prochaine mise à jour.
Vérifier domaine, SSL, cookies et configuration serveur
Un panier qui disparaît est souvent lié à la session. Assurez-vous que l’ensemble du parcours utilise un seul domaine canonique, avec ou sans www, et que les redirections HTTP vers HTTPS sont cohérentes. Un aller-retour entre deux domaines peut empêcher le navigateur de renvoyer le cookie de session attendu. Vérifiez les URL de la boutique configurées dans PrestaShop, puis testez les pages panier et commande sans redirection en chaîne.
Après un changement de version PHP, contrôlez la compatibilité de votre version de PrestaShop et de vos modules. Consultez également les droits d’écriture sur les répertoires de cache et de logs si les erreurs signalent un échec de création de fichiers. Enfin, si un pare-feu applicatif, un plugin de sécurité d’hébergement ou une règle anti-fraude a été ajouté, vérifiez qu’il ne bloque pas les requêtes POST du checkout ni les retours des prestataires de paiement.
Procédure de correction sûre avant remise en ligne
- Créez une sauvegarde complète de la base de données et des fichiers avant toute mise à jour ou modification.
- Reproduisez l’erreur avec un produit, une adresse et un paiement de test documentés.
- Corrigez une seule cause à la fois, puis videz les caches concernés.
- Testez au minimum un paiement, un transporteur, un compte client existant et une commande invité si cette option est proposée.
- Vérifiez dans le back-office la création de la commande, l’état du paiement, l’envoi d’e-mail et la décrémentation du stock.
- Surveillez les logs après remise en ligne pour détecter rapidement une récidive.
Si le problème est apparu après une mise à jour ou concerne des paiements réels, intervenez d’abord sur une préproduction. Les commandes en attente doivent être rapprochées des transactions du prestataire avant tout remboursement ou nouvel encaissement, afin d’éviter les doublons.
Pourquoi le bouton « Commander » est-il grisé dans PrestaShop ?
Le bouton peut être grisé lorsqu’une condition obligatoire n’est pas remplie : acceptation des conditions générales, choix d’un transporteur, sélection d’un point relais ou champ d’adresse invalide. Ouvrez la console du navigateur pour vérifier qu’une erreur JavaScript ne bloque pas aussi la validation du formulaire.
Une commande peut-elle être créée même si le client voit un échec de paiement ?
Oui. Certains modules créent une commande avec un statut en attente avant la confirmation finale du prestataire. Recherchez la référence de panier, l’adresse e-mail ou le montant dans le back-office et comparez avec le tableau de bord du prestataire avant de demander un nouveau paiement.
Comment tester le tunnel de commande sans perturber les vraies ventes ?
Utilisez une préproduction reliée à des identifiants de paiement de test, ou un moyen de paiement hors ligne réservé à un groupe de test. N’utilisez pas une carte bancaire réelle pour des essais répétés en production et annulez les commandes de test créées si elles affectent le stock ou les statistiques.
Le certificat SSL expiré peut-il empêcher une commande ?
Oui. Un certificat invalide déclenche un avertissement navigateur et peut empêcher le chargement de scripts, de contenus externes ou de redirections de paiement. Renouvelez le certificat, vérifiez la chaîne de certificats et testez toutes les variantes de domaine utilisées par la boutique.
Faut-il mettre PrestaShop à jour immédiatement pour corriger un checkout bloqué ?
Non. Une mise à jour peut corriger un bug, mais elle peut aussi introduire une incompatibilité avec le thème ou les modules. Identifiez d’abord l’erreur dans les logs, vérifiez la compatibilité, sauvegardez le site et testez la mise à jour sur une copie de préproduction.