Paiement reçu, mais pas de commande dans PrestaShop

Le relevé PayPal ou bancaire montre le paiement. Dans Commandes, rien. Parfois une commande existe, mais vide, ou au statut « Erreur de paiement » ; parfois le client a payé deux fois. Il attend son colis et va bientôt écrire. Un paiement reçu sans commande dans PrestaShop se règle presque toujours sans perte : il se retrouve et se rattache, à condition de ne rien faire payer une seconde fois.

Commencez par quatre vérifications qui ne modifient rien ; les trois messages en anglais qu’on croise sur ce sujet sont traduits plus bas. Menus donnés de la 1.6 à la 9, avec le point où il vaut mieux s’arrêter.

Quel est votre cas ?

Partez de ce que vous voyez. Chaque ligne renvoie à sa section ; les règles qui suivent passent avant tout essai.

Ce que vous voyez	Ce que cela veut dire, en général
Paiement chez le prestataire, aucune commande	Le client n’est pas revenu sur la boutique et la notification n’a pas abouti, ou la création de la commande a échoué.
Commande au statut « Erreur de paiement »	Montant différent du total du panier, ou paiement signalé refusé par le module. L’argent peut être là.
Commande sans produits, sans transporteur ou sans statut	La création s’est arrêtée en route : PrestaShop enregistre la commande avant ses lignes.
Commande bloquée « En attente de paiement PayPal » ou « En attente de paiement »	Le prestataire n’a pas confirmé, ou sa notification n’arrive plus.
Deux paiements pour un seul panier	Le client a cru que le premier avait échoué.
« Cart cannot be loaded or an order has already been placed using this cart » ou « Le panier ne peut être chargé… », dans Paramètres avancés > Logs	Souvent informatif. Un signal seulement s’il tombe avec l’un des cas ci-dessus.
« Webhook is disabled » module PayPal, depuis la version 6.1.0	Le module ne reçoit plus les changements de statut envoyés par PayPal.
« Expected an order id to be passed » fenêtre PayPal qui s’ouvre et se referme	Le client n’a pas pu payer : ni débit ni commande, mais une vente perdue.
Boutique en maintenance pendant des paiements	Le retour du client a reçu une erreur 503, comme les notifications de certains modules : des paiements sans commande sont possibles.

Un client qui s’impatiente déjà : appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h) ou décrivez-nous le problème.

Avant tout : ne faites rien payer une seconde fois

Une commande manquante se recrée. Un double débit, ou le remboursement du mauvais paiement, se rattrape beaucoup plus mal. Cinq règles :

1. Pas de nouveau lien de paiement, pas de « repassez commande » tant que vous n’avez pas regardé chez le prestataire.
2. Un remboursement seulement après les vérifications, chez le prestataire, avec l’identifiant de la transaction concernée.
3. Ne réinstallez, ne désactivez ni ne réinitialisez le module de paiement, et ne passez pas la boutique en maintenance : les paiements en cours pourraient perdre leur notification.
4. Notez pour chaque cas l’heure, le montant, l’e-mail du client et la référence de transaction.
5. N’envoyez à personne vos clés d’API, vos mots de passe ni un numéro de carte, ni par e-mail ni dans un formulaire. Ce diagnostic n’en a pas besoin.

Les vérifications, dans l’ordre

Quatre étapes en lecture seule : elles disent si l’argent est là et où la commande s’est perdue.

1. Le paiement existe-t-il chez le prestataire ?

Ouvrez le tableau de bord de PayPal, de Stripe, de PrestaShop Checkout ou de la solution de votre banque, et cherchez par montant, date et e-mail du client. Regardez l’état : un paiement encaissé (capturé) n’est ni une simple autorisation, ni un paiement « en attente », ni un paiement déjà remboursé. Les deux modules PayPal joignent le numéro du panier à chaque paiement, et certaines solutions bancaires le reprennent comme référence : s’il figure dans le détail, notez-le. Avant de comparer des heures, vérifiez le fuseau horaire de chaque écran.

Pas de paiement encaissé ? Rien à recréer. Un e-mail de confirmation ou une capture d’écran envoyés par le client ne remplacent pas cette vérification.

2. La commande existe-t-elle ? Et le panier ?

Dans Commandes > Commandes, filtrez sur le nom du client. Puis ouvrez Commandes > Paniers (Clients > Paniers en 1.6) : chaque panier affiche le numéro de sa commande, ou « Non commandé », ou « Panier abandonné » au-delà de 24 heures. Ouvrez celui du client à l’heure du paiement et comparez son total à la somme encaissée. Si rien n’apparaît sous son nom, filtrez les paniers sur la date du paiement, ou cherchez le numéro de panier relevé à l’étape 1 : l’adresse e-mail du compte PayPal n’est pas toujours celle du compte client.

• Panier « Non commandé » ou « Panier abandonné », paiement encaissé : la commande n’a jamais été créée. Passez à l’étape 3, puis recréez-la.
• Commande « Erreur de paiement » : soit le montant transmis par le module diffère du total du panier (PrestaShop pose alors ce statut, même si l’argent est arrivé), soit le module a signalé un paiement refusé. Ne recréez rien, la commande existe. Si la somme est encaissée et l’écart compris (arrondi, frais de port), passez-la à l’état payé, puis notez en message privé la référence de transaction et le montant reçu, car PrestaShop enregistre le reste dû comme payé ; sinon, arrêtez-vous.
• Commande « En attente de paiement » : comparez avec l’étape 1. Si rien n’est encaissé, laissez-la. Sinon, passez-la à l’état payé comme ci-dessus, sans la recréer, puis cherchez à l’étape 4 la notification bloquée.
• Commande incomplète, sans produits, transporteur ou statut : PrestaShop enregistre la commande avant ses lignes et son statut, sans tout annuler en cas d’erreur ; une panne au milieu la laisse incomplète. Ne la complétez pas dans la base : c’est un cas pour s’arrêter.
• « En attente de réapprovisionnement (payé) » : un produit était en rupture ; le paiement est enregistré, ce n’est pas une panne.

3. Ce que disent les journaux

Paramètres avancés > Logs liste les messages de PrestaShop avec leur « Gravité (1-4) », le « Type de l’objet » et l’« ID de l’objet ». Pour un paiement, l’objet est le panier : filtrez sur son numéro.

Ligne du journal (gravité)	Ce qu’elle veut dire
Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart gravité 1, toujours en anglais	Un visiteur revient avec un panier déjà commandé ; PrestaShop le retire de sa session. Information.
« Le panier ne peut être chargé ou une commande a déjà été réalisée avec ce panier » gravité 4, code d’erreur 1 ; en anglais sur une boutique en anglais	Un module a voulu créer une commande pour un panier déjà commandé, ou introuvable. Détail plus bas.
PaymentModule::validateOrder - Total paid amount does not match cart total gravité 3	Montant différent du total : « Erreur de paiement » (ligne écrite depuis la 1.7.8.6 ; avant, le statut est posé sans ligne).
PaymentModule::validateOrder - Module is not active gravité 3	Module de paiement désactivé, par exemple après une mise à jour : aucune commande possible.
PaymentModule::validateOrder - Secure key does not match gravité 3	Le retour ne correspond pas au panier : commande refusée.

Les modules tiennent aussi leur journal. Module PayPal de 202 ecommerce : lien « Vérification des logs » de son tableau de bord ; une ligne « Order validation error » y signale un paiement encaissé dont la commande a échoué. PrestaShop Checkout : fichiers ps_checkout du dossier var/logs/. Erreurs : var/logs/ (1.7.4 et plus) et journal d’erreurs PHP de l’hébergeur.

4. La notification de paiement arrive-t-elle ?

Une commande naît de deux façons : quand le navigateur du client revient sur la boutique, ou quand le prestataire appelle la boutique de serveur à serveur (notification, IPN ou webhook). Un client qui ferme l’onglet trop tôt ne laisse que la seconde voie, et encore faut-il que le module s’en serve. PrestaShop Checkout encaisse le paiement approuvé et crée la commande à partir de la notification si elle manque. Le module PayPal de 202 ecommerce, non : il la crée au retour du client.

Le tableau de bord du prestataire garde souvent l’historique des notifications et la réponse de la boutique. Celles de PrestaShop Checkout passent par les serveurs de PrestaShop, pas directement par PayPal. Le code de réponse oriente la recherche :

Réponse de la boutique	Piste
403	Un pare-feu bloque : Cloudflare, ModSecurity chez l’hébergeur, module de sécurité. Dans Cloudflare, regardez les événements de sécurité à l’heure du paiement, sur l’adresse du module.
401	Protection par mot de passe sur le site, souvent une préproduction devenue production.
503	Boutique en maintenance, ou serveur saturé (voir ci-dessous).
500	Erreur PHP en créant la commande : journal, puis diagnostic guidé de l’erreur 500.
404	Module de paiement désactivé (PrestaShop sert alors sa page 404), ou adresse périmée (ancien domaine).
400 (PrestaShop Checkout)	Notification rejetée par le module, à la vérification de signature ou au traitement : voir son journal.
405 (module PayPal)	Webhooks coupés ou jugés indisponibles.
422 (module PayPal)	Notification pour un paiement dont le module ne connaît pas la commande : sur une capture, bon indice que la commande n’a pas été créée au retour.

Mode maintenance. PrestaShop répond alors 503 à toute adresse de la boutique, sauf aux IP de maintenance et aux adresses exemptées, comme les webhooks des deux modules PayPal. Avec ces deux modules, un paiement PayPal classique ne finit pas sans commande : sans retour, rien n’est encaissé, ou la notification de PrestaShop Checkout crée la commande. Le paiement sans commande vient des modules où le client paie chez le prestataire, par exemple bancaires, quand leur notification n’est pas exemptée. Même erreur 503 que pendant un pic de trafic.

Cloudflare. Le « Bot Fight Mode » peut défier ce trafic sans navigateur, et la documentation de Cloudflare précise qu’aucune règle d’exception ne le contourne : s’il bloque, il faut le couper ou passer au « Super Bot Fight Mode », qui accepte les exceptions. Le mode « Under Attack » impose une page de vérification en JavaScript, qu’une notification ne passe jamais ; la documentation propose de le limiter à certains chemins par une « configuration rule ».

« Cart cannot be loaded or an order has already been placed using this cart »

La traduction française, et les deux lignes du journal

Traduction officielle : « Le panier ne peut être chargé ou une commande a déjà été réalisée avec ce panier ». Le message sort de deux endroits du code :

• Précédé de « Frontcontroller::init – », en anglais, gravité 1 : un visiteur charge une page avec un panier qui a déjà donné une commande (il revient après avoir commandé, recharge la confirmation). PrestaShop retire ce panier de sa session et le note. Rien à faire.
• Seul, dans la langue de la boutique, gravité 4 : il vient de la création de commande (PaymentModule::validateOrder()). Un module a demandé une commande pour un panier qui en a déjà une, par exemple quand le retour du client et la notification sont arrivés tous les deux, ou pour un panier introuvable. Jusqu’à la 8, le client peut alors voir ce message sur une page blanche ; en 9, une page d’erreur générique.

Repère de version : depuis la 1.7.5.0, PrestaShop empêche le double clic sur le bouton de paiement (correctif #9373).

Sans gravité, sauf dans trois cas

Sur les forums, ce message passe pour anodin, et c’est vrai la plupart du temps. Une ligne de gravité 4 sur un panier déjà commandé peut même vouloir dire que la protection a joué : notification reçue deux fois, la seconde refusée, aucun doublon. Un mainteneur de PrestaShop le résume en 2024 : la ligne n’est pas le problème, elle peut en être le symptôme (discussion #9866). Prenez-la au sérieux si elle tombe avec :

1. un paiement encaissé sans commande à la même heure : panier introuvable, paiement peut-être orphelin ;
2. deux commandes, ou deux paiements, pour le même panier ;
3. une commande sans lignes, ou en « Erreur de paiement », à la même heure.

Deux conseils de forum reviennent et sont à éviter : modifier le compteur de la table des paniers dans la base, et surcharger le code du cœur pour faire taire la ligne. Le premier touche à la base, le second masque le symptôme, et aucun ne retrouve un paiement.

PayPal : « Webhook is disabled »

Ce texte, resté en anglais même dans un back-office français, vient du module PayPal de 202 ecommerce, depuis sa version 6.1.0. Il s’affiche avec une croix rouge dans la « Checklist Technique » du module, réservée au marchand. Il veut dire que la réception des webhooks est coupée : les changements de statut envoyés par PayPal (capture en attente qui aboutit, remboursement, annulation) ne s’appliquent plus d’eux-mêmes, et une commande « En attente de paiement PayPal » n’en bougera pas.

• Ce qu’il ne dit pas : qu’un paiement est perdu. Ce module crée la commande au retour du client, jamais à partir du webhook ni de l’IPN. Les réactiver ne fera pas apparaître une commande manquante.
• Pourquoi il apparaît sans que vous ayez rien touché : à l’enregistrement des réglages de statuts, le module demande à PayPal de créer le webhook. Si PayPal refuse, le module repasse le réglage à « non », sans afficher d’erreur.
• Un autre message, à ne pas confondre : « Les webhooks PayPal ne peuvent pas être activés », quand le réglage est actif mais que le module n’arrive pas à joindre sa propre adresse de webhook. Il donne ses causes : protection par mot de passe (htpasswd), https absent, certificat incorrect, réglages du serveur. Le pare-feu de l’étape 4 mérite le même regard.

PayPal : « Expected an order id to be passed », le client n’a pas payé

La fenêtre PayPal s’ouvre une fraction de seconde puis se referme. Le message vient du programme de PayPal chargé dans la page : la demande du module a échoué côté serveur, il n’a pas reçu d’identifiant de paiement.

Rien n’a été débité et aucune commande n’existe, donc rien à recréer ni à rembourser. Causes rapportées sur le forum de PrestaShop, pour PrestaShop Checkout :

• un code pays à trois lettres au lieu de deux dans la configuration ;
• un module resté en mode test ;
• une version du module défectueuse, corrigée par une version suivante.

Le journal du module et celui des erreurs PHP, à l’heure du clic, donnent la cause. En attendant, gardez un autre moyen de paiement actif, puis passez une commande test une fois la correction faite. Si le message persiste, appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h) ou décrivez-nous le problème.

Recréer la commande sans faire payer deux fois

Seulement si l’étape 1 a confirmé un paiement encaissé et qu’aucune commande n’existe pour ce panier. Créer une commande dans le back-office ne débite jamais le client : PrestaShop enregistre, il ne demande rien au prestataire.

S’il y en a plusieurs, exportez les transactions du prestataire sur la période, puis la liste des commandes des mêmes jours. Rayez chaque paiement qui a sa commande (montant et e-mail, ou numéro de panier, identiques). Les autres se traitent un par un, du plus ancien au plus récent, avec les étapes ci-dessous.

Depuis le panier du client

1. Ouvrez le panier trouvé à l’étape 2 et cliquez sur « Créer une commande avec ce panier ». Autre chemin : Commandes > Commandes > « Ajouter une commande », le client, puis « Utiliser » en face du panier payé (le même bouton en face d’une ancienne commande en ferait une copie).
2. Contrôlez produits, livraison et total. PrestaShop recalcule le panier aux prix du jour : promotion terminée ou bon de réduction expiré, et le total ne correspond plus à la somme encaissée. Dans ce cas, arrêtez-vous.
3. « Paiement » : le module par lequel le client a payé. « État de la commande » : l’état payé, en général « Paiement accepté ».
4. « Créer une commande ». Le client reçoit l’e-mail de confirmation (sauf avec « Erreur de paiement » ou « Annulé »), plus celui de l’état choisi s’il en a un ; le stock est décompté.
5. Sur la page de la commande, ajoutez un message avec la référence de transaction et la date du paiement, « Montrer au client » décoché. Le champ « Message de la commande » de l’écran de création, lui, remplace le commentaire du client, et le client le voit.

Cette commande n’est pas toujours reliée à la transaction : faites un éventuel remboursement chez le prestataire. Si PrestaShop répond « Le panier ne peut être chargé ou une commande a déjà été réalisée avec ce panier », une commande existe déjà pour ce panier, peut-être vide : ne forcez pas, c’est un cas pour s’arrêter.

Double paiement pour un panier

Parmi les demandes qui arrivent à notre support : un client qui croyait son paiement bloqué et a payé une deuxième, voire une troisième fois. Vérifiez chez le prestataire que chaque paiement est bien encaissé (une autorisation non capturée n’est pas un débit définitif), gardez celui qui correspond à la commande, remboursez les autres.

Remboursez le doublon chez le prestataire, avec son propre identifiant de transaction, jamais en changeant l’état d’une commande. Avec le module PayPal de 202 ecommerce, passer la commande à l’état de remboursement renvoie l’argent du paiement relié à cette commande, c’est-à-dire le bon.

Ce que vous dites au client

Écrivez-lui avant qu’il ne vous écrive, dès que le paiement est confirmé et avant de recréer la commande : il va recevoir un e-mail de confirmation, autant qu’il sache pourquoi.

Éviter que ça recommence

Un paiement sans commande passe inaperçu tant que personne ne compare les deux listes. Quelques habitudes suffisent à le voir le jour même :

• Rapprochez chaque jour, en période chargée, le nombre et le total des paiements du prestataire avec ceux des commandes.
• Passez une vraie commande test après chaque mise à jour du module de paiement, de PHP ou de PrestaShop, depuis la page de commande et depuis une fiche produit si un bouton de paiement y figure. Une mise à jour de module peut s’afficher réussie alors que sa partie base de données n’a pas été jouée : la boutique répond normalement, les notifications échouent.
• Une exception ciblée pour l’adresse de notification du module dans le pare-feu, plutôt qu’une protection coupée.
• Pas de mode maintenance pendant que des clients paient : sur un ticket de 2024 (#36277, PrestaShop 8.1.6), un client a été débité pendant la maintenance sans qu’aucune commande ne soit créée.
• Surveillez les états « en attente » du module : une commande qui y reste plus d’une journée signale souvent une notification bloquée.

Ce qu’on trouve quand une boutique arrive chez nous : un bouton PayPal de fiche produit en erreur 500 pour tous les visiteurs depuis près de quatre mois, sans qu’aucun client ne l’ait signalé. Ancien module PayPal, même résultat qu’avec « Expected an order id » : aucune vente par ce bouton, alors que la page de commande fonctionnait.

Avant un pic de ventes, ces contrôles figurent dans notre checklist Black Friday, section paiement. Pour déléguer le suivi de la boutique : maintenance PrestaShop à 69 € HT/mois, sans engagement, dépannage inclus.

Où s’arrêter

Les vérifications et une commande recréée depuis un panier intact, vous pouvez les faire seul. Arrêtez-vous si :

• plusieurs paiements sont sans commande et la cause reste inconnue, ou les nouveaux paiements continuent d’en manquer ;
• une commande existe déjà pour le panier, vide ou incomplète ;
• le total du panier ne correspond plus à la somme encaissée ;
• la correction passe par la base de données, un fichier du module ou du cœur, ou un pare-feu que vous ne gérez pas ;
• le module de paiement a été modifié sans vous, ou un paiement part vers un compte que vous ne reconnaissez pas : ne supprimez rien et lisez notre page sur le détournement de paiement.

Qui appeler ? Le support du prestataire répond sur votre compte : paiement encaissé ou non, historique des notifications, remboursement. L’éditeur du module, sur un défaut de son module. L’hébergeur, sur un pare-feu qu’il gère. Quand la cause est dans la boutique elle-même, ou que personne ne la trouve, c’est un dépannage.

Questions fréquentes sur le paiement reçu sans commande

Que veut dire « Cart cannot be loaded or an order has already been placed using this cart » ?

« Le panier ne peut être chargé ou une commande a déjà été réalisée avec ce panier ». Précédé de « Frontcontroller::init », en gravité 1, c’est une information. Seul, en gravité 4, un module a voulu créer une commande pour un panier déjà commandé ou introuvable : vérifiez que la commande existe et que le client n’a payé qu’une fois.

Un client a payé mais la commande n’apparaît pas : est-elle perdue ?

Non. Si le paiement est encaissé chez le prestataire, son panier existe dans Commandes > Paniers (Clients > Paniers en 1.6), marqué « Non commandé » ou « Panier abandonné ». La commande se recrée à partir de ce panier, sans nouveau paiement.

Comment transformer un panier en commande sans faire repayer le client ?

Ouvrez le panier, « Créer une commande avec ce panier », choisissez le module de paiement utilisé et l’état « Paiement accepté », puis « Créer une commande ». Vérifiez d’abord que le total correspond à la somme encaissée, et n’utilisez aucune action qui envoie un lien de paiement.

« Webhook is disabled » sur le module PayPal : est-ce grave ?

Aucun paiement perdu : ce module crée la commande au retour du client. Mais les changements de statut envoyés par PayPal (capture, remboursement, annulation) ne s’appliquent plus. Le réglage se coupe seul quand PayPal refuse de créer le webhook : réactivez-le et vérifiez qu’il reste actif.

« Expected an order id to be passed » : le client a-t-il été débité ?

Non. Cette erreur du programme de PayPal survient avant le paiement : la fenêtre se ferme, rien n’est débité et aucune commande n’existe. C’est une vente perdue, à corriger dans la configuration ou la version du module.

Les paiements passés pendant le mode maintenance sont-ils perdus ?

Pas l’argent, mais des commandes peuvent manquer : en maintenance, le retour du client reçoit une erreur 503, comme les notifications des modules qui ne s’en exemptent pas. Rapprochez les paiements de cette période avec les commandes, et recréez celles qui manquent depuis les paniers.

Combien coûte un dépannage quand des paiements arrivent sans commande ?

Chez CYBERIAL, dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h, au 09 72 03 59 17.

Un paiement reçu sans commande à régler ?

Le formulaire ci-dessous suffit : l’adresse de la boutique, le prestataire de paiement, l’heure et le montant du paiement concerné, le message affiché s’il y en a un. Choisissez « Paiement impossible » dans la liste. N’y écrivez ni clé d’API, ni mot de passe, ni numéro de carte.

Vous préférez en parler de vive voix : appelez le 09 72 03 59 17 (7j/7, de 8 h à 22 h). Une fois les paiements remis d’aplomb, pour un suivi régulier de la boutique : maintenance PrestaShop à 69 € HT/mois, sans engagement, dépannage inclus.