Meilleurs modules de paiement pour PrestaShop : comparaison complète

Dernière vérification : juin 2026, les niveaux de frais de référence et le statut de maintenance des modules ont été contrôlés à partir des pages tarifaires actuelles des prestataires ; vérifiez les tarifs en vigueur avant de vous engager, car ils évoluent et deviennent négociables à partir d’un certain volume.

Cherchez « meilleur module de paiement pour PrestaShop » et vous tomberez sur un mur d’avis, dont la plupart sont rédigés par ceux qui vendent le module. Voici plutôt une lecture honnête : il n’existe pas de meilleur module de paiement universel, il existe celui qui convient à vos marchés, à votre panier moyen et au temps que vous acceptez de repasser dans le back-office l’année prochaine. Ce guide est la comparaison elle-même : les principaux modules de paiement réellement installés par les boutiques PrestaShop, leur coût par transaction, leur manière de s’intégrer à l’étape de paiement et un cadre de décision qui vous permet de savoir quels deux ou trois modules installer. Il porte volontairement sur le choix et l’exploitation des modules, pas sur un tour d’horizon pays par pays des habitudes de paiement, sujet que nous traitons séparément avec des liens lorsque c’est utile.

Ce que vous comparez vraiment : la passerelle est un module PrestaShop

Chaque option ci-dessous est, dans votre boutique, un module de paiement PrestaShop. C’est plus important que ne le laisse entendre le marketing, car c’est le module, et non la marque, qui détermine l’expérience à l’étape de paiement et la maintenance dont vous héritez. Deux critères séparent un bon module de paiement d’un risque pour votre boutique :

• La façon dont il s’affiche à l’étape de paiement. Les modules modernes s’enregistrent sur le hook paymentOptions (l’ancien hook displayPayment en 1.6) et renvoient un ou plusieurs objets PaymentOption, ce qui permet à un seul module de présenter plusieurs moyens de paiement, carte, iDEAL, BLIK, sous forme de boutons distincts à l’étape de paiement. Un module faible se contente d’injecter un lien de redirection et casse la continuité visuelle.
• Qui le maintient en vie. Un module de paiement communique avec une API externe qui évolue selon le calendrier du prestataire, pas le vôtre. Lorsque PayPal ou Stripe modifie une version d’API, un module maintenu publie une mise à jour et votre paiement continue d’encaisser ; un module abandonné échoue silencieusement au pire moment. Le « meilleur » choix dépend aussi de la personne ou de l’équipe qui maintient encore le code.

La vraie comparaison repose donc sur trois colonnes : les frais par transaction, les marchés que le module ouvre et la charge de maintenance qu’il laisse à votre back-office. Nous garderons ces trois dimensions en vue.

Si vous n’avez jamais vu à quoi ressemble ce hook dans la classe principale d’un module, voici tout le contrat, la méthode qui décide ce qu’un client voit à l’étape de paiement :

// In your_module.php – the modern hook every maintained gateway uses.
public function hookPaymentOptions($params)
{
    if (!$this->active) {
        return [];
    }

    $option = new \PrestaShop\PrestaShop\Core\Payment\PaymentOption();
    $option
        ->setModuleName($this->name)
        ->setCallToActionText($this->l('Pay by card'))
        ->setAction($this->context->link->getModuleLink(
            $this->name, 'validation', [], true
        ));
    // A single module can return several PaymentOption objects –
    // one per method (card, iDEAL, BLIK) – as separate buttons.
    return [$option];
}

Voilà la différence rendue concrète : un module qui renvoie un tableau propre d’objets PaymentOption s’intègre à l’étape de paiement native ; un module qui affiche à la place un lien de redirection brut est celui qui casse votre mise en page et devient difficile à réordonner. Lorsque vous évaluez un module, c’est ce comportement qu’il faut vérifier sur une commande de préproduction.

Les principaux modules de paiement en un coup d’œil

Le tableau ci-dessous donne la réponse courte. Les frais évoluent et peuvent se négocier au-delà d’un certain volume ; considérez donc les chiffres comme la base européenne publique au moment de la rédaction, vérifiez les tarifs actuels sur la page de prix du prestataire avant de vous engager. Chaque « nombre de moyens de paiement » correspond à ce que le module unique peut afficher dans votre étape de paiement.

Chacun de ces modules mérite plus qu’une ligne de tableau. Nous avons des guides dédiés et pratiques pour les deux que la plupart des boutiques finissent par installer, le parcours complet dans le back-office pour Stripe sur PrestaShop et Mollie comme passerelle multi-moyens de paiement, ainsi qu’un comparatif direct si vous hésitez entre les deux noms les plus connus dans Stripe vs PayPal. Pour le marché polonais en particulier, la configuration est un chantier à part entière : Przelewy24 pour PrestaShop.

Modules agrégateurs ou modules mono-moyen : la décision sous la décision

Avant de choisir des marques, choisissez une forme. Les marchands PrestaShop qui se trompent ici se retrouvent avec une étape de paiement encombrée et une maintenance pénible. Il existe deux formes :

Le module agrégateur (Mollie, Stripe)

Un seul module s’installe une fois, se connecte à un seul tableau de bord et affiche de nombreux moyens de paiement comme des boutons distincts à l’étape de paiement. Qu’est-ce que cela change pour vous ? Un seul ensemble de webhooks à surveiller, un seul écran de rapprochement, un seul élément à mettre à jour lorsqu’une API change, et vous pouvez activer ou désactiver un moyen de paiement dans la configuration du module sans rien installer de plus. Pour la plupart des boutiques, c’est le choix par défaut le plus juste, car le coût opérationnel d’un moyen de paiement se situe surtout dans la maintenance, pas dans les frais de transaction.

Le module mono-moyen (un Bizum dédié, une passerelle locale autonome)

Un module, un moyen de paiement, généralement parce que ce moyen n’est pas disponible via un agrégateur dans votre région, ou parce qu’une intégration directe réduit les frais par transaction à fort volume. Le compromis est réel : chaque module de paiement supplémentaire ajoute un autre point d’accroche dans la même étape de paiement, un autre endpoint de webhook, un autre cycle de mise à jour.

C’est l’erreur technique la plus courante que nous observons : empiler cinq ou six modules mono-moyen jusqu’à ralentir l’étape de paiement et déclencher des conflits. Comme règle de travail, limitez les modules de paiement simultanés à trois ou quatre : un agrégateur pour l’essentiel de vos moyens de paiement, PayPal pour la confiance des acheteurs, et au maximum un ou deux modules locaux dédiés lorsque l’agrégateur ne couvre pas le besoin. Au-delà, vous achetez des séances de débogage, pas des conversions.

Comment choisir : un cadre de décision

Avancez de haut en bas. La première question qui donne une réponse nette suffit généralement à trancher.

1. Sur combien de marchés vendez-vous réellement ?

• Un seul pays : installez le moyen local dominant avec PayPal comme solution de confiance de secours, puis arrêtez-vous là. Une boutique néerlandaise met iDEAL en avant ; une boutique polonaise met Przelewy24/BLIK en avant ; une boutique allemande met les moyens bancaires en avant. Ajouter des moyens de paiement que personne n’utilise sur ce marché ne fait qu’encombrer l’étape de paiement.
• Plusieurs pays de l’UE : commencez par un agrégateur (Mollie couvre le plus large éventail de moyens locaux européens dans un seul module), ajoutez PayPal, puis un module BNPL uniquement si votre catégorie en bénéficie. Cette configuration à trois modules couvre la grande majorité des préférences de paiement européennes tout en ne laissant qu’un seul tableau de bord d’agrégateur à rapprocher.

Si vous ne savez pas quels moyens locaux un marché attend, c’est une question de recherche à part entière, nous avons cartographié ce que les clients européens attendent à l’étape de paiement et les rails locaux précis dans BLIK, iDEAL et Bancontact.

2. Quel est votre panier moyen ?

En dessous d’environ 80 EUR, le BNPL justifie rarement ses frais plus élevés. Au-dessus, surtout dans la mode, le mobilier et l’art de vivre, une option d’achat immédiat avec paiement différé peut augmenter la part de clients qui finalisent un panier plus élevé, raison pour laquelle Klarna apparaît précisément sur ces boutiques. Savoir si ce gain vaut les frais se mesure boutique par boutique, ce n’est pas une garantie ; nous détaillons ce compromis dans ce que le BNPL signifie pour votre conversion.

3. Boutique axée cartes ou abonnements ?

Si la plupart de vos clients paient par carte et que vous n’avez pas besoin de rails locaux rares, les frais plus bas de Stripe sur les cartes de l’UE et sa prise en charge intégrée de la facturation récurrente en font le choix efficace, c’est aussi celui que les agences privilégient, car l’intégration et la documentation sont propres. Si la confiance envers la marque au moment du paiement est votre point de friction (nouvelle boutique, premiers achats, international), la notoriété de PayPal vaut ses frais plus élevés comme bouton secondaire.

L’intérêt plus large d’offrir plusieurs moyens de paiement, et pourquoi une seule passerelle laisse de l’argent sur la table, mérite un argumentaire à part entière, développé dans les moyens de paiement comptent : pourquoi plus d’options signifie plus de ventes.

Contrôles techniques avant de mettre un module de paiement en production

Comparer les frais est la partie facile. Voici les points qui cassent discrètement les modules de paiement en production, et chacun peut être vérifié depuis votre propre serveur ou votre back-office.

Les webhooks doivent réellement arriver

Toute passerelle moderne confirme le statut du paiement par un webhook serveur à serveur, et non par la redirection du navigateur du client. Ce qui signifie qu’une commande peut être payée côté passerelle alors que votre boutique l’affiche encore comme impayée si le webhook n’aboutit jamais. Avant le lancement, vérifiez trois choses : votre certificat SSL est valide (les passerelles refusent d’envoyer vers un mauvais certificat), votre serveur répond à l’URL de webhook dans le délai imposé par la passerelle (souvent ~30 secondes), et votre pare-feu ou CDN ne bloque pas les plages d’IP de la passerelle. Dans PrestaShop, le webhook atteint le front controller propre au module (le gestionnaire controllers/front/ du module, accessible via index.php?fc=module&module=...&controller=...) ; vérifiez qu’il se résout publiquement avant de lui faire confiance.

Un détail piège en particulier les intégrations Stripe : Stripe signe chaque webhook avec un secret, et votre module vérifie l’en-tête Stripe-Signature avec celui-ci. Si vous régénérez le secret de signature dans le tableau de bord Stripe sans coller la nouvelle valeur dans la configuration du module, chaque webhook arrive puis est rejeté comme non signé. La passerelle indique que le paiement est capturé tandis que PrestaShop ne bascule jamais la commande en payée. Lorsqu’une commande Stripe reste en « attente » alors que le tableau de bord la montre débitée, vérifiez la correspondance du secret de signature du webhook avant toute autre chose.

Ne laissez jamais un module manipuler les numéros de carte bruts

Si un module de paiement collecte les numéros de carte dans un formulaire servi depuis votre propre domaine, vous héritez du périmètre PCI DSS complet, un coût annuel de conformité qui se compte en milliers. Choisissez des modules qui utilisent les champs hébergés ou l’iframe de la passerelle (PayPal Checkout, Stripe Elements, Mollie Components) : les données de carte n’atteignent jamais votre serveur, vous restez donc dans la tranche PCI la plus légère (SAQ A) et le périmètre demeure chez le prestataire. Ce point n’est pas négociable, et c’est une raison parfaitement valable de rejeter un module moins cher par ailleurs.

Testez la surface de conflit en préproduction

Comme chaque module de paiement s’enregistre sur le même hook paymentOptions, deux modules peuvent se gêner dans le rendu, l’ordre d’affichage ou les ressources de l’étape de paiement. Installez et exercez d’abord tout nouveau module de paiement sur une copie de préproduction, passez une vraie commande de test avec chaque moyen de paiement, avant qu’il ne soit visible par un client réel. Un module de paiement qui déclenche une erreur 500 à l’étape de paiement ne fait pas perdre une vente ; il fait perdre toutes les ventes jusqu’à ce que vous vous en aperceviez.

Notre recommandation

Pour la plupart des boutiques PrestaShop européennes, le point de départ efficace est un agrégateur (Mollie si vos marchés s’appuient sur des moyens locaux européens, Stripe si vous êtes très orienté cartes ou avez besoin d’abonnements) plus PayPal comme solution de confiance de secours, deux modules, couvrant l’essentiel de la demande, avec un seul tableau de bord à rapprocher. Ajoutez Klarna uniquement lorsque votre panier moyen et votre catégorie justifient les frais du BNPL, et un module local dédié uniquement là où l’agrégateur ne couvre pas le moyen réellement utilisé par votre marché. Ensuite, n’y touchez plus : chaque module de paiement supplémentaire implique une maintenance continue, et une pile de paiement légère et bien maintenue convertit mieux qu’un empilement encombré.

Quels que soient les modules retenus, le principe reste valable pour la surface sur laquelle ils vivent : l’étape de paiement est l’écran le plus précieux de votre boutique, et le rôle de chaque module qui s’y trouve est d’encaisser correctement, rapidement et sans surprendre le client. Les modules ci-dessus s’enregistrent tous sur la même étape de paiement ; la façon dont cette étape est organisée compte donc autant que les modules qui y figurent, garder les moyens de paiement, le total de commande et le bouton de confirmation dans une seule vue, c’est précisément là que notre paiement en une page Checkout Revolution prend sa place, puisqu’il offre une étape de paiement propre où Stripe (cartes, Apple Pay, Google Pay, Link), PayPal et vos rails locaux peuvent s’afficher sans faire perdre son élan au client. Choisissez selon vos marchés, gardez une pile réduite, vérifiez les webhooks, et vous aurez pris une décision commerciale, pas seulement technique, c’est exactement ce qu’implique le choix de modules de paiement.

Questions fréquentes

Combien de modules de paiement une boutique PrestaShop doit-elle utiliser en même temps ?

Trois ou quatre constituent le plafond pratique pour la plupart des boutiques : un agrégateur (Mollie ou Stripe) pour l’essentiel de vos moyens de paiement, PayPal comme solution de confiance de secours, et au maximum un ou deux modules locaux dédiés lorsque l’agrégateur ne couvre pas un moyen dont votre marché a besoin. Chaque module supplémentaire ajoute un webhook à maintenir en bon état et un cycle de mise à jour, et comme ils partagent tous le même hook paymentOptions, c’est en les empilant que commencent les conflits de paiement et les étapes de paiement lentes.

Mollie ou Stripe : quel est le meilleur agrégateur pour une boutique PrestaShop ?

Cela dépend de l’emplacement de vos clients. Mollie réunit le plus large éventail de moyens locaux européens (iDEAL, Bancontact, BLIK, Przelewy24, Klarna et plus encore) dans un seul module avec une tarification par moyen de paiement, ce qui convient aux boutiques multi-marchés Benelux/DACH. Stripe propose des frais plus bas sur les cartes de l’UE, une facturation récurrente intégrée et une bonne prise en charge des portefeuilles (Apple Pay, Google Pay, Link), ce qui convient aux boutiques très axées cartes ou aux abonnements. Beaucoup de cartes et une portée mondiale → Stripe ; large couverture locale européenne → Mollie.

Ai-je besoin d’une certification PCI pour accepter les paiements par carte avec ces modules ?

Pas au sens lourd du terme, tant que le module utilise les champs hébergés ou l’iframe de la passerelle (Stripe Elements, Mollie Components, PayPal Checkout). Avec ces solutions, les données de carte brutes ne touchent jamais votre serveur, vous relevez donc du niveau d’auto-évaluation le plus léger, SAQ A. Le piège, c’est tout module qui affiche un formulaire de numéro de carte servi depuis votre propre domaine. Cela fait entrer votre boutique dans le périmètre PCI DSS complet, avec le coût d’audit que cela implique.

Une commande apparaît payée sur la passerelle mais impayée dans PrestaShop, que se passe-t-il ?

Presque toujours un webhook qui n’est pas arrivé ou n’a pas été accepté. Vérifiez que votre certificat SSL est valide, que le front controller du module se résout publiquement et qu’aucun CDN ni pare-feu ne bloque les plages d’IP de la passerelle. Pour Stripe en particulier, contrôlez que le secret de signature du webhook dans le module correspond à celui du tableau de bord Stripe, un secret différent pousse la boutique à rejeter silencieusement chaque webhook pourtant valide.

Les frais du tableau comparatif sont-ils fixes ?

Non. Il s’agit des niveaux européens publics au moment de la rédaction, et ils évoluent, les prestataires révisent leurs prix, et la plupart des tarifs se négocient une fois un certain volume mensuel dépassé. Considérez le tableau comme la forme de la comparaison, pas comme un devis, et confirmez les tarifs actuels sur la page de prix de chaque prestataire avant de vous engager.