# Problème de paiement ou de tunnel de commande PrestaShop

> Un client qui n’arrive pas à payer, c’est une vente perdue et souvent un panier abandonné en silence : il ne vous écrit pas forcément pour se plaindre. Je diagnostique le tunnel de commande étape par étape pour trouver où ça bloque réellement.

- Source canonique : [https://allaux.fr/prestashop/probleme-paiement](https://allaux.fr/prestashop/probleme-paiement)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Ouvrez Paramètres avancés > Journaux et repassez une commande de test : la ligne horodatée indique si le blocage vient du cœur ou du module de paiement. Si aucun moyen de paiement ne s’affiche, contrôlez les restrictions de pays, de devise et de groupe client dans la configuration du module. Une commande payée mais restée en attente signale une notification serveur-à-serveur qui n’arrive jamais.

## Ce qui m’amène sur ce type de dossier

- Le bouton de paiement ne répond pas ou renvoie une page blanche
- Un module de paiement (CB, PayPal, virement) a disparu de l’étape de paiement
- Le client est débité mais la commande reste en statut « en attente » côté PrestaShop
- Erreur au retour de la banque après authentification 3D Secure
- Un transporteur ou une méthode de paiement se bloque mutuellement à cause d’une restriction mal configurée
- Le paiement fonctionne en test mais pas en conditions réelles, ou l’inverse

## Où ça casse le plus souvent

Le tunnel de commande PrestaShop enchaîne plusieurs contrôles avant d’afficher les moyens de paiement : restrictions de transporteur, de groupe client, de devise, de pays de livraison. Si l’un de ces filtres est mal réglé, le module de paiement disparaît silencieusement sans message d’erreur explicite pour le client.

Côté validation, la confirmation d’une commande passe par le hook actionPaymentConfirmation et par l’appel à validateOrder() côté module de paiement. Quand la commande reste bloquée en attente malgré un paiement accepté par la banque, la cause est presque toujours un webhook ou une notification serveur-à-serveur (IPN) qui n’atteint jamais PrestaShop : pare-feu de l’hébergeur, URL de callback mal renseignée dans le back-office du prestataire de paiement, ou certificat SSL invalide qui fait échouer l’appel.

Un autre cas classique : une mise à jour de module de paiement change la version d’API utilisée (par exemple un passage forcé au SDK Stripe le plus récent) sans que la configuration ait été reprise, ce qui casse silencieusement les paiements par carte tout en laissant les autres méthodes actives.

## Comment je diagnostique

1. **Reproduction du parcours client** — Je passe une commande test de bout en bout, avec les mêmes conditions que le client bloqué (pays, devise, panier, transporteur).
2. **Vérification des restrictions** — Je contrôle les règles de restriction du module de paiement (groupes, transporteurs, pays) qui peuvent masquer une méthode sans avertissement.
3. **Contrôle des webhooks** — Je vérifie que les notifications du prestataire de paiement atteignent bien le serveur, en consultant les logs du module et, si besoin, le tableau de bord du prestataire.
4. **Test en conditions réelles** — Je vérifie le comportement en mode production, pas seulement en bac à sable, car certains blocages n’apparaissent qu’avec de vraies clés API.

## Pages liées

- **Passerelle de paiement** — Ce qui se passe entre le clic « payer » et l'autorisation bancaire, et où la chaîne peut rompre. ([/glossaire/passerelle-de-paiement](/glossaire/passerelle-de-paiement))
- **Tunnel de commande** — Les étapes que traverse une commande, et celles qui font abandonner le client quand elles échouent. ([/glossaire/tunnel-de-commande](/glossaire/tunnel-de-commande))
- **Paiement bloqué sous WooCommerce** — Le même symptôme sur l'autre plateforme : causes différentes, méthode de diagnostic comparable. ([/wordpress-woocommerce/probleme-paiement](/wordpress-woocommerce/probleme-paiement))
- **Dépannage urgent** — Quand les commandes ne passent plus, l'intervention se traite en priorité, pas après un cycle de devis. ([/services/depannage-urgent](/services/depannage-urgent))

## FAQ

### Une commande payée mais restée en attente va-t-elle être doublement facturée au client ?

Non, l’argent a déjà été prélevé par la banque une seule fois. Le problème est que PrestaShop n’a pas reçu la confirmation, il faut donc rapprocher manuellement la transaction et valider la commande.

### Faut-il changer de module de paiement pour régler le problème ?

Rarement en premier réflexe. Dans la majorité des cas la cause est une configuration ou un webhook mal réglé, pas le module lui-même. Je ne recommande un changement que si le module est réellement abandonné.

### Quels accès dois-je vous donner ?

Un accès back-office PrestaShop, un accès FTP ou SSH, et si possible un accès au tableau de bord du prestataire de paiement (Stripe, PayPal, etc.) pour vérifier les notifications envoyées.

### Est-ce que je risque de perdre des commandes pendant l’intervention ?

Non, je travaille sans interrompre la boutique. Les commandes déjà enregistrées ne sont pas touchées, et le tunnel de commande reste accessible pendant le diagnostic sauf cas exceptionnel que je signale à l’avance.

### Combien de temps pour rétablir un paiement en panne ?

Un blocage de restriction, c’est le type de problème qui se règle dans la journée quand l’accès au back-office et au serveur est disponible. Un problème de webhook ou de certificat SSL dépend en revanche d’un tiers : le délai est celui de la réponse de l’hébergeur ou du prestataire de paiement, pas le mien.