Quand le paiement ne passe plus sur une boutique PrestaShop, le risque n’est pas seulement technique. Le risque immédiat, ce sont les commandes perdues pendant que vous testez plusieurs pistes en même temps.

Le plus utile est d’avancer dans un ordre court : symptôme exact, mode test ou production, clés API, notifications ou webhooks, compatibilité après mise à jour, puis logs. À la fin de ce guide, vous saurez quoi vérifier sans brouiller le diagnostic, quoi faire tout de suite pour limiter les pertes, et quand basculer vers un diagnostic de bug de paiement PrestaShop.

Commencez par identifier le type de panne

Avant toute action, séparez la panne en familles de symptômes. Un moyen de paiement absent, un clic qui échoue, et un paiement accepté sans commande n’ont pas la même logique technique. Si vous mélangez ces cas, vous risquez de corriger la mauvaise couche.

Cette étape vous aide aussi à savoir si vous êtes face à un problème d’affichage du moyen de paiement, à un blocage dans le tunnel, ou à un défaut de retour entre le prestataire de paiement et la boutique. Si votre doute porte plutôt sur l’ensemble du tunnel, regardez aussi les pannes du panier et du tunnel de commande PrestaShop.

Le moyen de paiement a disparu à l’étape de commande

Ici, le client n’atteint même pas l’étape de validation du paiement. Le symptôme est visuel : la méthode n’apparaît plus, ou n’apparaît que dans certains parcours. Notez tout de suite si la disparition touche tous les clients, tous les transporteurs, tous les pays, ou seulement un cas précis.

Dans cette situation, ne partez pas d’abord sur les webhooks. Vérifiez en priorité ce qui contrôle l’affichage du moyen de paiement : état du module, changement récent de configuration, et évolution du tunnel côté boutique.

Le bouton est visible mais le paiement échoue au clic ou à la redirection

Deuxième cas : le moyen de paiement est bien là, mais le clic renvoie une erreur, une boucle, une redirection ratée ou un refus immédiat. Ici, les causes à vérifier en premier sont le mode test ou production, puis les identifiants API.

Ne concluez pas trop vite que le module est défectueux. Un mauvais environnement ou une clé incohérente peut produire exactement ce type de symptôme.

Le paiement est accepté par le PSP mais la commande n’apparaît pas dans PrestaShop

C’est le cas le plus sensible. Le client a payé, le prestataire de paiement indique une opération acceptée, mais aucune commande n’est créée, ou l’état de commande reste incohérent. Ici, il faut penser au retour technique du PSP vers PrestaShop, pas seulement au clic de paiement.

Le bon réflexe est de mettre de côté la question du front-office et de contrôler les notifications, webhooks et journaux d’événements.

Vérifiez d’abord le mode test ou production, puis les clés API

C’est le premier triage à faire. Tant que vous n’avez pas validé l’environnement et les identifiants, il est trop tôt pour incriminer une mise à jour ou un bug plus profond. Ce contrôle prend peu de temps et évite beaucoup d’allers-retours.

Repérer un mélange entre test et production

Le piège classique est simple : un module réglé pour la production avec des identifiants de test, ou l’inverse. PayPal signale aussi qu’un mélange sandbox et production fait partie des causes classiques d’erreurs d’authentification ou de configuration. Stripe distingue clairement les clés de test et de production dans sa documentation officielle Authentication | Stripe API Reference (consulté le 2026-10-27).

Sur Stripe, une clé secrète de test commence par sk_test_, une clé live par sk_live_, et une clé restreinte live par rk_live_. Si ces préfixes ne correspondent pas au mode activé dans le module, vous avez une piste solide.

Contrôler les clés et identifiants sans les confondre

Comparez ce qui est enregistré dans le module avec ce qui est attendu dans le bon environnement du compte PSP. Le but n’est pas de remplacer des valeurs au hasard, mais de vérifier que chaque identifiant correspond bien au mode actif.

Travaillez proprement. Relevez les réglages présents avant toute modification. Vous gardez ainsi la possibilité de revenir au dernier état fonctionnel connu.

Vérifier si un changement récent a réécrit la configuration

Si la panne est apparue juste après une intervention, une mise à jour ou une migration, partez de l’idée qu’un réglage a pu être modifié. Un module de paiement peut rester actif tout en ayant perdu une partie de sa configuration.

Posez-vous une question simple : qu’est-ce qui a changé depuis le dernier paiement réussi ? Cette étape évite de lancer un diagnostic trop large.

Si le paiement part mais que la commande n’arrive pas, contrôlez les notifications et webhooks

Quand le client paie mais que PrestaShop ne crée pas la commande, le problème ne se situe pas toujours au moment du clic. Il peut se trouver dans le retour d’information envoyé par le prestataire de paiement vers la boutique. Ce type d’incident doit donc être traité à part.

Ce qu’un webhook manquant casse réellement

Un webhook qui n’arrive pas, qui répond mal, ou qui pointe vers une mauvaise URL peut empêcher la boutique de recevoir l’information attendue après le paiement. Côté PayPal, la documentation précise qu’une URL de webhook doit être enregistrée, liée à un abonnement d’événements, disposer d’un Webhook ID, écouter en HTTPS sur le port 443 et répondre en HTTP 2xx. Sinon, PayPal retente l’envoi jusqu’à 25 fois sur 3 jours Integrate webhooks | PayPal Developer (mis à jour le 2026-06-18).

Autrement dit, un paiement peut sembler abouti côté PSP alors que la boutique n’a pas reçu, ou pas validé correctement, l’événement qui devait créer ou mettre à jour la commande.

Ce qu’il faut vérifier côté PayPal

Contrôlez d’abord l’URL réellement déclarée, puis l’abonnement aux événements attendus, puis l’identifiant du webhook utilisé par le module. Si le module vérifie la signature, il doit s’appuyer sur le bon identifiant de webhook et sur le corps brut de la requête.

Ne vous limitez pas à la simple existence du webhook. Un webhook présent mais mal rattaché, ou qui ne répond pas correctement, produit souvent le même résultat métier : paiement reçu, commande absente ou incomplète.

Pourquoi une simulation ne suffit pas

Un test de simulation peut rassurer à tort. Il peut aider à valider un listener, mais il ne prouve pas que les vrais événements de production arrivent bien jusqu’au module dans votre chaîne réelle.

Si vous avez un doute, partez d’une transaction récente, cherchez l’événement réel côté prestataire, puis comparez-le avec ce que la boutique a enregistré. C’est le contrôle le plus fiable.

Contrôlez ensuite ce qui a changé juste avant la panne

Une panne de paiement qui apparaît sans cause évidente suit souvent un changement récent : mise à jour de PrestaShop, mise à jour du module, réactivation d’un ancien réglage, ou environnement modifié. Le plus rentable est donc de regarder l’historique immédiat.

Après une mise à jour PrestaShop, revérifiez le Module Manager

La documentation officielle PrestaShop recommande, après une mise à jour, de vérifier le Module Manager, de réactiver les modules désactivés si nécessaire, puis de tester le front-office avec un vrai parcours de commande Post-update checklist | PrestaShop Developer Documentation (consulté le 2026-10-27).

Sur une boutique en production, regardez si le module de paiement a été désactivé, si un autre module du tunnel a changé d’état, et si le problème est apparu juste après cette intervention.

Relisez la compatibilité et les réglages sensibles du module

Si la panne a démarré après une évolution de la boutique, comparez la version de PrestaShop avec la compatibilité annoncée par le module, puis relisez les réglages sensibles. Un module déclaré compatible sur une version donnée ne doit pas être considéré comme automatiquement fiable après chaque mise à jour.

Si vous voulez repérer ce type de risque avant qu’il coupe votre tunnel, lisez aussi les signaux d’un module PrestaShop mal codé.

Testez tout le tunnel, pas seulement le bouton de paiement

Un module peut sembler actif et pourtant échouer seulement dans le parcours réel. C’est pour cela qu’un test complet du tunnel reste utile après une mise à jour : panier, adresse, transporteur, paiement, retour de confirmation.

Évitez aussi la formule trop large du type “la mise à jour a cassé les paiements”. La bonne question est plus précise : quel changement a rendu ce module, dans ce tunnel, incompatible ou mal configuré ?

Lisez les logs utiles avant d’activer le debug partout

Quand les contrôles précédents n’ont rien donné, passez aux logs. C’est l’étape qui permet de revenir à des faits : message d’erreur, moment exact, et composant concerné. PrestaShop dispose d’une page Logs dans le back-office pour consulter les erreurs et les actions de la boutique Logs | PrestaShop 8 documentation (consulté le 2026-10-27).

Où chercher en premier

Commencez par relever l’heure d’un échec réel, puis cherchez cette plage dans les logs de la boutique et dans les journaux du module si le prestataire en fournit. Le but n’est pas de lire tout le journal, mais de corréler un essai précis avec un message précis.

Si la panne fait apparaître une erreur serveur plus large, la méthode ressemble à celle d’un diagnostic d’erreur 500 sur PrestaShop : isoler l’instant, le composant, puis la modification récente.

Quand activer le mode debug

Le mode debug peut aider, mais ce n’est pas le premier levier. Activez-le seulement si les logs ne suffisent pas, et seulement le temps du diagnostic. La documentation PrestaShop précise qu’il a un impact significatif sur les performances. Une fois le message utile récupéré, coupez-le.

Cette règle est importante en production : le debug doit servir à confirmer une piste, pas à remplacer une méthode de triage.

Ce qu’il faut corréler entre boutique, module et PSP

Un diagnostic propre ne repose pas sur une seule source. Vérifiez ensemble l’heure de l’action client, l’erreur éventuelle côté boutique, l’état remonté par le module, et l’événement visible côté PSP. Sans cette corrélation, vous risquez de confondre un refus au clic avec une absence de webhook.

À ce stade, résistez à la tentation de désactiver plusieurs modules en production “pour voir”. Vous brouilleriez le diagnostic et vous perdriez la trace de la cause initiale.

Pendant la panne, limitez les pertes et décidez vite si vous escaladez

Pendant l’incident, l’objectif est double : éviter d’aggraver la panne et garder une trace exploitable des paiements en attente.

Si le triage dans cet ordre ne suffit pas, mieux vaut passer à une intervention ciblée. KLN-WEB propose un support PrestaShop ponctuel ou au mois, avec diagnostic gratuit, réponse sous 24 h et devis sous 24 h ouvrées.

Questions fréquentes

Pourquoi le module de paiement a disparu à l’étape de commande sur PrestaShop ?

Quand le moyen de paiement disparaît, traitez d’abord le problème comme un défaut d’affichage ou de disponibilité dans le tunnel, pas comme un problème de webhook. Vérifiez si la disparition touche tous les clients ou seulement certains parcours. Un paiement absent ne se diagnostique pas comme un paiement accepté sans commande, et cette distinction évite de chercher au mauvais endroit.

Comment savoir si mon module est resté en mode test au lieu du mode production ?

Comparez le mode activé dans le module avec l’environnement utilisé dans votre compte PSP. Sur Stripe, les clés secrètes de test commencent par sk_test_ et les clés live par sk_live_. Si le module est en production avec des clés de test, ou l’inverse, le paiement peut échouer immédiatement alors que la configuration semble correcte.

Où vérifier les clés API Stripe ou PayPal quand le paiement ne passe plus ?

Le contrôle se fait à deux endroits : dans la configuration du module de paiement dans PrestaShop, puis dans le bon environnement du compte Stripe ou PayPal. Le point clé est la cohérence entre le mode actif et les identifiants enregistrés. Avant toute modification, relevez les réglages présents pour pouvoir revenir au dernier état connu.

Pourquoi le paiement est accepté côté banque ou PSP, mais la commande n’apparaît pas dans PrestaShop ?

Ce cas oriente souvent vers un problème de retour technique entre le prestataire de paiement et la boutique. Il faut alors contrôler les notifications ou webhooks, l’URL déclarée, l’abonnement aux événements attendus, et la façon dont le module traite ce retour. Un paiement validé côté PSP ne garantit pas à lui seul que PrestaShop a bien reçu l’événement nécessaire à la création de la commande.

Que faut-il contrôler juste après une mise à jour de PrestaShop ou du module de paiement ?

Après une mise à jour, vérifiez d’abord l’état du module dans le Module Manager, puis sa compatibilité annoncée avec la version de la boutique. Ensuite, testez un vrai parcours de commande sur le front-office. Le plus important est de ne pas conclure trop vite que la mise à jour a “cassé” le paiement sans avoir identifié le réglage ou l’incompatibilité en cause.

Où trouver les logs utiles dans PrestaShop pour diagnostiquer un échec de paiement ?

PrestaShop propose une page Logs dans le back-office. Utilisez-la avec une méthode simple : notez l’heure exacte d’un échec, puis cherchez les entrées correspondantes dans les logs de la boutique, du module et du prestataire de paiement si vous y avez accès. Si vous activez le mode debug, faites-le uniquement le temps du diagnostic puis désactivez-le aussitôt.