Problème de paiement PrestaShop : identifier l’origine du blocage

Un paiement qui échoue sur PrestaShop ne provient pas nécessairement du module bancaire. Le blocage peut se produire avant la redirection vers le prestataire, sur la page de paiement hébergée, lors du retour vers la boutique ou au moment de la confirmation par webhook. La priorité est donc de situer précisément l’étape défaillante, puis de croiser les journaux de PrestaShop, du serveur et du prestataire de paiement. Cette méthode évite de modifier des réglages au hasard ou de désactiver la sécurité du site sans raison.

Localiser l’étape exacte où le paiement échoue

Refaites un test avec une commande réelle à faible montant ou avec le mode test du prestataire, si celui-ci est correctement configuré. Utilisez une fenêtre de navigation privée afin d’écarter un panier, un cookie ou une session déjà corrompus. Notez l’URL, le message affiché et le moment précis du blocage.

1. Le bouton de paiement n’apparaît pas : le module peut être désactivé, soumis à des restrictions de devise, pays, groupe client, transporteur ou montant de commande.
2. Le clic ne produit rien ou affiche une erreur immédiate : recherchez une erreur JavaScript, une requête AJAX en échec, un jeton invalide ou une incompatibilité de thème/module.
3. La redirection vers la banque ou le PSP échoue : le problème concerne souvent les clés API, l’URL de retour, le réseau serveur, un pare-feu ou une configuration de compte marchand.
4. Le client paie mais la commande reste impayée ou absente : la notification serveur-à-serveur, aussi appelée webhook ou callback, n’atteint pas PrestaShop ou n’est pas validée.
5. Le paiement est refusé sur la page du prestataire : seul le prestataire, ou la banque émettrice dans certains cas, connaît le motif de refus. La boutique doit surtout vérifier que la transaction est bien créée et que les données envoyées sont cohérentes.

Conservez l’identifiant de panier PrestaShop, l’identifiant de commande éventuel, l’heure exacte avec son fuseau horaire et l’identifiant de transaction affiché par le prestataire. Ces éléments permettent de rapprocher les événements entre plusieurs journaux.

Contrôler PrestaShop avant d’incriminer le prestataire

Vérifier le module, ses restrictions et son environnement

Dans le back-office, ouvrez Gestionnaire de modules et contrôlez que le module de paiement est activé, à jour et compatible avec votre version de PrestaShop et de PHP. Une mise à jour de PHP ou du cœur de PrestaShop peut rendre un ancien module instable, notamment si ses dépendances Composer ne sont plus compatibles.

Contrôlez ensuite les restrictions du module : devises autorisées, pays de livraison, groupes clients, transporteurs et plages de montant. Un module peut fonctionner avec une commande de 20 € en France, mais disparaître pour une devise étrangère, un client B2B ou un transporteur spécifique. Testez avec le même profil que celui qui rencontre l’erreur.

Vérifiez aussi la distinction entre les identifiants de test et de production. Une clé API de test associée à un environnement de production, ou l’inverse, conduit fréquemment à une erreur de création de paiement. Ne copiez jamais une clé secrète dans un ticket ou dans un message non sécurisé ; régénérez-la si elle a été exposée.

Lire les journaux utiles

Activez temporairement le mode debug dans Paramètres avancés > Performances, puis reproduisez le problème sur un environnement de préproduction lorsque cela est possible. Le mode debug peut afficher des informations sensibles : désactivez-le après le test et ne l’utilisez pas durablement sur une boutique en production.

Selon la version et l’hébergement, examinez les fichiers de logs de PrestaShop dans var/logs/ ou les journaux affichés dans le back-office. Cherchez l’heure du test, le nom technique du module et des erreurs telles que 401, 403, 404, 500, cURL error, SSL ou une exception PHP. Un code 401 indique généralement une authentification refusée ; un 403 peut signaler un pare-feu ou une règle de sécurité ; un 500 impose de lire l’erreur PHP associée.

Ne cherchez pas de numéros de carte bancaire dans les logs : une intégration conforme ne doit pas les faire transiter ni les enregistrer dans PrestaShop. Les références de transaction et les identifiants de paiement suffisent au diagnostic.

Examiner le navigateur, le thème et les conflits JavaScript

Si le client reste sur la page de commande ou si le bouton est inactif, ouvrez les outils de développement du navigateur, onglet Console puis Réseau. Reproduisez l’action et repérez les requêtes en rouge. Une requête qui retourne 404 vers un fichier JavaScript de module révèle souvent un cache, une URL réécrite ou un déploiement incomplet. Une réponse 500 doit être corrélée aux logs PHP.

Désactivez provisoirement la concaténation, la minification et la mise en cache JavaScript dans les performances de PrestaShop, videz le cache, puis testez. Si le paiement refonctionne, réactivez les options une par une pour isoler le réglage concerné. Vérifiez aussi que le thème appelle bien les hooks prévus par le module sur la page de commande. Un override ou une personnalisation du checkout peut supprimer un conteneur, un script ou un jeton attendu.

Les outils de consentement aux cookies peuvent également bloquer les scripts d’un prestataire si celui-ci est classé à tort comme outil marketing. Le script indispensable au paiement doit rester disponible pour l’exécution de la transaction, tout en respectant la configuration de consentement et les obligations applicables à votre site.

Tester les échanges serveur avec le prestataire de paiement

Deux flux doivent être distingués. Le premier part généralement du navigateur vers le prestataire ou passe par la boutique pour créer une session de paiement. Le second revient du prestataire vers votre serveur pour confirmer le statut réel. Une redirection réussie ne prouve donc pas que la commande a été validée dans PrestaShop.

Dans le tableau de bord du prestataire, recherchez la transaction avec son heure ou sa référence. Si aucune transaction n’existe, la demande n’est pas arrivée : contrôlez les clés, la configuration du module et les sorties HTTPS de l’hébergement. Si la transaction est autorisée ou capturée mais que la commande est en attente, consultez le journal des notifications du prestataire et l’URL de callback renseignée par le module.

• L’URL de notification doit être accessible publiquement en HTTPS, sans authentification HTTP, restriction d’IP inadaptée ni redirection défectueuse.
• Le certificat SSL doit être valide pour le nom de domaine utilisé. Une chaîne de certificats incomplète peut empêcher certains services distants de joindre le site.
• Un WAF, ModSecurity, Cloudflare ou une règle anti-bot peut bloquer le callback. Recherchez l’IP, l’URL et le code de réponse dans les logs de sécurité avant de créer une exception ciblée.
• La signature du webhook doit rester activée. Ne contournez pas la vérification de signature pour « faire fonctionner » le paiement : corrigez plutôt le secret de webhook ou la configuration du module.

Écarter les problèmes d’hébergement et de configuration technique

Un serveur saturé, une limite PHP trop basse ou une tâche planifiée défaillante peuvent interrompre le traitement. Consultez les logs d’erreurs du serveur web et de PHP autour de l’incident. Recherchez notamment les dépassements de mémoire, les délais d’exécution, les erreurs de connexion à la base de données et les restrictions de requêtes sortantes. Si votre hébergeur applique une protection anti-fraude, fournissez-lui les horaires, URLs et adresses IP du prestataire concerné afin qu’il vérifie les blocages sans ouvrir inutilement tout le pare-feu.

Vérifiez enfin la cohérence de l’URL de boutique et du HTTPS dans les réglages de PrestaShop. Une boutique accessible à la fois avec et sans www, ou avec des redirections en chaîne, peut casser les URLs de retour. Utilisez une URL canonique unique, forcez HTTPS et testez le tunnel complet après toute modification.

Procédure de correction sans perdre de commandes

1. Ne désactivez pas le module en pleine période de vente sans prévoir une alternative de paiement visible.
2. Exportez ou notez les commandes et paniers concernés, avec leur statut et leur référence de transaction.
3. Corrigez une seule cause à la fois : clé API, URL de callback, règle WAF, cache ou compatibilité du module.
4. Videz le cache PrestaShop et celui du CDN si nécessaire, puis réalisez un paiement de test complet.
5. Contrôlez simultanément le statut côté prestataire et le statut créé dans PrestaShop.
6. Traitez manuellement les transactions déjà capturées mais non rapprochées, après vérification de leur authenticité, afin d’éviter une double expédition ou un double remboursement.

Si le diagnostic reste incertain, transmettez au support du module ou du prestataire un relevé factuel : version de PrestaShop, version du module, version PHP, URL concernée, heure du test, code d’erreur, référence de transaction et extrait de log anonymisé. Cette demande est bien plus exploitable qu’un simple « le paiement ne marche pas ».