# Un moyen de paiement disparaît du tunnel de commande après une mise à jour PrestaShop

> Un module de paiement qui fonctionnait très bien peut ne plus s’afficher au client après une mise à jour PrestaShop, sans qu’aucune erreur ne s’affiche nulle part dans le back-office. Trois causes reviennent : un point d’accroche que le module n’utilise plus depuis PrestaShop 1.7, des restrictions de pays, devise ou groupe de client réinitialisées, ou un module désactivé automatiquement parce que marqué incompatible avec la nouvelle version installée.

- Source canonique : [https://allaux.fr/prestashop/problemes/moyen-paiement-disparait-apres-maj](https://allaux.fr/prestashop/problemes/moyen-paiement-disparait-apres-maj)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Ouvrez Modules > Gestionnaire de modules, entrez dans la configuration du module de paiement et rétablissez les restrictions de pays, de devise et de groupe client qu’une mise à jour a réinitialisées. Si elles sont correctes, le module s’accroche sans doute encore à displayPayment au lieu de paymentOptions, qui l’a remplacé depuis PrestaShop 1.7.

## Le point d’accroche a changé avec la version 1.7

Avant PrestaShop 1.7, les modules de paiement affichaient leurs boutons via le hook displayPayment. À partir de la 1.7, ce mécanisme a été remplacé par le hook paymentOptions, qui fonctionne différemment : le module doit renvoyer des objets de type option de paiement plutôt que du HTML brut affiché directement.

Un module resté conçu pour l’ancien hook peut très bien s’installer sans erreur après une montée de version : PrestaShop ne signale pas qu’un hook est inutilisé, il l’ignore silencieusement. Le module reste visible dans Modules et services, actif, configuré, mais rien ne s’affiche plus dans le tunnel de commande. C’est la cause la plus fréquente d’une disparition après une migration vers la 1.7 ou une version supérieure.

## Restrictions pays, devise et groupe de client

Chaque module de paiement a son propre écran de réglage, avec des restrictions par pays, devise et groupe de client. Ces restrictions permettent, par exemple, de ne proposer un moyen de paiement qu’aux clients français payant en euros.

Après une mise à jour du module lui-même, ces réglages peuvent se réinitialiser ou se désynchroniser : un pays qui était coché repasse décoché, ou une plage de devises autorisées redevient vide. Le module reste actif, mais ne correspond plus à aucune commande en cours, donc n’apparaît jamais au client. C’est une vérification à faire avant de chercher plus loin.

## Un module peut aussi être désactivé automatiquement

> PrestaShop peut désactiver de lui-même un module qu’il considère incompatible avec la version installée. Ce cas se voit dans la liste des modules, marqués « incompatible » ou grisés, plutôt que dans le tunnel de commande directement.

## Comment je vérifie, dans l’ordre

1. **Le module est-il toujours actif ?** — Je vérifie dans Modules et services qu’il n’a pas été désactivé automatiquement après la mise à jour, et qu’il ne s’affiche pas comme incompatible.
2. **Le hook attendu est-il bien enregistré ?** — Je regarde si le module est toujours accroché à paymentOptions (ou à l’ancien displayPayment pour les versions antérieures à la 1.7), et s’il répond correctement à cet appel.
3. **Les restrictions du module sont-elles correctes ?** — Pays, devises et groupes de client autorisés : je vérifie qu’aucune de ces listes ne s’est vidée ou n’exclut, par erreur, la commande en cours de test.
4. **Le module lui-même est-il à jour ?** — Si le module reste incompatible malgré ces vérifications, la mise à jour doit venir de son éditeur, ou le module doit être adapté au nouveau mécanisme de paiement.

## Pages liées

- **Tunnel de commande et paiement en panne** — Le diagnostic complet quand un client n’arrive pas du tout à payer, étape par étape dans le tunnel de commande. ([/prestashop/probleme-paiement](/prestashop/probleme-paiement))
- **Migration PrestaShop 1.6 vers 1.7 ou 8** — Pourquoi une montée de version majeure casse certains modules, et comment vérifier leur compatibilité avant de migrer. ([/prestashop/migration](/prestashop/migration))
- **Développement d’un module PrestaShop sur mesure** — Quand un module de paiement doit être réécrit ou adapté au nouveau mécanisme plutôt que simplement reconfiguré. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### Le module ne s’affiche plus, mais je ne vois aucune erreur : est-ce normal ?

Oui, c’est le comportement le plus fréquent. PrestaShop n’affiche pas d’erreur quand un module utilise un hook qui n’est plus appelé par le tunnel de commande : le module reste actif en apparence, mais personne ne le voit jamais côté client.

### Dois-je réinstaller le module depuis zéro ?

Rarement. Dans la majorité des cas, une reconfiguration des restrictions ou une réactivation suffit. Une réinstallation complète n’est nécessaire que si la configuration existante est corrompue.

### Le module vient d’un éditeur tiers, dois-je attendre sa mise à jour ?

Si le module utilise encore l’ancien hook displayPayment sur une boutique passée en 1.7 ou plus, oui : seul l’éditeur peut publier une version compatible, sauf à faire réécrire le module en développement sur mesure.

### Comment savoir si c’est un problème de hook ou de restriction ?

Si le module n’apparaît pour aucun client, quelle que soit sa commande, c’est presque toujours le hook. S’il n’apparaît que pour certains profils ou certains pays, ce sont les restrictions qu’il faut vérifier en premier.

### Dois-je m’attendre à ce que ça se reproduise à chaque nouvelle version PrestaShop ?

Pas systématiquement, mais chaque montée de version majeure mérite de revérifier les modules de paiement avant de la déployer en production, surtout ceux qui n’ont pas été mis à jour depuis longtemps.