Le client remplit son adresse, choisit sa livraison, arrive au paiement et lit : « Malheureusement, aucun moyen de paiement n’est disponible. » Il repart, panier plein. La boutique a l’air de tourner ; les ventes, elles, s’arrêtent au dernier écran. PrestaShop n’est pas cassé : la liste des moyens de paiement proposée à ce client est vide. Un réglage, le module lui-même ou le thème les a tous écartés.
Reste à trouver lequel, en partant de ce que le client a fait : pays, transporteur, compte, téléphone. Suivez ensuite les vérifications dans l’ordre. Menus donnés de la 1.6 à la 9 ; un encadré dit où vous arrêter.
Trouvez la cause dans le tableau de tri : tout le monde, ou certains clients seulement ?
Avec un seul transporteur : sa case a été décochée pour le module dans Paiement > Préférences.
Pour un pays, une devise, la commande sans compte : mêmes cases, autres blocs.
Pour tout le monde, depuis un changement : module désactivé, retiré du point d’accroche paymentOptions, ou compte de paiement déconnecté.
Après chaque correction : une commande test en navigation privée.
Plus aucune vente : 09 72 03 59 17, réponse en moins d’une heure, 7j/7, de 8 h à 22 h. Dépannage PrestaShop en urgence dès 150 € HT, prix fixe validé avant toute intervention.
« Aucun moyen de paiement n’est disponible » : le texte selon votre version
En anglais, la boutique affiche « Unfortunately, there are no payment method available. » (sic, faute d’origine). Le texte de la 1.6 en cinq étapes trompe : il parle de modules non installés alors qu’ils le sont souvent.
| Version | Ce que voit le client |
|---|---|
| 1.7, 8 et 9 thème Classic, et Hummingbird en 9 | « Malheureusement, aucun moyen de paiement n’est disponible. » Unfortunately, there are no payment method available. |
| 9.2, module « One-page checkout » activé | La même phrase, dans la commande sur une page. |
| 1.6, commande en cinq étapes | « Aucun module de paiement n’a encore été installé. » No payment modules have been installed. |
| 1.6, commande sur une page | « Aucun moyen de paiement disponible. » No payment method is available for use at this time. |
| 1.6, module Advanced EU Compliance | « Il n’y a actuellement pas de moyen de paiement disponible pour votre commande. Veuillez nous contacter si le problème persiste. » |
Le sens ne change pas : aucun module n’a rien proposé à ce client, soit qu’il ait été écarté, soit qu’il se soit retiré. Ce n’est pas un panier à 0 € (« Aucun paiement nécessaire pour cette commande », de la 1.7 à la 9), ni « Il n’y a malheureusement aucun transporteur pouvant livrer à votre adresse » (étape livraison). Une page d’erreur ou blanche au paiement relève du diagnostic guidé de l’erreur 500.
Tous les clients, ou certains seulement ?
PrestaShop filtre par pays, devise, groupe du client, transporteur, boutique et, jusqu’à la 8, appareil : un message limité à certains clients désigne en général l’un de ces filtres.
| Le message apparaît… | À regarder |
|---|---|
| avec un transporteur, pas avec les autres | Restrictions par transporteurs 1.7 à 9 |
| pour les livraisons vers un pays, ou outre-mer | Restrictions des pays |
| dans une devise seulement | Restrictions des devises |
| en commande sans compte, ou pour un type de client | Restrictions des groupes |
| pour certains montants seulement | Les réglages du module |
| sur téléphone seulement | Module désactivé sur mobile 1.6 à 8 |
| sur une seule boutique d’une multiboutique | Réglages de cette boutique |
| pour tout le monde, depuis un module, une mise à jour, une migration ou un thème | Le module et sa greffe, puis après un changement. Plus aucune vente : 09 72 03 59 17 |
| pour tout le monde, avec PrestaShop Checkout ou PayPal pour seul moyen | Le compte relié au module |
Tester sans perdre de client
Dans le doute, refaites la commande en navigation privée comme le client, puis changez un seul élément : celui qui fait revenir le paiement donne la ligne. Inutile de payer, la liste s’affiche dès l’étape paiement. Commandez sans compte pour tester le groupe Invité, ou avec un compte de test livré dans le pays du client.
Pendant la recherche : limiter les commandes perdues
Tant que le message s’affiche, les clients touchés repartent sans commander. Le temps de trouver la cause (ou de nous la confier), sans toucher au code :
- Un bandeau visible jusqu’à la page de commande (bloc de texte du thème) : « Paiement en ligne momentanément indisponible, commandez au … ». Pas de mode maintenance : il ferme toute la boutique.
- Transfert bancaire (« Virement bancaire » en 1.6), s’il est installé et convient à vos clients : cochez-le pour le pays, la devise, le transporteur ou le groupe en panne.
- Commandes > Paniers (Clients > Paniers en 1.6) liste tous les paniers ; ceux sans commande y sont marqués « Non commandé » ou « Panier abandonné », avec le client et le transporteur. Rappelez ceux créés depuis le début de la panne ; un transporteur commun est un indice.
Paiement > Préférences : les cases qui manquent
Chaque bloc croise vos modules avec des devises, des groupes, des pays et, depuis la 1.7, des transporteurs ; une case vide écarte le module. Le piège : un module de paiement coche ce qui existe le jour de son installation. Ce qui est ajouté ensuite arrive souvent décoché.
- En multiboutique, choisissez d’abord la boutique concernée.
- Ouvrez Paiement > Préférences (menus de la 1.6 dans le tableau ci-dessous).
- Dans le bloc désigné par le tableau de tri, cochez la case du module, enregistrez.
- Passez une commande test, dans les conditions du client.
Bon réglage : chaque pays livré, transporteur actif, devise et groupe (Invité, Client et ceux que vous avez créés) a au moins un module coché. Attention : en 1.7.8 à 9, cliquer sur le nom d’un module coche ou décoche toute sa colonne ; rien n’est enregistré avant « Enregistrer ».
| Écran | 1.7, 8 et 9 | 1.6 |
|---|---|---|
| Restrictions de paiement | Paiement > Préférences | Modules et services > Paiement |
| Modules | Modules > Gestionnaire de modules | Modules et services > Modules et services |
| Greffes | Apparence > Positions | Modules et services > Positions |
| Pays | International > Zones géographiques > Pays | Localisation > Pays |
| Taxes (« Basé sur ») | International > Taxes | Localisation > Taxes |
| Transporteurs | Livraison > Transporteurs | Transport > Transporteurs |
| Groupes | Paramètres de la boutique > Clients > Groupes | Clients > Groupes |
| Paniers | Commandes > Paniers | Clients > Paniers |
| Cache, surcharges | Paramètres avancés > Performances | |
| Journaux | Paramètres avancés > Logs | |
Un transporteur décoché pour le module
De la 1.7 à la 9, un transporteur créé dans le back-office est coché d’office pour tous les modules de paiement installés. S’il ne l’est pas, la case a été décochée (de la 1.7.8 à la 9, un clic sur le nom d’un module vide toute sa colonne), ou bien, en multiboutique, il a été créé alors qu’une seule boutique était sélectionnée : il n’est coché que pour celle-là. Vérifiez-le avant une opération, comme le rappelle notre checklist Black Friday, et cochez-le dans « Restrictions par transporteurs ». La 1.6 ne filtre pas par transporteur.
En 1.7.5 et 1.7.6, deux transporteurs du même nom (Colissimo en crée plusieurs) n’avaient qu’une ligne, et enregistrer pouvait retirer l’autorisation des autres : renommez-les, puis cochez.
Le pays de livraison
PrestaShop teste le pays de l’adresse de livraison (de facturation si vos taxes sont « basées sur » elle). Le module est coché pour les pays actifs le jour de son installation. Un pays activé plus tard ne l’est pas toujours : en 9.2, l’activer depuis la liste des pays ne coche rien côté paiement.
Outre-mer : la Guadeloupe, la Martinique ou La Réunion sont des pays à part pour PrestaShop ; cocher la France ne les couvre pas.
La devise du panier
Même logique : une devise créée à la main après le module n’est pas cochée pour lui (importée avec un pack de localisation, elle l’est). Cochez-la dans « Restrictions des devises ».
Le groupe du client : la commande sans compte
Un client qui commande sans créer de compte est dans le groupe Invité. Décoché, il perd le paiement ; avec un compte, tout marche. Idem pour un groupe de professionnels. Le réglage existe aussi dans la fiche du groupe (Paramètres de la boutique > Clients > Groupes ; Clients > Groupes en 1.6) : « Modules autorisés ».
Multiboutique : boutique par boutique
Les cases sont enregistrées boutique par boutique. Une boutique créée sans reprendre les données d’une autre peut démarrer sans aucune case cochée.
La cause est plus loin : greffe, surcharge, thème, compte de paiement. Nous la cherchons pour vous, dès 150 € HT, déduits si vous passez ensuite à la maintenance.
Tous les clients touchés : le module lui-même
Dans cet ordre :
- Actif, dans le gestionnaire de modules.
- Greffé. Apparence > Positions, case « Afficher les points d’accroche invisibles » cochée, puis cherchez
paymentOptions(displayPaymenten 1.6). Si votre module manque, « Greffer un module » l’y remet. - Sans exception sur la commande. Dans cette greffe, la liste des exceptions ne doit pas contenir la page de commande (
order, ouorderopcen 1.6 avec la commande en une page) : le module y serait ignoré. - Configuré. Un montant minimum ou maximum (réglé dans le module, ou propre à chaque moyen chez PrestaShop Checkout) le retire des petits ou gros paniers. Un compte en attente de validation ou une licence expirée peut le faire disparaître sans message ; seuls ses journaux le disent.
Seulement sur téléphone
De la 1.6 à la 8, un module peut être désactivé sur mobile (« Désactiver sur mobile », menu d’actions du gestionnaire de modules) : le paiement disparaît des seuls téléphones. La 9 n’applique plus ce réglage.
Après une migration depuis la 1.6
Un module dans une version écrite pour la 1.6 seule ne se greffe souvent que sur displayPayment. La 1.7, la 8 et la 9 n’appellent plus ce point d’accroche pour proposer un paiement : il faut une version du module écrite pour votre version de PrestaShop.
PrestaShop Checkout ou PayPal : le compte doit être relié
Cases cochées ou non, ces deux modules se retirent d’eux-mêmes quand leur compte n’est pas prêt.
- PrestaShop Checkout (v5) ne propose rien sans compte PayPal relié et prêt à recevoir des paiements, ni compte PrestaShop associé. La devise du panier doit être acceptée par PayPal et cochée pour le module. Puis chaque moyen (carte, Bancontact, paiement en plusieurs fois…) a ses conditions de pays, de devise et de montant : l’un peut disparaître sans les autres.
- Le module PayPal (202 ecommerce, v6) ne s’affiche pas si la connexion à PayPal n’est pas configurée ou si PayPal la refuse. Autre cas : sa liste d’adresses IP de test. Remplie, elle réserve PayPal à ces adresses ; le module demande de la vider après le test.
Pour PrestaShop Checkout, l’aide officielle de l’éditeur fait vérifier les modes activés dans le module, les cases de Paiement > Préférences, puis vider le cache ; son guide de dépannage ajoute la reconnexion du compte PayPal. En 2024, sur un forum, un changement de thème l’avait rendu muet jusqu’à sa réinitialisation et cette reconnexion. La validation du compte relève du prestataire ; le reste se règle sur la boutique : nous pouvons nous en charger.
Que demander au support de votre prestataire
Le support de PrestaShop Checkout, de PayPal, de Stripe ou de la solution de votre banque (Systempay…) ne voit que votre compte. Demandez-lui :
- si le compte est validé et peut recevoir des paiements, sans restriction en cours ;
- quels pays, devises et montants il accepte pour votre compte ;
- quelle version du module il recommande pour votre version de PrestaShop ;
- s’il voit des erreurs ou des refus venant de votre boutique depuis le début de la panne.
Donnez l’adresse de la boutique, les versions de PrestaShop et du module, la date de début. Jamais vos clés. Compte en ordre de son côté ? La cause est sur la boutique.
Apparu après une mise à jour, un thème ou une migration
Le message a suivi un changement alors que réglages et module sont en ordre : ces pistes touchent toute la boutique.
- Le thème. Un thème personnalisé a souvent sa propre étape de paiement (
templates/checkout/_partials/steps/payment.tpl) ; ancien ou modifié, il peut mal afficher la liste. Pour le vérifier, repassez au thème Classic sur une boutique de test. - Les surcharges. Un fichier dans
override/classes/nomméHook.php,PaymentModule.phpoucheckout/PaymentOptionsFinder.phpchange le choix des paiements. Le test, « Désactiver toutes les surcharges » (Paramètres avancés > Performances), se fait sur une copie : il coupe aussi celles dont vos autres modules ont besoin. - Les modules tiers coupés. En 1.6 et 1.7, « Désactiver les modules non développés par PrestaShop » (Paramètres avancés > Performances) doit rester sur Non. En 8 et 9, l’option a quitté le back-office mais reste lue si elle était activée avant la mise à jour ; la corriger se fait en base : arrêtez-vous là.
- Le cache. « Vider le cache » (Paramètres avancés > Performances) une fois, sans risque. Mais PrestaShop ne met pas en cache la liste des modules de paiement : si le message revient, la cause est ailleurs.
Enfin, les journaux : Paramètres avancés > Logs, var/logs/ (1.7.4 et plus), et ceux du module de paiement s’il en tient. Un module de paiement modifié sans vous relève du piratage : lisez notre page boutique PrestaShop piratée avant tout.
Revenir en arrière
- Cases de Paiement > Préférences : faites une capture de chaque bloc avant d’y toucher ; pour annuler, recochez d’après la capture et enregistrez.
- Greffe ajoutée : « Dégreffer », au même endroit. « Désactiver sur mobile » : « Activer sur mobile » (« Afficher sur mobiles » en 1.6).
- Surcharges désactivées (sur la copie) : l’option revient sur Non. Cache vidé : rien à annuler.
- Module désinstallé, fichier ou base modifiés : seule une sauvegarde faite avant permet de revenir.
- Bandeau et virement ajoutés pendant la panne : une fois le paiement revenu, retirez le bandeau et décochez le virement là où vous ne le proposiez pas.
Cocher une case, greffer un module, vider le cache : faites-le seul. Thème, surcharges, fichier, base, journaux illisibles : arrêtez-vous, une erreur à ce niveau coupe plus que le paiement. Dépannage à prix fixe, validé avant toute intervention.
Ce qu’il ne faut pas faire pour retrouver le paiement
- Désinstaller puis réinstaller le module de paiement en production. Vous perdez ses restrictions et, selon le module, sa configuration ; « Réinitialiser » peut faire pareil. Si cela « répare », une case ou une greffe manquait et a été refaite au passage. À la place : la trouver.
- Vider et recréer la table
module_carrier. Vous retirez d’un coup toutes les autorisations par transporteur ; les cases de Paiement > Préférences suffisent. - Modifier
Hook.phpou un fichier du cœur pour supprimer les filtres. Écrasé à la mise à jour. À la place : la case, ou une version du module adaptée. - Tout cocher d’un coup. Certaines restrictions sont voulues : virement réservé aux professionnels, paiement à la livraison limité à un transporteur. À la place : la seule case qui manque.
- Coller une clé API, un identifiant PayPal ou Stripe sur un forum. Décrivez le symptôme : personne n’a besoin des clés pour diagnostiquer.
Questions fréquentes sur « aucun moyen de paiement n’est disponible »
Que veut dire « Malheureusement, aucun moyen de paiement n’est disponible » ?
Qu’aucun module de paiement n’a été proposé à ce client (en anglais : « Unfortunately, there are no payment method available »). Soit PrestaShop les a écartés (pays, devise, groupe, transporteur, boutique), soit les modules restants n’ont rien renvoyé.
Pourquoi le paiement disparaît-il avec un seul transporteur ?
Ce transporteur n’est coché pour aucun module dans Paiement > Préférences, « Restrictions par transporteurs ». À sa création, de la 1.7 à la 9, il l’est pour tous : la case a donc été décochée, ou, en multiboutique, il a été créé pour une autre boutique. Cochez-le pour chaque module, puis enregistrez.
Mon module de paiement est installé mais n’apparaît pas au paiement : pourquoi ?
Il doit être actif (pas désactivé sur mobile, de la 1.6 à la 8), greffé sur paymentOptions dans Apparence > Positions, coché pour le pays, la devise, le groupe et le transporteur du client, et configuré (compte relié, montant minimum ou maximum).
PrestaShop Checkout n’apparaît pas au paiement : que vérifier ?
Le compte PayPal relié depuis la configuration du module, le compte PrestaShop associé, les modes de paiement activés, puis la devise (acceptée par PayPal), le pays et le transporteur cochés dans Paiement > Préférences.
Le message est apparu après une migration de 1.6 vers 1.7, 8 ou 9 : pourquoi ?
Souvent, un module de paiement en version 1.6 ne se greffe que sur displayPayment, que la 1.7 et les suivantes n’appellent plus : il en faut une version adaptée. Vérifiez aussi que les transporteurs, pays et devises migrés sont cochés dans Paiement > Préférences.
Combien coûte un dépannage quand plus aucun paiement ne passe ?
Chez CYBERIAL, dès 150 € HT, prix fixe validé avant toute intervention : à mettre en face d’une journée de commandes bloquées. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h, au 09 72 03 59 17.
Vous préférez qu’on remette le paiement en route ?
Le message « aucun moyen de paiement n’est disponible » bloque vos ventes ? Choisissez « Paiement impossible » dans le formulaire ci-dessous. Dépannage dès 150 € HT ; pour fixer le prix avant toute intervention, indiquez :
- l’adresse de la boutique et votre version, si vous la connaissez ;
- le message affiché et le moyen de paiement concerné ;
- pour le client : pays de livraison, transporteur, avec ou sans compte, téléphone ou ordinateur.
N’écrivez ni mot de passe, ni clé API, ni identifiant de votre prestataire de paiement. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h.
Pour aller plus vite : 09 72 03 59 17. Ensuite, pour que chaque mise à jour soit testée sur une copie, avec sauvegarde et retour arrière : maintenance PrestaShop à 69 € HT/mois, sans engagement.
