Tunnel de commande PrestaShop : processus, module et meilleures options

Dernière mise à jour : juin 2026.

Le tunnel de commande PrestaShop désigne deux choses différentes, remettons les choses au clair

La moitié des tickets de support que nous recevons à propos du tunnel de commande portent en réalité sur tout autre chose. Il y a le tunnel de commande (le parcours en plusieurs étapes intégré à chaque boutique PrestaShop) et il y a ps_checkout, un module de paiement spécifique développé par PrestaShop SA en partenariat avec PayPal. Les deux noms se ressemblent. Ce ne sont pas les mêmes choses. Remplacer l'un ne remplace pas l'autre.

Nous proposons Checkout Revolution depuis 2018 parce que nous n'arrivions pas à faire fonctionner correctement le tunnel natif pour nos clients, et nous avons vu toutes les variantes possibles du tunnel de commande PrestaShop casser en production : panier vidé à l'étape de paiement, "aucun moyen de paiement disponible" avec cinq modules actifs, redirections 3DS qui atterrissent sur des 404. Cet article est la version de la documentation que nous aurions aimé trouver quand nous avons commencé à développer des modules dédiés au parcours de commande.

Comment fonctionne le tunnel de commande PrestaShop

Le parcours multi-étapes par défaut

Chaque boutique PrestaShop est livrée avec le même parcours en cinq étapes, réparti sur plusieurs chargements de page :

1. Vérification du panier, produits, quantités, totaux
2. Informations personnelles, connexion, inscription ou invité
3. Adresse, livraison et facturation
4. Livraison, sélection du transporteur selon l'adresse, le poids et les dimensions
5. Paiement, moyen de paiement et confirmation de commande

Après le paiement, le client arrive sur la page de confirmation. C'est la base dont hérite chaque thème et dans laquelle vient se brancher chaque module de paiement. C'est aussi la friction que l'on nous demande de supprimer : cinq chargements de page pour un seul achat, c'est beaucoup.

Le tunnel par défaut est une séquence, pas un module de paiement.

Cette planche contact provient d'un parcours de commande ps9-dev fraîchement exécuté : produit ajouté au panier, informations invité saisies, adresse enregistrée, transporteur sélectionné, étape de paiement atteinte. Quand un prestataire de paiement échoue à la dernière étape, les étapes précédentes peuvent encore sembler saines, c'est pourquoi nous déboguons étape par étape, sans jamais présumer.

Ce qui a changé entre 1.7 et 8/9

Le parcours lui-même n'a pas bougé. La plomberie en dessous, elle, a beaucoup évolué :

• Architecture des thèmes. Classic utilise encore une validation AJAX très dépendante de jQuery à chaque étape. Hummingbird (l'alternative 8/9) l'a réécrite sur un socle technique moderne, si vous êtes encore sur Classic, vous maintenez du code front-end dont la majeure partie de l'écosystème s'est éloignée.
• Hooks de paiement. paymentOptions a remplacé les anciens displayPayment/displayPaymentEU en 1.7. Sur 8 et 9, les anciens hooks de paiement ne sont plus déclenchés du tout. Tout module qui utilise encore displayPayment devient invisible sans bruit. Nous l'avons constaté plus d'une fois dans des boutiques clientes.
• Migration Symfony. La gestion des commandes en back-office est désormais sous Symfony. Le OrderController du front-office tourne toujours sur l'ancien socle. Les auteurs de modules qui ciblent les deux mondes doivent savoir de quel côté de la frontière ils travaillent.
• Valeurs CSP plus strictes sur 8+. Les en-têtes Content Security Policy par défaut peuvent bloquer purement et simplement le JavaScript des prestataires de paiement. "Mon tunnel de commande est devenu blanc après la mise à niveau" vient presque toujours de là.
• PHP 8.1+ sur PS 9. Tout module de paiement écrit pour les fonctionnalités de PHP 7 verra ses défauts remonter à la mise à niveau.

Si un module de paiement est devenu invisible après une mise à niveau vers 8 ou 9, le moyen le plus rapide de confirmer que le hook mort est en cause consiste à chercher l'ancien hook dans votre dossier modules. Tout module qui enregistre encore displayPayment ou displayPaymentEU mais jamais paymentOptions ne s'affichera pas à l'étape de paiement :

# modules that still register a legacy payment hook
grep -rln "displayPayment\b\|displayPaymentEU" modules/*/

# of those, which never register the modern hook?
for d in $(grep -rln "displayPayment" modules/*/); do
  grep -q "paymentOptions" "$d" || echo "NO paymentOptions: $d"
done

Chaque ligne NO paymentOptions correspond à un module qui doit être mis à jour avant de pouvoir encaisser des paiements sur 8/9. La correction revient à l'auteur du module. Un hook de paiement supprimé du cœur ne peut pas être réintroduit par un bricolage pour se déclencher à nouveau, mais identifier le module responsable transforme "le tunnel de commande est cassé" en problème précis et traitable.

Le OrderController et son déclenchement

Le tunnel de commande est piloté par controllers/front/OrderController.php. Il charge le panier, déclenche les hooks, parcourt un objet CheckoutProcess qui contient chaque étape sous forme de classe distincte (CheckoutAddressesStep, CheckoutDeliveryStep, CheckoutPaymentStep, toutes héritant de AbstractCheckoutStep).

Cette structure modulaire est réellement bien conçue : les modules peuvent remplacer une étape sans remplacer tout le parcours. Le piège, c'est que "bien conçue" ne veut pas dire "facile à comprendre". Quand cinq modules modifient chacun une étape différente, le débogage prend du temps. Chaque problème de tunnel de commande que nous avons corrigé a commencé par une lecture complète de OrderController.

Ce qui se passe à chaque étape

Derrière chaque étape, des validations s'exécutent et des hooks se déclenchent pour permettre aux modules d'étendre le processus :

• Validation d'adresse. Champs obligatoires, combinaisons pays/région, recalcul des règles fiscales selon le pays de livraison.
• Sélection du transporteur. Transporteurs disponibles filtrés par zone, poids, dimensions et restrictions. actionCarrierProcess est le hook sur lequel intervenir.
• Rendu du paiement. Chaque module de paiement actif s'enregistre via paymentOptions et l'ordre d'affichage correspond à ce que vous définissez dans Paiement > Préférences.
• Validation de commande. actionValidateOrder se déclenche à la confirmation, paiement, décrémentation du stock, emails, création de la ligne de commande, tout le reste.

C'est ce qui rend le tunnel de commande extensible. C'est aussi pour cela que deux modules mal écrits peuvent se gêner mutuellement et produire des erreurs impossibles à diagnostiquer sans `var/logs/` dans une main et la base de données dans l'autre.

Pourquoi votre tunnel de commande est lent

Un tunnel de commande lent coûte de l'argent. Chaque seconde de chargement fait perdre des conversions. Quand nous auditons les performances d'un tunnel de commande, les goulots d'étranglement sont presque toujours l'un de ceux-ci :

• Trop de modules sur les hooks du tunnel de commande. Nous avons vu des boutiques avec plus de 15 modules déclenchés sur displayPayment, displayBeforeCarrier, actionCarrierProcess. Chacun ajoute des millisecondes. Ensemble, ils ajoutent des secondes.
• Appels à des API externes. Tarifs UPS/FedEx en direct, calcul de taxe TaxJar, vérification d'adresse. N'importe lequel peut bloquer tout le tunnel de commande quand le service amont a un soubresaut.
• Configurations de transporteurs incontrôlables. Des dizaines de transporteurs avec des règles zone/poids qui se chevauchent forcent PrestaShop à lancer de longues requêtes à chaque rendu de l'étape de livraison.
• Accumulation de règles panier. Des centaines de règles panier actives signifient des centaines d'évaluations par panier. Les règles expirées doivent être supprimées, pas désactivées.
• Index manquants sur les tables de règles panier et de prix spécifiques. Sur les boutiques qui tournent depuis des années, ces tables sont énormes et souvent mal indexées.
• Pas d'OPcache, pas de Redis. Inutile de développer. Si vous êtes encore sur des sessions fichier et un OPcache désactivé en 2026, le reste de cet article ne vous sauvera pas.

Pour trouver le responsable sur une copie de préproduction, activez le profiler :

// staging only
define('_PS_DEBUG_PROFILING_', true);

Ne laissez jamais cela activé en production. Lancez une commande de test, lisez le tableau du profiler : le module le plus lent est généralement visible avant même d'avoir besoin de logs plus profonds. Nous l'avons appris à nos dépens dans une boutique cliente où un module de conversion de devise consommait 1,8 seconde à chaque rendu du tunnel de commande.

Les erreurs de tunnel de commande que nous voyons le plus souvent

"Aucun moyen de paiement disponible." L'erreur la plus recherchée sur Google. Elle signifie qu'aucun module de paiement n'a renvoyé quoi que ce soit depuis paymentOptions. Les suspects habituels :

• Une restriction de devise ou de pays exclut le panier du client
• Paiement > Préférences exclut le transporteur, le pays ou le groupe client actuel
• Le module de paiement rencontre une erreur PHP et échoue silencieusement, vérifiez var/logs/
• Sur PS 8+, les en-têtes CSP bloquent le JavaScript du module

Le plus souvent, c'est une incohérence de configuration, pas un problème de thème.

Dans le tunnel PS9 capturé, le panier, l'adresse et le transporteur fonctionnaient, mais l'étape de paiement revenait vide. La matrice du back-office a vendu la mèche : les modules de paiement natifs étaient limités à un pays différent de la France du panier de test.

Paiement > Préférences est le premier endroit à vérifier.

Les restrictions de devise, de groupe client, de pays et de transporteur déterminent si un module apparaît ou non dans le tunnel de commande. Un module de paiement installé et actif peut malgré tout rester invisible pour le client si une restriction exclut le contexte du panier courant.

"Une erreur est survenue pendant le traitement de votre commande." Le message le plus générique livré par PrestaShop. Commencez par l'exception réelle dans le journal d'erreurs PHP et les logs PrestaShop. Vérifiez ensuite la disponibilité du stock (un produit passé en rupture entre le panier et le paiement fait échouer la commande), puis les conflits de règles panier (un bon de réduction invalide qui empoisonne discrètement la validation finale).

Panier vidé pendant le tunnel de commande. C'est toujours un problème de cookie ou de session. Mauvaise configuration SSL, domaines boutique/SSL différents, partition de sessions pleine, ou (nous avons vu celui-ci partir en production) un module qui appelle Context::getContext()->cart = new Cart() dans un hook de tunnel de commande et réinitialise accidentellement le panier. Si vous suspectez un module, désactivez-les un par un jusqu'à ce que le tunnel se comporte normalement.

Échecs de validation d'adresse. Région/État obligatoire sur un pays que le client n'a pas vu, chaîne de format d'adresse malformée ou regex de code postal trop stricte. International > Zones géographiques > Pays est l'endroit à vérifier.

Échecs de redirection 3DS. Le client s'authentifie mais arrive sur une page d'erreur ou ne revient jamais. Causes possibles : l'URL de retour est en HTTP et non en HTTPS, la session a expiré pendant le 3DS, l'URL de rappel est inaccessible depuis la banque, ou une configuration multi-domaines fait pointer l'URL de retour 3DS vers un domaine différent de celui sur lequel le client achetait.

Règles panier et remises : la couche qui casse en dernier

La logique de remise est la partie du tunnel de commande qui déroute autant les marchands que les développeurs. Les règles panier (bons de réduction, promotions, remises automatiques) et les prix spécifiques au produit interagissent d'une manière qui n'est pas toujours intuitive.

• Les règles panier sont évaluées par ordre de priorité, certaines s'appliquent à tout le panier, d'autres à des produits ou catégories spécifiques.
• Les prix spécifiques s'appliquent avant les règles panier. Un produit déjà en promotion peut ne pas être éligible à une remise supplémentaire.
• Les restrictions de cumul permettent de marquer des règles comme non cumulables, mais la logique qui décide "laquelle gagne" n'est pas évidente dans les boutiques multi-devises.

Les règles panier ne sont pas seulement des codes promo.

La vraie liste du back-office ps8-dev affiche la priorité, le code, la limite de quantité, l'expiration et l'état actif de chaque règle panier. Quand les remises se comportent bizarrement dans le tunnel de commande, c'est par cette liste que nous commençons, avant d'accuser le module de paiement.

Règles panier avec livraison gratuite et interaction avec les transporteurs

Une règle panier "livraison gratuite" ne rend pas tous les transporteurs gratuits. Si la règle n'est pas limitée à des transporteurs précis, elle s'applique à celui que choisit le client. Si elle est restreinte à certains transporteurs, seuls ceux-là passent à zéro, les autres affichent toujours leur prix normal. Les restrictions de pays et de zone sur la règle panier la resserrent encore. Si plusieurs règles de livraison gratuite s'appliquent, la règle valide avec la priorité la plus élevée est utilisée et les autres sont ignorées silencieusement.

Le piège de la priorité et du cumul

La priorité compte plus que la plupart des marchands ne l'imaginent. Prenons un cas courant :

• Règle A (priorité 1) : 20 % de remise sur tout le panier, non cumulable
• Règle B (priorité 2) : livraison gratuite dès 50 EUR

Comme la règle A est non cumulable et passe en premier, la règle B ne s'applique jamais. Le client obtient 20 % de remise et paie quand même la livraison. Rendez la règle A cumulable, ou intégrez directement la livraison gratuite dans la règle A.

L'autre classique : un client saisit un bon de 10 EUR, mais le panier bénéficie déjà d'une remise automatique de 15 % non cumulable. PrestaShop rejette le bon avec un message "non valide" inutile. Nous avons reconstruit plus d'une fois la logique des règles panier pour des clients parce que c'était plus simple que d'expliquer cela aux équipes support.

Montant minimum des règles panier

Le contrôle du montant minimum s'exécute avant ou après les autres remises selon la configuration, et il peut inclure ou exclure les taxes et la livraison. Résultat : un panier de 110 EUR avant remise mais 95 EUR après remise peut ou non passer une règle "minimum 100 EUR". Testez toujours les règles de montant minimum avec de vrais scénarios de panier dans plusieurs pays avant la mise en ligne.

Commande invitée vs création de compte

La commande invitée est un réglage de commande, pas un réglage de paiement, Paramètres de la boutique > Paramètres des commandes dans PS 8. Nous l'activons sur presque tous les projets B2C, car forcer la création de compte tue la conversion mobile. Le B2B fait exception : achats liés à un compte, historique de commandes récurrentes et facturation correcte pèsent généralement plus lourd que la friction d'un formulaire supplémentaire.

La commande invitée se trouve dans les paramètres des commandes.

Cette capture ps8-dev montre le vrai bouton Activer la commande invitée. Le désactiver modifie la toute première étape du tunnel de commande, avant même qu'un transporteur ou un module de paiement n'intervienne.

Le module ps_checkout. Ce qu'il est vraiment

Ce que fait ps_checkout (et ce qu'il ne fait pas)

Le module PrestaShop Checkout (nom technique ps_checkout) est un module de paiement gratuit développé conjointement par PrestaShop SA et PayPal. Il est préinstallé sur chaque PrestaShop depuis la version 1.7.5.

Voici la distinction qui piège les marchands tous les jours : ps_checkout est un module de paiement, pas le tunnel de commande. Il ne change ni les étapes, ni la mise en page, ni l'ordre des champs, ni quoi que ce soit dans la façon dont PrestaShop guide le client jusqu'à l'achat. Il affiche seulement des options de paiement à l'étape de paiement. Quelqu'un qui vous vend un "tunnel en une page via ps_checkout" n'a pas lu le README du module.

Ce qu'il propose

Pour un module gratuit, la liste des fonctionnalités est correcte :

• Paiements par carte (Visa, Mastercard, AmEx) via les champs hébergés par PayPal
• Portefeuille PayPal
• Apple Pay et Google Pay lorsque disponibles
• Moyens locaux, iDEAL, Bancontact, BLIK, et d'autres selon le marché
• Paiement différé / paiement en 3-4 fois (PayPal BNPL)
• 3DS2
• Plus de 20 devises via le réseau PayPal

Code source complet sur le dépôt GitHub ps_checkout.

Frais de transaction

Le module est gratuit. Le traitement des paiements ne l'est pas. Considérez tout tarif cité comme un exemple propre à un marché : PayPal, Stripe, Mollie et Adyen varient tous selon le pays du marchand, l'origine de la carte, le moyen de paiement, la devise, le volume et le profil de risque. Demandez un devis écrit pour votre propre pays marchand avant de vous engager.

Références tarifaires, dernière vérification en mai 2026 : Stripe France, Mollie, Adyen, PayPal UK. Utilisez la page équivalente pour votre pays marchand.

Comparer les prestataires de paiement. Les frais ne font pas tout

Nous avons vu des marchands choisir un prestataire pour 0,3 EUR d'écart par commande, puis perdre des clients à l'étape de paiement parce que le moyen local auquel ils font confiance n'était pas proposé. Le taux d'autorisation, la couverture des moyens locaux, le parcours de remboursement, la qualité du support et la facilité de débogage dans le back-office comptent au moins autant que le pourcentage affiché.

ps_checkout vs Stripe vs Mollie en un coup d'œil

Installer et configurer ps_checkout

Installez le module (préinstallé sur les nouvelles boutiques, sinon disponible depuis Addons), liez un compte PrestaShop Addons, connectez votre compte PayPal Business via l'assistant d'activation (les comptes PayPal personnels ne sont pas pris en charge, et cela piège beaucoup de monde), choisissez les moyens de paiement à proposer, vérifiez les paramètres d'arrondi et de devise par rapport aux attentes de PayPal, puis testez en sandbox avant la mise en production. Nous passons toujours au moins une commande sandbox par devise vendue par la boutique.

La mise en place combine activation du compte et configuration du paiement.

Le module peut être installé sans que l'expérience de paiement soit complète. Compte PrestaShop lié, compte PayPal Business associé, arrondi compatible, et au moins un paiement sandbox ou réel confirmé depuis le tunnel de commande : seulement là, c'est terminé.

Désinstaller ps_checkout

Modules > Gestionnaire de modules, trouvez ps_checkout, commencez par Désactiver (sans risque, cela l'arrête sans perdre les données). Pour le supprimer complètement, utilisez Désinstaller, puis supprimez éventuellement modules/ps_checkout/. Assurez-vous qu'un autre module de paiement est configuré avant cela, sinon votre boutique affichera "Aucun moyen de paiement disponible" au prochain passage dans le tunnel de commande.

L'architecture intermédiaire (et pourquoi elle compte)

C'est ici que ps_checkout diffère d'une intégration directe. Stripe, Mollie et Adyen versent les paiements directement sur votre compte marchand. ps_checkout les fait transiter par le compte de plateforme PayPal commerce de PrestaShop SA, PrestaShop SA agit comme facilitateur de paiement.

Ce que cela change en pratique :

• Vous liez votre compte PayPal Business via le parcours PrestaShop, pas directement avec PayPal
• Le délai de règlement dépend à la fois des règles de PayPal et de la configuration de plateforme de PrestaShop SA
• Les chargebacks passent par une couche supplémentaire, les litiges prennent plus de temps à résoudre
• Les données de transaction brutes sont moins visibles que sur une passerelle directe

Ce n'est pas mauvais en soi, Shopify Payments fonctionne de la même manière. Mais pour les marchands à fort volume ou réglementés, cela ajoute une complexité opérationnelle qu'il vaut mieux connaître avant de s'engager.

Les limites que nous voyons revenir

D'après les issues GitHub, les forums communautaires et les tickets de support que nos clients nous ont apportés :

• Compatibilité thème. ps_checkout fonctionne au mieux sur Classic. Les thèmes fortement personnalisés cassent régulièrement le rendu des champs de paiement hébergés.
• Le spinner infini. Le formulaire de paiement ne finit jamais de charger. Il s'agit généralement d'un conflit JavaScript avec un autre module ou d'un en-tête CSP qui bloque les scripts PayPal.
• Erreurs 3DS peu utiles. Quand le 3DS échoue, le client voit un message générique qui ne l'aide pas à réessayer, de l'abandon qui aurait pu être récupéré avec un libellé plus clair.
• Pas de support direct. L'aide passe par les canaux communautaires. Pour les boutiques qui perdent activement de l'argent pendant une panne de paiement, c'est la partie la plus douloureuse.
• Risque de mise à niveau. Certaines versions majeures ont introduit des changements cassants. Rythme fonctionnel rapide, mises à niveau fragiles. Testez à chaque fois en préproduction.

Aucun de ces points n'est rédhibitoire isolément. Ensemble, ils expliquent pourquoi nous testons toujours les mises à jour de ps_checkout sur une copie de préproduction d'abord.

Quand ps_checkout a du sens

Malgré tout ce qui précède, c'est un choix de départ raisonnable pour :

• Les nouvelles boutiques qui doivent accepter des paiements dès demain sans coût initial
• Les boutiques sur un seul marché, sans besoins complexes de règlement multi-devises
• Les marchands soucieux du budget qui préfèrent payer à la transaction plutôt qu'acheter des modules
• Les catalogues simples, pas d'abonnements, pas de précommandes, pas de parcours de paiement atypiques

Personnaliser le tunnel de commande PrestaShop

Ce que vous pouvez changer sans module

Avant d'ajouter du code tiers, plusieurs éléments peuvent être modifiés avec les outils intégrés :

• Templates du thème. Modifier les templates Smarty du tunnel de commande dans votre thème enfant, mise en page, ordre des champs, contenu personnalisé entre les étapes.
• CSS. Couleurs, espacements, boutons, typographie. Alignement de marque sans toucher à la logique.
• Configuration des transporteurs. Noms des transporteurs, descriptions, estimations de livraison, ordre d'affichage.
• Ordre des modules de paiement. Paiement > Préférences contrôle le moyen qui apparaît en premier.
• Champs obligatoires. Clients > Adresses contrôle les champs obligatoires.

Ce sont des personnalisations sûres qui survivent aux mises à jour PrestaShop si vous utilisez un thème enfant, ce que vous devriez faire. Pour aller plus loin, notre guide d'optimisation du tunnel de commande détaille le sujet.

Le formatage des adresses est intégré à PrestaShop.

L'éditeur de pays contrôle les champs qui apparaissent et leur ordre. C'est important dans le tunnel de commande, car le pays de livraison pilote la validation, les règles de code postal, la zone fiscale et la disponibilité des transporteurs.

Champs personnalisés dans le tunnel de commande

La plupart des marchands avec lesquels nous travaillons finissent par avoir besoin de champs que PrestaShop ne collecte pas par défaut. Téléphone mobile pour les notifications SMS, raison sociale et numéro de TVA pour le B2B, codes de portail et instructions de livraison du type "laisser chez le voisin", références de commande personnalisées pour les achats B2B.

Le formulaire d'adresse du back-office (Clients > Adresses) couvre les bases. Pour tout ce qui va plus loin, il faut soit un module personnalisé branché sur actionValidateOrder, soit un module de champs de tunnel de commande depuis Addons. Les deux fonctionnent, choisissez celui qui correspond au niveau de confort PHP de votre équipe.

Traduire le tunnel de commande

Si vous vendez à l'international et que votre tunnel de commande affiche des messages d'erreur en anglais sur une boutique française, vous perdez des commandes. Les clients ne paient pas pour quelque chose qu'ils ne comprennent pas.

Les éléments à traduire :

• Libellés d'étapes. International > Traductions > Traductions du front-office, votre thème.
• Chaînes des modules de paiement. Chaque module de paiement a ses propres fichiers de traduction, séparés du coeur.
• Messages d'erreur. "Please enter a valid address" et les autres, les chaînes qui apparaissent au pire moment.
• Conditions générales. La case "J'accepte" pointe vers une page CMS qui doit exister dans chaque langue.
• Libellés du formulaire d'adresse. Les formats propres au pays doivent correspondre à la locale du client.

Le piège classique : installer un pack de langue ne traduit pas les chaînes des modules. Nous avons livré sept traductions multi-boutiques chez nos clients, et ce piège attrape tout le monde la première fois.

Cherchez la chaîne du tunnel de commande, puis modifiez le domaine du thème.

Cette page de traduction ps8-dev filtrée sur checkout affiche des chaînes de Shop > Theme > Actions. Le même flux s'applique à chaque libellé, bouton et message du front-office qui apparaît pendant le tunnel de commande.

Tunnel de commande en une page

La personnalisation du tunnel de commande la plus demandée. Cinq chargements de page distincts sont regroupés sur une seule page où l'adresse, la livraison et les champs de paiement sont visibles en même temps.

La raison pour laquelle cela fonctionne n'a rien de magique : cela supprime la friction de navigation et garde tout le contexte de commande visible. Le gain de conversion varie, source de trafic, répartition des appareils, complexité de la livraison, moyens de paiement et nombre de champs obligatoires comptent tous. Nous ne prétendons pas à un pourcentage fixe. En revanche, nous constatons régulièrement moins d'abandons dans les données d'analyse après la mise en production d'un tunnel en une page chez un client. Traitez-le comme une expérimentation, pas comme une promesse universelle du type "X % de mieux".

Du point de vue UX : tous les champs visibles d'un coup, mises à jour AJAX des frais de livraison, validation en ligne pendant la saisie, aucun indicateur de progression nécessaire, récapitulatif de commande persistant. Bien réalisé, c'est nettement plus calme qu'un parcours multi-étapes.

PrestaShop n'a aujourd'hui aucun tunnel de commande natif en une page. La feuille de route le mentionne pour PrestaShop 9.2 avec Hummingbird v2, mais il sera optionnel et le parcours multi-étapes ne disparaîtra pas. En attendant, la réponse est un module.

C'est le territoire de Checkout Revolution : nous l'avons construit parce que toutes les alternatives avaient l'air datées, cassaient sur Hummingbird ou empilaient quatre autres modules pour fonctionner. C'est notre produit phare, et nous pensons sincèrement que c'est le meilleur tunnel de commande en une page du marché pour PrestaShop. Nous le dirions même si nous ne l'avions pas construit.

La différence structurelle, côte à côte.

À gauche : le parcours multi-étapes PrestaShop 9 par défaut sur ps9-dev. À droite : Checkout Revolution sur ps178-dev, contact, livraison, paiement et récapitulatif de commande visibles sur une seule page.

Commande express, tout autre chose

La commande express est souvent confondue avec le tunnel en une page. Ce n'est pas la même chose.

Tunnel en une page = remplacement complet du parcours multi-étapes. Commande express = boutons de portefeuille (Apple Pay, Google Pay, PayPal Express, Link) sur la page produit et le panier, qui contournent tout le tunnel de commande. Le client touche Apple Pay sur la page produit, s'authentifie avec Face ID, et la commande est passée. Pas de formulaire d'adresse, pas de sélecteur de transporteur, pas d'étape de paiement, le portefeuille fournit tout.

Ce n'est pas un remplacement du tunnel de commande. C'est un point d'entrée alternatif. Sur mobile, où chaque champ d'adresse tue un peu plus la conversion, c'est l'ajout le plus impactant que nous puissions faire dans une boutique cliente. Nous le vendons comme produit à part entière : Express Checkout. Pour les boutiques qui veulent les deux (boutons portefeuille et tunnel en une page), Checkout Revolution les regroupe.

La commande express commence avant la page panier.

Cette page produit ps178-dev montre un vrai bouton Express Checkout juste à côté des contrôles d'achat du produit. Selon le prestataire, le navigateur, le pays et l'éligibilité du portefeuille, le bouton visible peut être un bouton express générique ou un bouton propre à Apple Pay, Google Pay, PayPal ou BNPL.

Tunnel intégré et modal

Un modèle moins courant : le formulaire de paiement apparaît dans une modale ou directement dans la page actuelle, sans navigation vers une URL de tunnel séparée. Le Payment Element de Stripe et le parcours dans le contexte de PayPal le prennent tous deux en charge. La distance psychologique entre "je veux ça" et "je l'ai acheté" se raccourcit. Nous utilisons cette approche dans Checkout Revolution quand le marchand veut réduire la friction de la manière la plus agressive possible.

Alternatives à ps_checkout

Si ps_checkout ne convient pas, voici les options matures pour le traitement des paiements PrestaShop :

Stripe

Le Payment Element de Stripe est l'intégration de paiement la plus agréable pour les développeurs sur le marché. Nous l'utilisons sous le capot dans Checkout Revolution parce qu'il offre la couverture de moyens la plus large avec l'API la plus propre.

• Compte marchand direct, aucun intermédiaire sur le règlement
• Plus de 135 devises, change automatique
• Apple Pay, Google Pay, Link, plus de 40 moyens locaux
• La meilleure documentation API du paiement
• Stripe Radar pour la protection antifraude

Idéal pour : boutiques internationales, équipes techniques, toute personne qui veut un contrôle complet sur ses données de paiement.

Mollie

Un prestataire de paiement européen avec une forte couverture aux Pays-Bas, en Belgique, en Allemagne et en France.

• Tarification par transaction, aucun frais mensuel
• iDEAL, Bancontact, SOFORT, EPS, Giropay, KBC/CBC natifs
• Module PrestaShop solide maintenu par Mollie elle-même
• Onboarding rapide

Idéal pour : boutiques de l'UE, surtout Benelux ou DACH où les moyens locaux dominent.

Acheter maintenant, payer plus tard : Klarna, Alma, Clearpay/Afterpay

Le BNPL mérite d'être ajouté lorsque les paniers sont assez élevés pour qu'un paiement fractionné change la décision d'achat. Dans PrestaShop, il est presque toujours ajouté via un prestataire de paiement ou un module dédié, pas via les paramètres natifs du tunnel de commande.

• Klarna, DACH, pays nordiques, Royaume-Uni, stacks européennes plus larges. Paiement différé, paiement en 3/4, financement ou express selon l'intégration.
• Alma, très présent en France et dans le sud de l'Europe pour les paiements en plusieurs fois sur des paniers élevés.
• Clearpay/Afterpay, marchés où Afterpay opère, y compris le Royaume-Uni sous le nom Clearpay.

Le piège : les frais BNPL sont plus élevés que le traitement carte, et le marchand porte une charge opérationnelle supplémentaire sur les litiges et remboursements. Vérifiez l'éligibilité par pays et le calendrier de règlement (immédiat ou différé) avant de l'activer.

Moyens de paiement locaux par marché

Si vous vendez dans toute l'Europe, la couverture des moyens locaux peut compter autant que le tarif carte. Les clients font confiance au moyen qu'ils utilisent déjà avec leur banque ou leur portefeuille mobile. Des prestataires comme Stripe et Mollie peuvent les afficher dynamiquement, mais seulement si votre module PrestaShop, votre devise, vos restrictions de pays et votre compte prestataire sont configurés pour cela.

Pour la prise en charge actuelle des moyens, consultez les moyens de paiement Stripe, les moyens de paiement Mollie et l'avis de dépréciation de Giropay par Stripe.

Adyen

L'option entreprise. Utilisé par Booking.com et eBay, plus de 250 moyens de paiement, routage intelligent, détection de fraude RevenueProtect et acquisition directe. Adyen est à la fois processeur et acquéreur, ce qui supprime les intermédiaires.

Le compromis, c'est la complexité et le coût. Pour les marchands à fort volume, Adyen est souvent gagnant. Pour les autres, Stripe, Mollie ou ps_checkout vous mettront en ligne plus vite, avec moins d'échanges commerciaux et techniques.

Amazon Pay

Les clients commandent avec leur compte Amazon existant, adresse, paiement, tout. Commande en un geste avec les informations enregistrées chez Amazon et protection acheteur de A à Z. Un module PrestaShop est disponible sur Addons. Fonctionne bien en option secondaire à côté des cartes et de PayPal, moins bien comme option principale.

Module PayPal autonome

Si vous voulez PayPal sans la couche intermédiaire de PrestaShop SA, un module autonome se connecte directement à votre compte PayPal Business. Vous gardez le contrôle direct des règlements et du traitement des litiges, la même expérience portefeuille PayPal que les clients connaissent, et le paiement différé configuré depuis votre propre tableau de bord PayPal.

Idéal pour : les marchands qui veulent PayPal mais préfèrent une relation directe avec PayPal plutôt qu'une relation facilitée.

Virement bancaire, l'option sans frais que l'on oublie

Facile à écarter parce que ce n'est ni un portefeuille ni un formulaire carte. Pourtant utile dans la bonne boutique. Le module natif ps_wirepayment affiche vos coordonnées bancaires pendant le tunnel de commande et permet au client de passer commande sans aucune passerelle carte.

L'argument commercial est simple : pas de frais de passerelle, pas de frais de réseau carte, pas de calendrier de versement intermédiaire. Pour le B2B, les produits fabriqués à la demande, les comptes grossistes, les paniers élevés et les marchés où le virement bancaire est culturellement normal, c'est réellement intéressant.

Le coût opérationnel, c'est le rapprochement. Les fonds ne sont pas confirmés instantanément, les clients quittent votre site pour finaliser le paiement dans leur application bancaire, et quelqu'un dans votre équipe doit associer les virements entrants aux commandes avant l'exécution. Nous l'avons mis en place pour des clients B2B et le coût au jour 2 est "dix minutes de temps comptable chaque matin". Cela vaut le coup pour la bonne boutique.

Référence : PrestaShop ps_wirepayment.

Checkout Revolution (oui, le nôtre)

Transparence totale : Checkout Revolution est notre produit phare et nous pensons évidemment que c'est la bonne réponse pour la plupart des boutiques qui ont dépassé les limites du tunnel natif. Il combine tunnel en une page et boutons express dans un seul module propulsé par Stripe. Boutons d'achat sur la page produit, le panier et le tunnel de commande. Apple Pay, Google Pay, PayPal, Link, cartes et plus de 30 moyens supplémentaires via le Payment Element de Stripe. Les paiements vont directement sur votre compte Stripe.

Nous l'avons construit parce que les clients installaient trois ou quatre modules séparés pour obtenir des fonctionnalités qui auraient dû être livrées ensemble. Si vous voulez un tunnel en une page, des boutons express et un socle de paiement moderne chez un seul éditeur avec un seul contrat de support, c'est ce que nous suggérerions. Si vous avez seulement besoin d'une solution PayPal rapide pour une nouvelle boutique, ps_checkout fera le travail pour moins cher.

Comparatif rapide

Sécurité du tunnel de commande et conformité PCI

Ce n'est pas la section à sauter. Les clients confient leurs données de carte à votre boutique. Une fuite vous coûte de l'argent, des clients et du référencement, dans cet ordre.

Ce que PCI DSS signifie vraiment pour votre boutique

PCI DSS s'applique à toute entreprise qui accepte, traite, stocke ou transmet des informations de carte. Votre charge de conformité dépend entièrement de la façon dont votre tunnel de commande gère les données de carte :

• SAQ A (charge la plus faible). Champs de paiement hébergés ou redirection, les données de carte ne touchent jamais votre serveur. C'est là que vous placent ps_checkout, Stripe Payment Element et le paiement hébergé Mollie. Visez ce niveau.
• SAQ A-EP. Le JavaScript du prestataire de paiement tourne sur votre page et capture les données de carte, même si elles sont envoyées directement au prestataire. Charge légèrement plus élevée.
• SAQ D (charge la plus élevée). Les données de carte passent par votre serveur à un moment quelconque. Les formulaires de paiement personnalisés qui envoient les numéros de carte à votre boutique avant transfert tombent ici. Coûteux, complexe, presque jamais le bon choix. À éviter.

Utilisez des modules de paiement avec champs hébergés ou pages de paiement hébergées. Confirmez le SAQ exact avec votre prestataire ou acquéreur, car les détails d'implémentation comptent et nous ne sommes pas votre QSA.

Champs de paiement hébergés, pas de saisies carte brutes

Les champs de paiement hébergés sont des iframes servies par le prestataire de paiement et intégrées à votre page de commande. Le numéro de carte, l'expiration et le CVV ressemblent à des éléments de votre formulaire, mais s'exécutent sur le domaine du prestataire, votre serveur ne touche jamais les données de carte. Tous les grands prestataires le prennent en charge. Si un module vous demande d'ajouter des champs HTML bruts de carte à votre boutique, partez. C'est un signal d'alerte PCI et un cauchemar de maintenance.

SCA, 3DS2 et SSL

La SCA dans l'UE exige 3DS2 pour la plupart des paiements par carte. Votre module de paiement doit le prendre en charge. Tout ce qui est uniquement 3DS1 verra ses taux d'échec augmenter et finira par ne plus fonctionner du tout. 3DS2 ajoute une étape d'authentification qui peut nuire au taux de finalisation, donc choisissez un prestataire avec de bons taux de réussite 3DS2 et n'affichez pas d'erreurs génériques quand l'authentification échoue. "Réessayez" bat "une erreur est survenue" à chaque fois.

Chaque page de commande doit être en HTTPS. Sans certificat valide, les navigateurs refusent de charger les champs hébergés, Google pénalise le référencement, et les avertissements "Non sécurisé" inquiètent les clients. Let's Encrypt est gratuit. Après installation, vérifiez que tout le HTTP redirige vers HTTPS, le contenu mixte casse silencieusement les modules de paiement.

Vérifiez HTTPS dans le navigateur, pas seulement dans la configuration.

Voici une vraie capture Chrome du tunnel ps178-dev en HTTPS. Chrome moderne a supprimé le cadenas vert, mais le contrôle de sécurité est toujours dans la barre d'adresse, et l'URL du tunnel de commande doit se charger de manière sécurisée pour que les champs de paiement hébergés fonctionnent de façon fiable.

Mesurer la performance du tunnel de commande

On n'améliore pas ce que l'on ne mesure pas. Les indicateurs qui comptent pour un tunnel de commande PrestaShop :

Indicateurs clés

• Taux de finalisation du tunnel, commandes terminées / sessions de commande. Le chiffre le plus important.
• Taux d'abandon du tunnel, pourcentage de clients qui commencent le tunnel de commande sans le terminer. Isole les problèmes de tunnel des simples visiteurs hésitants.
• Abandon par étape, l'étape qui perd le plus de clients. Si 40 % partent à la livraison, vos options de transporteur sont le problème.
• Temps de finalisation. Plus il est long, plus l'abandon augmente.
• Taux d'échec de paiement, des taux élevés indiquent généralement une mauvaise configuration 3DS ou des règles antifraude trop agressives.

Tests A/B des changements du tunnel de commande

Quand vous modifiez la mise en page, testez par rapport à votre propre référence. Envoyez une partie d'un trafic comparable vers le tunnel actuel et une autre vers le nouveau parcours, puis comparez taux de finalisation, échecs de paiement, panier moyen et tickets support. Gardez le test comparable, ne mélangez pas B2B connecté, nouveaux visiteurs mobile et clients récurrents sur ordinateur dans une seule conclusion s'ils se comportent différemment.

E-commerce amélioré GA4

La méthode standard pour mesurer l'entonnoir. Installez un module GA4 qui déclenche begin_checkout, add_shipping_info, add_payment_info et purchase. Configurez un rapport d'entonnoir dans GA4 > Explorer > Exploration de l'entonnoir avec des étapes correspondant à votre tunnel de commande.

Pour un suivi des achats précis, envisagez le côté serveur. Le JavaScript côté client peut être bloqué, retardé ou perdu au fil des redirections. Une implémentation côté serveur du GA4 Measurement Protocol déclenchée par les hooks de commande PrestaShop est ce que nous utilisons sur les boutiques où les rapports de chiffre d'affaires comptent vraiment.

À quoi ressemble un "bon" taux de finalisation

Il n'existe pas de chiffre universel. Une boutique de t-shirts à 5 EUR, un catalogue B2B de pièces détachées et une boutique de meubles à 3 000 EUR ne se comporteront pas de la même manière. Construisez une référence à partir de vos propres données d'analyse, puis surveillez les changements après les modifications du tunnel de commande. Si la finalisation chute brusquement : création de compte forcée, frais de livraison surprise, options de paiement manquantes, validation d'adresse, erreurs de module de paiement. Dans cet ordre.

Ce qui arrive : le tunnel en une page natif dans 9.2

La feuille de route de PrestaShop mentionne 9.2 pour le T2-T3 2026, avec un tunnel natif en une page. C'est une évolution importante : les marchands sur la bonne pile technique pourront proposer un tunnel en une seule page sans module tiers.

Les réserves :

• Thème Hummingbird v2 uniquement. Les boutiques Classic ne le verront pas.
• Optionnel, pas par défaut. Le multi-étapes reste disponible.
• Les auteurs de modules devront adapter leurs modules de paiement et de livraison au nouveau parcours.
• Le calendrier de la feuille de route n'est pas une date de sortie. Il peut bouger.

Faut-il attendre ? Si vous lancez aujourd'hui, non. Attendre des mois (ou plus) une fonctionnalité qui peut nécessiter une migration complète de thème n'est pas réaliste. Si vous êtes déjà sur Hummingbird et que vous planifiez une mise à niveau, surveillez la feuille de route. Notre analyse des plans PS 9.2 se trouve dans les plans d'OPC natif de PrestaShop.

Choisir le bon tunnel de commande pour votre boutique

Il n'existe pas de "meilleure" configuration unique. Voici notre cadre après dix ans à les construire :

• Démarrage, budget serré. Multi-étapes par défaut + ps_checkout. Gratuit, fonctionnel, améliorable plus tard.
• Boutique établie, abandon élevé. Module de tunnel en une page. Le gain de conversion se rembourse souvent en quelques semaines.
• Trafic majoritairement mobile. Paiement express avec Apple Pay et Google Pay. Les formulaires d'adresse mobile sont le plus gros tueur de conversion en e-commerce.
• Vente dans toute l'Europe. Mollie pour les moyens locaux forts, ou Stripe pour une couverture internationale plus large.
• Fort volume. Intégration directe avec Stripe ou Adyen, règlement, rapports et gestion des litiges comptent davantage à grande échelle.
• Entreprise / omnicanal. Adyen pour unifier en ligne + magasin sur une seule plateforme.
• Tout vouloir chez un seul éditeur. Des solutions qui combinent optimisation du parcours et paiements dans un seul module plutôt que d'en empiler trois ou quatre.

Quel que soit votre choix, testez-le. Passez des commandes de test sur différents appareils, essayez plusieurs moyens de paiement, appliquez des codes de réduction, vérifiez ce qui se passe quand les choses tournent mal. Le tunnel de commande est l'endroit où le chiffre d'affaires se crée. Il mérite plus d'attention que la plupart des boutiques ne lui accordent.

FAQ

ps_checkout est-il la même chose que le tunnel de commande PrestaShop ?

Non, et c'est la confusion la plus fréquente que nous rencontrons. Le tunnel de commande est le parcours en plusieurs étapes (panier, informations personnelles, adresse, livraison, paiement) intégré à chaque boutique PrestaShop. ps_checkout est un module de paiement gratuit développé par PrestaShop SA avec PayPal, qui affiche uniquement des options de paiement à l'étape de paiement. Il ne change ni les étapes, ni la mise en page, ni l'ordre des champs. Désinstaller ps_checkout ne modifie pas votre tunnel de commande, et l'installer ne vous donnera pas un tunnel en une page, quiconque vous dit le contraire n'a pas lu le README du module.

Pourquoi mon tunnel affiche-t-il "Aucun moyen de paiement disponible" ?

Cela signifie qu'aucun module de paiement n'a renvoyé quoi que ce soit depuis le hook paymentOptions. Les causes habituelles, dans l'ordre : une restriction de devise ou de pays exclut le panier ; Paiement > Préférences exclut le transporteur, le pays ou le groupe client actuel ; le module de paiement a rencontré une erreur PHP et a échoué silencieusement (vérifiez var/logs/) ; ou, sur PS 8+, les en-têtes CSP bloquent le JavaScript du module. Commencez par Paiement > Préférences. Un module entièrement installé et actif peut rester invisible si une restriction exclut le contexte du panier courant.

Pourquoi mon panier se vide-t-il à l'étape de paiement ?

Les paniers vidés sont presque toujours un problème de cookie ou de session : mauvaise configuration SSL, domaines boutique et SSL différents, partition de sessions pleine, ou module qui réinitialise le panier dans un hook du tunnel de commande. Désactivez les modules un par un jusqu'à ce que le tunnel se comporte correctement pour trouver le responsable. C'est rarement le prestataire de paiement lui-même. Le panier a déjà disparu avant que le prestataire soit appelé.

Dois-je gérer moi-même la conformité PCI ?

Gardez les données de carte hors de votre serveur et votre charge reste au niveau le plus bas (SAQ A). Utilisez un module avec champs de paiement hébergés ou redirection, ps_checkout, le Payment Element de Stripe et le paiement hébergé de Mollie vous placent tous dans ce cas, car le numéro de carte, l'expiration et le CVV s'exécutent sur le domaine du prestataire dans une iframe, pas sur votre boutique. Si un module vous demande d'ajouter des champs HTML bruts de carte à votre page, partez : cela vous pousse vers SAQ D, coûteux et presque jamais le bon choix. Confirmez le SAQ exact avec votre prestataire, nous ne sommes pas votre QSA.

Faut-il attendre le tunnel en une page natif de 9.2 ?

Si vous lancez aujourd'hui, non. Attendre des mois une fonctionnalité qui peut exiger une migration complète vers le thème Hummingbird n'est pas réaliste, et la version native sera réservée à Hummingbird et optionnelle plutôt que proposée par défaut. Si vous êtes déjà sur Hummingbird et que vous planifiez une mise à niveau, surveillez la feuille de route. Tant qu'il n'est pas livré, un tunnel en une page signifie un module, c'est le territoire de Checkout Revolution. Notre analyse complète se trouve dans les plans d'OPC natif de PrestaShop.

À lire aussi

• Guide d'optimisation du tunnel de commande PrestaShop, des changements concrets qui améliorent le taux de finalisation
• Tunnel en une page natif de PrestaShop 9.2, notre lecture de la feuille de route
• Checkout Revolution, notre module une page + express
• Express Checkout, boutons portefeuille sans remplacer votre tunnel de commande
• Hooks & overrides PrestaShop, les hooks déclenchés par le tunnel de commande et comment s'y brancher proprement