Les structures de frais de Stripe et PayPal, les parcours de paiement (Payment Element / redirection PayPal ou champs de carte hébergés) et les réalités des modules PrestaShop décrites ici sont à jour. Vérifiez toujours les tarifs en vigueur dans le tableau de bord de votre propre processeur, car les deux publient des grilles par pays qui évoluent.
Presque tous les marchands PrestaShop arrivent au même carrefour : Stripe ou PayPal ? De l’extérieur, ils semblent interchangeables. Les deux acceptent les cartes, les deux sont stables, les deux ont un module PrestaShop. Mais ils reposent sur deux visions différentes de la personne à qui appartient le paiement. Stripe garde le paiement sur votre site et traite le formulaire de carte comme une partie de votre page. PayPal place sa propre marque entre vous et l’acheteur et, dans son parcours classique, envoie le client sur son site pour confirmer. Cette seule différence se répercute sur vos frais, votre conversion, la confiance dans la transaction et la manière dont un litige se déroule. Ce guide sert à prendre la bonne décision pour une boutique précise, la vôtre, plutôt qu’à désigner un vainqueur universel, car il n’y en a pas.
Si votre choix est déjà fait et que vous avez seulement besoin de la mise en place, clés API, webhooks, SCA, Apple Pay, c’est un autre sujet, traité de bout en bout dans le guide d’intégration de Stripe pour PrestaShop. Cet article concerne la décision qui vient avant.
La réponse courte, puis les nuances
Pour la plupart des boutiques PrestaShop, la réponse honnête est les deux, Stripe comme processeur principal pour les cartes, PayPal comme bouton supplémentaire pour les clients qui y tiennent. Proposer plusieurs moyens de paiement pertinents fait partie des rares leviers presque toujours positifs au moment de payer (le raisonnement est détaillé dans pourquoi proposer plus d’options génère plus de ventes). Mais « les deux » n’est pas gratuit, et beaucoup de boutiques ont raison de n’en utiliser qu’un seul. Le reste de ce guide vous donne le cadre pour savoir dans quel cas vous vous trouvez.
Frais : faites le calcul avec votre propre mix de cartes
C’est généralement là que Stripe l’emporte, mais l’écart dépend entièrement du pays d’émission des cartes de vos clients ; ne prenez donc pas un tarif affiché comme une vérité universelle. Les tarifs européens publiés placent Stripe autour de 1,5% + €0.25 pour les cartes de l’Espace économique européen et à un niveau plus élevé (environ 2,5% + €0.25) pour les cartes hors EEE, sans abonnement mensuel. Le tarif standard de PayPal pour les paiements par carte en ligne se situe autour de 2,49% + €0.35. Considérez ces chiffres comme indicatifs : les deux processeurs publient des tarifs propres à chaque pays et négocient des paliers de volume, donc vérifiez les montants de votre compte plutôt que de reprendre les nôtres.
Ce qui compte, c’est la forme de l’écart, avec deux composantes :
| Valeur de commande | Stripe (carte EEE, ~1,5% + €0.25) | PayPal (~2,49% + €0.35) | Différence |
|---|---|---|---|
| €20 | ~€0.55 | ~€0.85 | PayPal ~55% plus cher |
| €50 | ~€1.00 | ~€1.60 | PayPal ~60% plus cher |
| €150 | ~€2.50 | ~€4.09 | PayPal ~64% plus cher |
Les frais fixes (€0.25 contre €0.35) pèsent surtout sur les petits paniers : une boutique qui vend des accessoires à €15 ressent l’écart plus nettement qu’une autre qui vend des meubles à €300. Le pourcentage s’applique à chaque commande, donc la différence est récurrente, pas ponctuelle. Qu’est-ce que cela signifie pour vous ? Pour une boutique qui réalise un volume mensuel significatif avec surtout des cartes européennes, faire passer l’essentiel des paiements par Stripe plutôt que par PayPal représente de l’argent réellement conservé, mais une boutique dont les clients préfèrent vraiment payer depuis un solde PayPal peut convertir suffisamment de commandes supplémentaires pour compenser le surcoût par transaction. Modélisez-le avec votre mix de cartes et votre panier moyen avant de supposer que le « moins cher » gagne.
Expérience de paiement : sur votre page ou avec changement de contexte
C’est la différence que les clients ressentent vraiment, et dans PrestaShop elle dépend directement de la façon dont votre tunnel de commande est construit.
Stripe affiche ses champs de carte dans votre propre page de paiement (Payment Element / Stripe Elements). Le client ne quitte jamais votre domaine ; beaucoup ne remarquent même pas qu’un tiers intervient. Sur un tunnel PrestaShop en plusieurs étapes ou en une seule page, cela garde un parcours continu. Les informations de carte restent dans le même CheckoutPaymentStep que le reste, et Apple Pay / Google Pay peuvent apparaître sous forme de bouton express via l’Express Checkout Element de Stripe ou la prise en charge des portefeuilles dans le Payment Element, selon la version du module.
PayPal a deux visages. Son parcours classique redirige le client vers paypal.com pour se connecter et confirmer, puis le ramène vers votre contrôleur de confirmation de commande, un changement de contexte que certains acheteurs trouvent rassurant et que d’autres trouvent brusque. PayPal propose aussi le traitement des cartes sur site (ses champs hébergés Advanced Credit and Debit Card), qui se comporte davantage comme Stripe et garde l’acheteur sur votre page. Ce que votre module PrestaShop expose dépend du module et de sa configuration ; ne partez donc plus du principe que « PayPal = redirection ».
La redirection a deux effets possibles. Pour un acheteur sans compte PayPal, elle ajoute un obstacle qui peut faire perdre la commande ; pour un acheteur avec compte, elle peut améliorer la conversion, car il paie avec des identifiants qu’il possède déjà et auxquels il fait confiance. C’est pour cela qu’il faut raisonner par audience, et non appliquer une règle universelle.
Un détail de timing propre à PrestaShop mérite d’être compris, car il déroute les marchands qui consultent leur liste de commandes : avec le parcours classique de PayPal, la commande PrestaShop n’est pas créée à l’instant où le client clique sur « Payer avec PayPal ». Le module redirige, l’acheteur approuve sur PayPal, PayPal le renvoie vers le contrôleur du module, et seulement à ce moment-là, après la capture du paiement, le module appelle validateOrder() pour écrire la commande PrestaShop. Donc un client qui approuve sur PayPal mais ferme l’onglet avant d’être redirigé peut laisser un paiement capturé chez PayPal sans commande PrestaShop correspondante pour l’instant. C’est exactement pour combler cet écart que le callback webhook/IPN ci-dessous existe, et c’est pourquoi « payé sur PayPal, aucune commande dans PrestaShop » est un symptôme connu plutôt qu’un mystère.
[SCREENSHOT: Étape de paiement d’un tunnel PrestaShop en une page montrant un champ de carte Stripe intégré à la page et un bouton PayPal côte à côte comme deux options sélectionnables]
Confiance : qui le client paie-t-il vraiment ?
Pour une boutique toute récente ou de petite taille qui n’a pas encore de réputation, le plus grand atout de PayPal n’est pas sa technologie, c’est son nom. Un visiteur qui découvre votre boutique et n’en a jamais entendu parler peut quand même cliquer sur « Payer avec PayPal », parce qu’il fait confiance à PayPal pour faire écran entre lui et un vendeur inconnu. Cet effet d’intermédiaire de confiance est le plus fort précisément lorsque votre propre capital de marque est encore faible.
La confiance apportée par Stripe fonctionne autrement. Stripe n’a pas de marque grand public visible au paiement ; il rassure donc indirectement : un formulaire de carte propre, intégré à une page SSL qui inspire le sérieux. Pour une boutique établie avec une marque reconnaissable, cette finition convertit souvent aussi bien, voire mieux, qu’une redirection. Qu’est-ce que cela signifie pour vous ? Plus votre boutique est récente et peu connue, plus la confiance empruntée à PayPal mérite de rester dans l’offre ; plus votre marque est installée, plus vous pouvez mettre Stripe seul en avant avec sérénité.
Litiges et protection du vendeur : l’endroit où se trouve l’argent compte
Un chargeback ne se vit vraiment pas de la même manière avec les deux solutions, et mieux vaut le comprendre avant d’être en plein dedans.
| Stripe | PayPal | |
|---|---|---|
| Litige traité par | Réseaux de cartes ; vous soumettez les preuves via Stripe | Le Centre de résolution de PayPal d’abord, avant que cela ne devienne un chargeback carte |
| Frais de litige typiques | ~€15 par litige (souvent remboursés si vous gagnez) | Généralement pas de frais par litige sur les réclamations standard |
| Protection du vendeur | Score de fraude Stripe Radar ; contestation fondée sur les preuves | Protection des Marchands pour les biens physiques éligibles expédiés avec suivi |
| Réputation | Processeur neutre, tout dépend de la qualité de vos preuves | Souvent perçu comme favorable à l’acheteur dans les cas contestés |
L’implication pratique : PayPal peut résoudre certains problèmes par médiation avant que l’argent ne bouge, ce qui est pratique, mais s’il tranche en faveur de l’acheteur, les fonds peuvent simplement être prélevés sur votre solde PayPal. Stripe ne fait pas de médiation ; il vous donne un délai pour soumettre vos preuves à la banque. Quel que soit le processeur utilisé, votre défense repose sur les mêmes documents, confirmation de commande, suivi d’expédition, preuve de livraison, messages du client, et PrestaShop stocke déjà tout cela dans l’historique de commande. Le vrai enjeu est donc de pouvoir les rassembler rapidement avant que l’échéance de dépôt des preuves fixée par le processeur ne commence à courir.
Couverture internationale et moyens de paiement locaux
Si vous vendez à l’international, ne regardez pas seulement les cartes. Stripe prend en charge une longue liste de devises et, point essentiel pour les vendeurs européens, des moyens de paiement locaux comme iDEAL, Bancontact et le prélèvement SEPA via la même intégration, or l’impact sur la conversion d’un moyen de paiement attendu par le client dans son propre pays est important (nous l’expliquons dans les moyens de paiement locaux qui ouvrent des marchés locaux). La force de PayPal est inverse : moins de devises, mais une notoriété de marque quasi universelle, qui pèse dans des marchés comme les États-Unis, le Royaume-Uni et l’Australie, où les acheteurs utilisent volontiers PayPal pour les achats transfrontaliers.
Si votre vrai besoin est une large couverture des moyens de paiement locaux européens avec un seul contrat, il vaut aussi la peine de comparer un agrégateur multi-méthodes, voir Mollie pour PrestaShop, et pour une boutique ciblant spécifiquement le marché polonais, Przelewy24 compte souvent davantage que Stripe ou PayPal.
Le paiement fractionné fait désormais partie de la décision
Une chose a changé ces dernières années : les deux processeurs servent désormais d’intermédiaires pour le Buy Now, Pay Later. PayPal intègre Pay in 3 / Pay Later dans son bouton ; Stripe donne accès à Klarna, Afterpay/Clearpay et d’autres via le Payment Element. Pour les paniers moyens à élevés, proposer le paiement en plusieurs fois peut augmenter la finalisation, mais c’est un sujet avec ses propres compromis (frais, éligibilité, retours), traité dans Buy Now Pay Later : ce que cela signifie pour votre conversion. Le point à retenir ici : « Stripe vs PayPal » n’est plus seulement une question de carte. Les deux peuvent aussi être votre porte d’entrée vers le BNPL.
Intégrer l’un ou l’autre à PrestaShop
Les deux disposent de modules PrestaShop officiels, et les deux fonctionnent. La décision doit dépendre des frais, de votre audience et de la confiance, pas de l’idée qu’un module serait forcément plus robuste que l’autre. Quelques réalités propres à PrestaShop sont à connaître avant de brancher quoi que ce soit :
- Utilisez l’API moderne. Pour Stripe, cela signifie un module basé sur la Payment Intents API (et non sur l’ancienne Charges API). C’est ce qui permet à la SCA européenne / 3D Secure 2 de fonctionner correctement. L’équivalent côté PayPal est son SDK Orders/Checkout actuel plutôt que l’ancien parcours NVP/SOAP déprécié.
- Les webhooks décident si les commandes sont réelles. Les deux processeurs confirment les paiements hors bande. Si le point d’accès webhook est bloqué par un pare-feu, une règle Cloudflare ou
.htaccess, vous obtenez le symptôme PrestaShop classique : des commandes coincées dans un état intermédiaire sans débit correspondant. Le côté Stripe est détaillé dans le guide d’intégration Stripe. - La devise doit correspondre. Le paiement doit être créé dans la même devise que celle affichée au client par PrestaShop ; un décalage entre la devise active et le débit est une source fréquente de réclamations pour montant incorrect.
Pour le panorama plus large, Mollie, Adyen, passerelles locales et comparaison des modules officiels, partez plutôt de Meilleurs modules de paiement pour PrestaShop au lieu de tout redécider ici.
Utiliser les deux sans doubler votre administration
Si vous choisissez « les deux », et c’est le cas de la plupart des boutiques, le coût principal n’est pas les frais de transaction, mais la charge de back-office : deux tableaux de bord, deux comptes de règlement, deux rapprochements à faire en fin de mois. C’est gérable, mais c’est la partie que les marchands sous-estiment.
C’est là que le fait de garder les paiements dans un seul parcours de commande prend tout son sens. Notre module Checkout Revolution présente Stripe, PayPal, Apple Pay, Google Pay, Link et les cartes classiques comme des options au sein d’un paiement PrestaShop en une seule page (vérifiable dans les fonctionnalités propres au module), configurées depuis le back-office plutôt que par une facture de développement. Qu’est-ce que cela signifie pour vous ? Le client voit une étape de paiement claire et choisit son moyen de paiement ; vous n’avez pas à dupliquer votre thème ni à maintenir deux expériences de paiement séparées pour prendre en charge deux processeurs. Et comme les données de commande arrivent de manière cohérente dans PrestaShop, quel que soit le processeur qui a encaissé l’argent, regrouper les deux flux de revenus dans une seule vue, pour la comptabilité et le rapprochement, correspond exactement au type de tâche pour lequel notre reporting Financial Revolution est conçu. Ainsi, « deux comptes de règlement » ne signifie pas deux comptabilités à recoller à la main.
Quand n’en choisir qu’un seul
Les deux sont le choix par défaut, pas une loi. Choisissez un seul processeur lorsque le second n’apporte que de la charge :
- Stripe uniquement, une boutique B2B dont les acheteurs paient par carte ou virement bancaire et ne demandent jamais PayPal, ou toute boutique où la position de PayPal souvent favorable à l’acheteur dans les litiges représente un vrai risque pour votre type de produits (biens de forte valeur, personnalisés ou sujets aux contestations).
- PayPal uniquement, une toute nouvelle boutique qui veut le lancement le plus simple possible et un maximum de confiance empruntée dès le premier jour. Ajoutez Stripe plus tard, lorsque vous aurez du volume et une marque reconnaissable, et que les économies de frais commenceront à compter.
- Ni l’un ni l’autre en priorité, si votre marché a une préférence locale dominante (iDEAL aux Pays-Bas, BLIK/Przelewy24 en Pologne, Bancontact en Belgique), mettez-la en avant et traitez les cartes comme une option secondaire. Les attentes réelles des clients dans chaque marché européen sont cartographiées dans les moyens de paiement pour l’e-commerce européen.
Comment décider pour votre boutique
Ramenez la décision à quatre questions, et la réponse apparaît généralement :
- Quel est votre mix de cartes et votre panier moyen ? Une majorité de cartes EEE et des marges serrées poussent vers Stripe côté frais ; les petits paniers subissent le plus fortement les frais fixes de PayPal.
- Votre marque est-elle déjà établie ? Une marque nouvelle et inconnue s’appuie sur la confiance empruntée à PayPal ; une marque reconnue et soignée peut mettre Stripe seul en avant.
- Où vendez-vous ? En Europe, avec des moyens de paiement locaux, Stripe (ou un agrégateur comme Mollie) est favorisé ; un fort volume transfrontalier vers les États-Unis, le Royaume-Uni ou l’Australie garde PayPal très utile.
- Pouvez-vous absorber un peu d’administration ? Si oui, proposez les deux et laissez les clients choisir. Si vous gérez votre boutique seul et protégez votre temps, mieux vaut en exploiter un correctement que deux médiocrement.
Il n’existe pas de processeur simplement « meilleur ». Stripe est généralement le moteur carte le moins cher, intégré à la page et flexible sur les moyens locaux ; PayPal est le nom de confiance qui convertit les acheteurs prudents et les clients transfrontaliers. Les meilleures boutiques PrestaShop traitent cela comme un avantage, pas comme un dilemme : elles offrent le choix au client et gardent les deux dans un paiement propre, afin que la seule décision que l’acheteur ait à prendre soit de payer.
Questions fréquentes
Stripe est-il toujours moins cher que PayPal ?
Généralement, avec un mix de cartes européennes, mais pas automatiquement. Le tarif Stripe pour les cartes EEE (environ 1,5% + €0.25 dans les prix européens publiés) est habituellement inférieur au tarif standard de PayPal pour les cartes en ligne (environ 2,49% + €0.35), et l’écart augmente avec la valeur de commande. Mais l’économie n’existe que sur les cartes qui entrent dans le palier le plus bas, les cartes hors EEE coûtent plus cher avec Stripe, et PayPal peut quand même produire un meilleur résultat global si sa confiance empruntée convertit des commandes qu’un paiement par carte seul aurait perdues. Modélisez cela avec votre propre mix de cartes et votre panier moyen plutôt que de supposer que le tarif affiché tranche la question.
Puis-je utiliser Stripe et PayPal en même temps sur PrestaShop ?
Oui, et la plupart des boutiques devraient le faire. Ce sont des modules de paiement séparés et ils ne se gênent pas ; chacun enregistre sa propre option de paiement au moment de payer. Le vrai coût de leur utilisation conjointe n’est pas technique, mais administratif : deux tableaux de bord et deux comptes de règlement à rapprocher en fin de mois. Les présenter dans une seule étape de paiement (le type de fonctionnement que propose notre module Checkout Revolution) garde une interface propre côté client, même si les fonds arrivent ensuite sur deux comptes distincts.
Pourquoi PayPal a-t-il encaissé l’argent alors qu’aucune commande n’apparaît dans PrestaShop ?
C’est l’écart de timing propre aux commandes PayPal. Dans le parcours classique avec redirection, la commande PrestaShop n’est écrite que lorsque le client revient vers le contrôleur du module et que le module appelle validateOrder() après la capture, donc si l’acheteur approuve sur PayPal puis ferme l’onglet avant d’être redirigé, le paiement peut être capturé sans commande PrestaShop pour l’instant. Le callback serveur à serveur de PayPal (IPN/webhook) sert à combler cet écart, ce qui explique pourquoi une URL de callback bloquée est la cause habituelle. Vérifiez que le paiement existe dans votre tableau de bord PayPal, puis confirmez que l’URL de callback n’est pas bloquée par un pare-feu, un challenge Cloudflare ou une règle .htaccess.
Le choix entre Stripe et PayPal affecte-t-il la SCA / 3D Secure ?
Les deux gèrent l’authentification forte du client, mais seulement si le module est à jour. Pour Stripe, cela signifie un module basé sur la Payment Intents API, elle déclenche automatiquement 3D Secure 2 lorsque la carte et l’émetteur l’exigent. Pour PayPal, cela signifie le SDK Orders/Checkout actuel plutôt que l’intégration NVP/SOAP dépréciée. Un module encore basé sur l’ancienne Charges API de Stripe ou sur l’ancien parcours PayPal peut mal gérer la SCA européenne ; vérifiez donc la génération d’API avant l’installation.
Quelle solution convient le mieux à une toute nouvelle boutique sans réputation ?
PayPal, le premier jour, précisément pour la confiance empruntée. Un visiteur qui découvre votre boutique et n’en a jamais entendu parler peut quand même payer parce qu’il fait confiance à PayPal pour se placer entre lui et un vendeur inconnu, et cet effet est le plus fort exactement lorsque vous n’avez pas encore de capital de marque. Le parcours courant consiste à lancer avec PayPal pour cette réassurance, à ajouter Stripe une fois que vous avez du volume et une marque reconnaissable, puis à laisser les économies de frais de Stripe compter davantage à mesure que vous grandissez.
