PrestaShop Checkout : le processus, le module et vos meilleures options

Qu'est-ce que le PrestaShop Checkout ?

Si vous avez déjà recherché « prestashop checkout », vous avez probablement remarqué que ce terme signifie deux choses très différentes selon le contexte. Il peut désigner le processus de commande intégré à chaque boutique PrestaShop — le parcours en plusieurs étapes que les clients suivent pour finaliser un achat — ou le module PrestaShop Checkout (ps_checkout), une solution de paiement spécifique développée par PrestaShop SA en partenariat avec PayPal.

Cet article couvre les deux aspects. Nous allons vous montrer comment fonctionne le processus de commande PrestaShop par défaut, expliquer ce que le module ps_checkout fait réellement (et ne fait pas), examiner les options de personnalisation, comparer les alternatives les plus courantes, et discuter de la sécurité du checkout PrestaShop, de la conformité PCI et de la manière de mesurer les performances du checkout — afin que vous puissiez prendre une décision éclairée pour votre boutique.

Comment fonctionne le processus de commande PrestaShop

Le parcours multi-étapes par défaut

Chaque boutique PrestaShop est livrée avec un processus de commande intégré. Il s'agit d'un processus en plusieurs étapes réparti sur des chargements de pages séparés. Le client passe par cinq étapes distinctes :

1. Vérification du panier — le client vérifie les produits, les quantités et les totaux avant de continuer
2. Informations personnelles — connexion, création de compte ou commande en tant qu'invité
3. Adresse — saisie ou sélection de l'adresse de livraison et de facturation
4. Livraison — sélection du transporteur en fonction de l'adresse de livraison et du poids/dimensions du panier
5. Paiement — sélection du mode de paiement et confirmation de commande

Après le paiement, le client arrive sur une page de confirmation. C'est l'expérience de checkout de base que chaque thème doit implémenter, et c'est la fondation sur laquelle tous les modules de paiement, modules de livraison et personnalisations du checkout s'appuient.

PrestaShop 1.7 Checkout vs. PrestaShop 8/9 Checkout

Bien que le parcours de commande général soit resté cohérent d'une version à l'autre, il existe des différences significatives entre la version 1.7 et les versions modernes 8.x/9.x :

• Architecture du thème — PrestaShop 1.7 a introduit le thème Classic avec un checkout fortement basé sur JavaScript utilisant AJAX pour valider chaque étape. PrestaShop 8 et 9 poursuivent ce modèle mais avec l'option du thème Hummingbird, qui remplace jQuery par un stack frontend plus moderne.
• Changements des hooks de paiement — En 1.7, le hook paymentOptions a remplacé les anciens hooks displayPayment et displayPaymentEU de la version 1.6. PrestaShop 8 et 9 imposent cela — les hooks de paiement hérités ne fonctionnent plus, donc tout module utilisant encore displayPayment n'apparaîtra pas au checkout.
• Migration Symfony — PrestaShop 8 a migré davantage du back office vers Symfony, et la version 9 poursuit cette migration. Le contrôleur front-office du checkout (OrderController) fonctionne encore sur le framework legacy, mais les pages de gestion des commandes du back office sont désormais basées sur Symfony.
• En-têtes de sécurité — PrestaShop 8+ est livré avec des en-têtes Content Security Policy par défaut plus stricts, qui peuvent bloquer le JavaScript externe des fournisseurs de paiement. C'est une source fréquente de problèmes de « formulaire de paiement vide » après une mise à jour.
• Exigences de version PHP — PrestaShop 9 nécessite PHP 8.1+, ce qui signifie que les modules de paiement utilisant des fonctionnalités PHP obsolètes peuvent casser lors de la mise à jour.

Le contrôleur du checkout : OrderController

Sous le capot, le checkout est piloté par la classe OrderController (située dans controllers/front/OrderController.php). Ce contrôleur orchestre l'ensemble du processus — il charge le panier, valide chaque étape, déclenche les hooks et génère le template du checkout.

Méthodes clés à connaître si vous déboguez ou développez :

• initContent() — configure le processus de commande, charge le résumé du panier et détermine quelle étape afficher
• checkoutProcess — un objet CheckoutProcess qui contient la chaîne des étapes du checkout (informations personnelles, adresse, livraison, paiement)
• getCheckoutSession() — retourne les données de session qui suivent quelles étapes sont complétées

Chaque étape est implémentée comme une classe séparée (par exemple, CheckoutAddressesStep, CheckoutDeliveryStep, CheckoutPaymentStep) qui hérite de AbstractCheckoutStep. Cette architecture modulaire signifie que les modules peuvent surcharger ou étendre des étapes individuelles sans remplacer l'ensemble du processus de commande.

Ce qui se passe à chaque étape

Derrière chaque étape, PrestaShop exécute une logique de validation et déclenche des hooks que les modules peuvent utiliser pour étendre le processus :

• Validation de l'adresse — PrestaShop vérifie les champs obligatoires, valide la combinaison pays/état et vérifie que l'adresse correspond au format configuré. Les règles fiscales sont recalculées en fonction du pays de livraison.
• Sélection du transporteur — les transporteurs disponibles sont filtrés par la zone de l'adresse de livraison, le poids du panier, les dimensions des produits et les restrictions de transporteurs configurées. Les frais de livraison sont calculés en temps réel. Le hook actionCarrierProcess permet aux modules d'intervenir ici.
• Affichage des paiements — chaque module de paiement actif s'enregistre via le hook paymentOptions. PrestaShop affiche les modes de paiement disponibles dans l'ordre que vous avez configuré dans le back office.
• Validation de la commande — lorsque le client confirme, PrestaShop valide l'ensemble de la commande via actionValidateOrder, traite le paiement, décrémente le stock, envoie les e-mails de confirmation et crée l'enregistrement de la commande.

Cette architecture basée sur les hooks est ce qui rend le checkout si extensible — mais elle signifie aussi que des modules mal codés peuvent interférer entre eux, causant le genre d'erreurs que les marchands ont souvent du mal à diagnostiquer.

Performance du PrestaShop Checkout : ce qui le ralentit

Un checkout lent impacte directement les conversions. Chaque seconde supplémentaire de temps de chargement augmente la probabilité qu'un client abandonne son panier. Les goulots d'étranglement courants incluent :

• Trop de modules accrochés aux hooks du checkout — chaque module enregistré sur les hooks du checkout (displayPayment, displayBeforeCarrier, actionCarrierProcess, etc.) ajoute du temps d'exécution. Nous avons vu des boutiques avec plus de 15 modules déclenchés au checkout, ajoutant 2 à 3 secondes de traitement.
• Appels API externes — les calculs de tarifs de livraison en temps réel (APIs UPS, FedEx, DHL), les services de calcul de taxes (TaxJar, Avalara) et les APIs de vérification d'adresse ajoutent tous de la latence réseau. Si l'un de ces services est lent ou inaccessible, votre checkout entier se bloque.
• Calculs de transporteurs non optimisés — les boutiques avec des dizaines de transporteurs et des règles complexes de zones/poids forcent PrestaShop à exécuter des requêtes de base de données extensives à l'étape de livraison. Consolider les transporteurs et simplifier les configurations de zones peut réduire significativement le temps de chargement de cette étape.
• Évaluation des règles de panier — si vous avez des centaines de règles de panier actives, PrestaShop doit évaluer chacune d'elles par rapport au panier actuel à chaque étape du checkout. Nettoyer périodiquement les règles de panier expirées ou inutilisées aide.
• Index de base de données manquants — les tables ps_cart_rule, ps_cart_rule_combination et ps_specific_price peuvent devenir volumineuses sur les boutiques actives. S'assurer que des index appropriés existent sur ces tables évite les requêtes lentes pendant le checkout.
• Pas d'OPcache ni de cache d'objets — PHP OPcache devrait toujours être activé en production. Redis ou Memcached pour le cache de session et d'objets réduit davantage les temps de réponse du checkout.

Pour diagnostiquer les problèmes de vitesse du checkout, activez le profileur de débogage de PrestaShop (_PS_DEBUG_PROFILING_ dans config/defines.inc.php) et examinez quels hooks et modules consomment le plus de temps lors du chargement de la page de checkout.

Erreurs courantes du PrestaShop Checkout et comment les corriger

Voici les erreurs de checkout PrestaShop que les marchands rencontrent le plus fréquemment :

« Aucun mode de paiement disponible » — C'est l'erreur la plus recherchée sur Google. Elle signifie qu'aucun module de paiement n'a retourné d'options via le hook paymentOptions. Causes courantes :

• Le module de paiement n'est pas configuré pour la devise ou le pays du client
• Les restrictions du module de paiement dans Paiement > Préférences excluent le transporteur, le pays ou le groupe de clients actuel
• Le module de paiement a une erreur PHP et échoue silencieusement — vérifiez les logs PrestaShop dans var/logs/
• Sur PrestaShop 8+, un en-tête Content Security Policy bloque le JavaScript du module, empêchant son affichage

« Une erreur s'est produite lors du traitement de votre commande » — Ce message générique peut avoir des dizaines de causes. Commencez par vérifier :

• Les logs d'erreur PrestaShop et le log d'erreur PHP pour l'exception réelle
• Si la passerelle de paiement a retourné un code d'erreur spécifique (vérifiez les logs de transaction du module de paiement)
• La disponibilité du stock — si un produit est devenu épuisé entre le panier et le paiement, la création de commande échoue
• Les conflits de règles de panier — un code de réduction invalide ou expiré dans le panier peut faire échouer la validation à la dernière étape

Le panier se vide au checkout — Les clients signalent que leur panier se vide lorsqu'ils arrivent à la page de checkout. C'est presque toujours un problème de cookie ou de session :

• Mauvaise configuration SSL — le panier est stocké dans un cookie de session qui ne se transfère pas entre HTTP et HTTPS
• Non-correspondance de domaine — si l'URL de votre boutique et le domaine SSL ne correspondent pas exactement, les cookies ne sont pas partagés
• Stockage de session plein — si les sessions sont stockées sur disque et que la partition est pleine, de nouvelles sessions ne peuvent pas être créées
• Un module qui appelle Context::getContext()->cart = new Cart() pendant un hook du checkout, réinitialisant accidentellement le panier

Échecs de validation d'adresse — Les clients ne peuvent pas passer l'étape de l'adresse. Vérifiez :

• Les champs d'adresse obligatoires dans International > Zones géographiques > Pays — certains pays exigent un état/région que le client n'a pas sélectionné
• La chaîne de format d'adresse pour le pays de livraison — un format mal formé peut faire rejeter des adresses valides par la validation
• Le regex de validation du code postal — PrestaShop valide les codes postaux selon des modèles spécifiques au pays, qui peuvent être incorrects ou trop stricts pour certaines régions

Problèmes de redirection 3DS — Après l'authentification 3D Secure, le client n'est pas redirigé vers la boutique ou arrive sur une page d'erreur. Cela se produit quand :

• L'URL de retour configurée dans le module de paiement utilise HTTP au lieu de HTTPS
• La session a expiré pendant la vérification 3DS (le client a pris trop de temps)
• L'URL webhook/callback du module de paiement est inaccessible depuis les serveurs du fournisseur de paiement (pare-feu, URL incorrecte)
• Des configurations multi-domaines où l'URL de retour 3DS pointe vers un domaine différent de celui sur lequel le client fait ses achats

Les règles de panier et la couche de réductions

L'une des parties les plus complexes de tout checkout PrestaShop est la façon dont les réductions sont appliquées. Les règles de panier (bons, codes promo, réductions automatiques) et les prix spécifiques au niveau du catalogue interagissent tous pendant le checkout, et les résultats peuvent être déroutants.

• Les règles de panier sont évaluées par ordre de priorité. Certaines s'appliquent à l'ensemble du panier, d'autres à des produits ou catégories spécifiques. Elles peuvent offrir des réductions en pourcentage, des montants fixes ou la livraison gratuite.
• Les prix spécifiques (définis par produit dans le catalogue) sont appliqués avant les règles de panier, ce qui signifie qu'un produit déjà en promotion peut ne pas être éligible à certaines promotions.
• Restrictions de cumul — PrestaShop vous permet de marquer des règles de panier comme non cumulables, mais la logique de quelle règle « gagne » n'est pas toujours intuitive, surtout avec les boutiques multi-devises.

Règles de livraison gratuite et interaction avec les transporteurs

Les règles de panier avec livraison gratuite sont l'une des fonctionnalités de checkout les plus mal comprises. Une règle de panier avec « livraison gratuite » ne signifie pas que tous les transporteurs deviennent gratuits. Voici comment cela fonctionne réellement :

• Si la règle de panier n'est pas restreinte à des transporteurs spécifiques, la livraison gratuite s'applique au transporteur que le client sélectionne
• Si la règle de panier est restreinte à des transporteurs spécifiques, seuls ces transporteurs apparaissent comme gratuits — les autres transporteurs affichent toujours leur prix normal
• Les restrictions de pays et de zone de la règle de panier s'appliquent également — une règle « livraison gratuite en Allemagne » ne rendra pas la livraison gratuite pour une adresse de livraison française
• Lorsque plusieurs règles de panier offrent la livraison gratuite, la première valide (par priorité) est appliquée. Les autres sont toujours « utilisées » du point de vue du client mais n'ajoutent pas d'avantages supplémentaires.

Le problème de priorité et de cumul

La priorité des règles de panier détermine l'ordre d'évaluation, et elle compte plus que la plupart des marchands ne le réalisent. Considérez cet exemple :

• Règle A (priorité 1) : 20 % de réduction sur l'ensemble du panier, non cumulable
• Règle B (priorité 2) : Livraison gratuite pour les commandes de plus de 50 EUR

Parce que la Règle A est non cumulable et a une priorité plus élevée, la Règle B ne s'appliquera pas — même si la livraison gratuite semble être un avantage séparé. Le client obtient 20 % de réduction mais paie la livraison. Pour corriger cela, vous devriez soit rendre la Règle A cumulable, soit intégrer la livraison gratuite dans la Règle A elle-même.

Un autre scénario courant : un client entre un code bon de 10 EUR, mais le panier a aussi une réduction automatique de 15 %. Si la réduction automatique est non cumulable et a une priorité plus élevée, le bon est rejeté — et le client voit un message confus « ce bon n'est pas valide » sans explication de la raison.

Pourquoi les règles de panier « montant minimum » déroutent les marchands

Le champ « montant minimum » des règles de panier vérifie le total du panier avant ou après les autres réductions selon la configuration — et c'est là que la confusion survient. Si vous définissez un minimum de 100 EUR et que le client a un panier d'une valeur de 110 EUR mais qu'une règle de panier précédente l'a déjà réduit à 95 EUR, la vérification du montant minimum peut échouer. De plus, le « montant minimum » peut être configuré pour inclure ou exclure les taxes et la livraison, menant à des seuils différents selon la localisation du client et le transporteur choisi. Testez toujours vos règles de montant minimum avec des scénarios de panier réels dans différents pays avant de les déployer.

Commande invité vs. création de compte

PrestaShop prend en charge la commande en tant qu'invité par défaut, permettant aux clients de passer des commandes sans créer un compte complet. Cela réduit considérablement les frictions — les études montrent systématiquement que la création de compte obligatoire est l'une des principales raisons d'abandon de panier. Vous pouvez activer ou désactiver la commande invité dans Paramètres de la boutique > Paramètres clients. Nous traitons ce sujet en profondeur dans notre guide de la commande invité, y compris les compromis entre taux de conversion et collecte de données clients.

Module PrestaShop Checkout (ps_checkout)

Qu'est-ce que ps_checkout ?

Le module PrestaShop Checkout — techniquement nommé ps_checkout — est un module de paiement gratuit développé conjointement par PrestaShop SA et PayPal. Il est préinstallé sur les nouvelles installations PrestaShop depuis la version 1.7.5.

Voici la distinction clé qui déroute de nombreux marchands : ps_checkout est un module de paiement, pas le processus de commande lui-même. Il ne modifie pas vos étapes de checkout, la mise en page ou l'ordre dans lequel les informations sont collectées. Il gère uniquement l'étape du paiement — en offrant à vos clients plus de moyens de payer. Le processus de commande sous-jacent décrit ci-dessus reste exactement le même.

Ce qu'il propose

Sur le papier, ps_checkout offre un ensemble solide de fonctionnalités de paiement :

• Paiements par carte — Visa, Mastercard et American Express via des champs hébergés par PayPal intégrés dans votre checkout
• Portefeuille PayPal — les clients paient avec leur solde PayPal ou leur compte bancaire lié
• Apple Pay et Google Pay — support des portefeuilles mobiles (selon disponibilité)
• Modes de paiement locaux — iDEAL, Bancontact, BLIK et d'autres selon votre marché
• Pay Later / Paiement en 3-4 fois — options achetez maintenant, payez plus tard propulsées par PayPal
• 3D Secure 2 — authentification forte du client obligatoire pour les transactions UE
• Plus de 20 devises — support multi-devises via le réseau PayPal

Pour un module gratuit, c'est une liste de fonctionnalités généreuse. Vous pouvez consulter la documentation complète sur le dépôt GitHub de ps_checkout.

Détail des frais de transaction

Bien que ps_checkout soit gratuit, vous payez les frais de transaction standard de PayPal sur chaque commande. En 2026, voici ce à quoi vous pouvez vous attendre :

Notez que ces tarifs peuvent varier en fonction de votre niveau de compte PayPal et de votre volume mensuel. Les marchands à fort volume peuvent être éligibles à des tarifs réduits via le programme de tarifs marchands PayPal.

ps_checkout vs. Stripe vs. Mollie : comparaison du PrestaShop Checkout

Pour vous aider à évaluer vos options, voici une comparaison côte à côte des trois solutions de paiement les plus populaires :

Comment installer et configurer ps_checkout

Configuration de ps_checkout : installez le module (préinstallé sur les nouvelles boutiques, sinon téléchargez-le depuis Addons), liez votre compte PrestaShop Addons, connectez votre compte PayPal Business via l'assistant d'intégration (les comptes personnels ne sont pas pris en charge), configurez les modes de paiement à proposer, assurez-vous que les paramètres d'arrondi/devise correspondent aux attentes de PayPal, et testez en mode sandbox avant de passer en production.

Comment désinstaller ps_checkout

Pour supprimer ps_checkout : allez dans Modules > Gestionnaire de modules, recherchez « ps_checkout » et sélectionnez d'abord Désactiver (sûr — arrête l'affichage sans supprimer les données). Pour le supprimer complètement, sélectionnez Désinstaller, puis supprimez éventuellement modules/ps_checkout/. Important : assurez-vous qu'un autre module de paiement est configuré d'abord, sinon le checkout affichera « Aucun mode de paiement disponible ».

L'architecture d'intermédiaire PayPal

C'est là que les choses deviennent plus nuancées. Contrairement à une intégration directe Stripe ou Adyen où les paiements vont directement sur votre compte marchand, ps_checkout achemine les transactions via le compte de plateforme commerce PayPal intermédiaire de PrestaShop SA. PrestaShop SA agit comme facilitateur.

Ce que cela signifie en pratique :

• Vous devez lier votre compte PayPal Business via le processus d'intégration de PrestaShop — pas directement avec PayPal
• Le calendrier de règlement et la disponibilité des fonds dépendent à la fois des politiques de PayPal et de la configuration de la plateforme de PrestaShop SA
• Le traitement des chargebacks passe par une couche supplémentaire, rendant les litiges plus lents à résoudre
• Vous avez moins de visibilité sur les données brutes de transaction comparé à une intégration directe de passerelle

Cette architecture n'est pas fondamentalement mauvaise — c'est ainsi que fonctionnent de nombreux modèles de facilitateur de paiement (Shopify Payments fonctionne de manière similaire). Mais il vaut la peine de le comprendre avant de vous engager, surtout si votre boutique traite de gros volumes ou opère dans des secteurs réglementés.

Limitations connues

Sur la base des retours de la communauté, des issues GitHub et de nos propres tests, voici les problèmes les plus fréquemment signalés avec ps_checkout :

• Compatibilité de thème — le module fonctionne mieux avec le thème Classic. Les thèmes non standard, en particulier ceux fortement personnalisés, rencontrent fréquemment des problèmes d'affichage avec les champs de paiement hébergés.
• Spinner infini — un problème bien connu où le formulaire de paiement ne finit jamais de charger, typiquement causé par des conflits JavaScript avec d'autres modules ou des en-têtes Content Security Policy bloquant les scripts de PayPal.
• Messages d'erreur 3DS génériques — lorsque l'authentification 3D Secure échoue, le message d'erreur affiché au client est souvent peu utile, menant à des achats abandonnés qui auraient pu être récupérés avec une communication plus claire.
• Pas de support dédié — le support est assuré via les forums communautaires et les issues GitHub plutôt qu'un canal de support direct, ce qui peut être frustrant pour les marchands confrontés à des échecs de paiement.
• Risques de mise à jour — les mises à jour majeures ont historiquement introduit des changements cassants. Le module évolue rapidement, ce qui est positif pour les fonctionnalités mais risqué pour la stabilité.

Aucun de ces problèmes n'est rédhibitoire en soi, mais ensemble ils signifient que vous devriez tester minutieusement avant de passer en production — et toujours tester les mises à jour de modules dans un environnement de staging d'abord.

Quand ps_checkout est pertinent

Malgré les limitations, ps_checkout est un choix solide pour certains scénarios :

• Nouvelles boutiques — vous démarrez et avez besoin d'accepter des paiements rapidement sans coûts initiaux
• Boutiques mono-marché — vous vendez principalement dans un pays et n'avez pas besoin de règlement multi-devises complexe
• Marchands soucieux du budget — aucun coût de module, pas de frais mensuels, et tarification au paiement via PayPal
• Catalogues simples — produits standards sans abonnements, précommandes ou workflows de paiement complexes

Personnaliser le checkout PrestaShop

Que pouvez-vous changer sans modules ?

Avant d'installer des modules tiers, il existe plusieurs façons de personnaliser le checkout avec les outils intégrés :

• Templates de thème — modifiez les templates Smarty du checkout dans votre thème pour changer la mise en page, l'ordre des champs ou ajouter du contenu personnalisé entre les étapes
• Style CSS — ajustez les couleurs, les espacements, les tailles de boutons et la typographie pour correspondre à votre marque sans toucher à la fonctionnalité
• Configuration des transporteurs — restructurez la présentation des options de livraison en ajustant les noms, descriptions, estimations de délai et ordre d'affichage des transporteurs
• Ordre des modules de paiement — réorganisez quel mode de paiement apparaît en premier dans le back office sous Paiement > Préférences
• Champs obligatoires — ajustez quels champs client et adresse sont obligatoires via la configuration Clients > Adresses

Ces modifications sont des personnalisations sûres au niveau du thème qui survivent aux mises à jour PrestaShop tant que vous utilisez un thème enfant. Pour approfondir l'optimisation de votre checkout sans ajouter de complexité, consultez notre guide d'optimisation du checkout.

Champs de checkout personnalisés

De nombreux marchands ont besoin d'informations supplémentaires lors du checkout PrestaShop que l'installation par défaut ne collecte pas. Des exemples courants incluent : numéro de mobile pour les notifications SMS de livraison, nom d'entreprise et numéro de TVA pour les flux B2B, instructions de livraison (codes de porte, « laisser chez le voisin ») et références de commande personnalisées (numéros de bon de commande).

PrestaShop prend en charge l'ajout de champs personnalisés au formulaire d'adresse via le back office (Clients > Adresses), mais les options sont limitées. Pour des besoins plus complexes, vous pouvez soit modifier vos templates de checkout directement et traiter les données via un module personnalisé accroché à actionValidateOrder, soit utiliser un module tiers de champs de checkout depuis la marketplace Addons.

Traduction et localisation du checkout

Si vous vendez à l'international, traduire le checkout PrestaShop est essentiel. Des libellés et messages d'erreur non traduits causent directement l'abandon — un client qui ne comprend pas l'étape de paiement ne finalisera pas la commande.

Tâches de localisation clés :

• Libellés des étapes du checkout — traduits via International > Traductions. Sélectionnez « Traductions front office » et votre thème pour trouver les chaînes liées au checkout.
• Textes des modules de paiement — chaque module de paiement a ses propres fichiers de traduction, séparés des traductions du cœur.
• Messages d'erreur — les erreurs de validation comme « Veuillez entrer une adresse valide » sont souvent oubliées lors de la traduction.
• Conditions générales de vente — la case « J'accepte les CGV » renvoie à une page CMS qui doit être traduite par langue.
• Libellés du formulaire d'adresse — PrestaShop utilise des formats d'adresse spécifiques au pays. Assurez-vous que les libellés correspondent à la langue du client.

Piège courant : installer un pack de langue ne traduit pas les chaînes spécifiques aux modules. Si le checkout affiche des noms de modes de paiement en anglais dans une boutique française, traduisez le module de paiement séparément.

One Page Checkout

La personnalisation de checkout la plus populaire est de regrouper toutes les étapes sur une seule page. Au lieu de naviguer à travers cinq écrans séparés, le client voit l'adresse, la livraison et les champs de paiement tous en même temps — les remplissant et finalisant l'achat sans rechargement de page.

Les données sont claires : le one page checkout réduit les taux d'abandon en éliminant la friction des étapes multiples. Moins de clics, moins de chances que le client parte. Les benchmarks du secteur montrent que les implémentations de one page checkout améliorent typiquement les taux de conversion de 10 à 20 % par rapport aux parcours multi-étapes. Les gains les plus importants viennent des utilisateurs mobiles, où chaque chargement de page sur une connexion lente risque de perdre le client. Nous détaillons les chiffres et l'approche dans notre article explicatif sur le one page checkout.

Du point de vue UX, le one page checkout signifie : tous les champs de formulaire visibles immédiatement, mises à jour instantanées des frais de livraison via AJAX, validation en ligne (les erreurs apparaissent pendant la saisie), pas besoin d'indicateur de progression, et le récapitulatif de commande reste visible tout au long. Ces changements réduisent collectivement la charge cognitive et maintiennent les clients concentrés sur la finalisation de l'achat.

Actuellement, PrestaShop n'inclut pas de one page checkout natif — le parcours multi-étapes est tout ce que vous obtenez par défaut. Cela change avec PrestaShop 9.2, qui introduira un OPC natif optionnel pour les boutiques utilisant le thème Hummingbird v2. D'ici là, les modules tiers sont le seul moyen d'obtenir cette fonctionnalité.

Express Checkout

L'express checkout pousse le concept plus loin : au lieu d'optimiser la page de checkout, il permet aux clients de la passer entièrement. Des boutons d'achat propulsés par Apple Pay, Google Pay ou PayPal apparaissent directement sur les pages produits et le panier. Le client s'authentifie avec son portefeuille, qui fournit son adresse de livraison et ses informations de paiement en un seul clic — pas de formulaires, pas d'étapes.

C'est particulièrement puissant sur mobile, où la saisie d'adresses sur de petits écrans est un frein majeur à la conversion. Nous explorons les modèles d'express checkout et leur implémentation dans notre article approfondi sur l'express checkout.

Checkout intégré et modal

Un modèle moins courant mais en croissance est le checkout intégré — où le formulaire de paiement apparaît dans une fenêtre modale ou en ligne sur la page actuelle sans naviguer vers une URL de checkout séparée. Cela maintient le client dans le contexte d'achat tout en collectant les informations de paiement, réduisant la distance psychologique entre « je veux ça » et « je l'ai acheté ». Le Payment Element de Stripe et l'expérience in-context de PayPal prennent tous deux en charge cette approche.

Alternatives au PrestaShop Checkout

Si ps_checkout ne répond pas à vos besoins, plusieurs alternatives matures existent pour gérer les paiements dans votre processus de checkout PrestaShop.

Stripe

Le Payment Element de Stripe est l'une des intégrations de paiement les plus conviviales pour les développeurs. Points forts :

• Compte marchand direct — les paiements sont versés sur votre compte Stripe sans intermédiaire
• Plus de 135 devises avec conversion automatique
• Apple Pay, Google Pay, Link (le portefeuille de cartes enregistrées de Stripe) et plus de 40 modes de paiement locaux
• API complète avec une excellente documentation
• Protection anti-fraude intégrée via Stripe Radar

Idéal pour : les boutiques internationales, les marchands techniquement capables, les boutiques voulant un contrôle total sur leurs données de paiement et l'expérience client.

Mollie

Mollie est le fournisseur de paiement dominant pour le e-commerce européen, avec une adoption particulièrement forte aux Pays-Bas, en Belgique, en Allemagne et en France. Points forts :

• Tarification transparente, à la transaction, sans frais mensuels
• Support natif d'iDEAL, Bancontact, SOFORT, EPS, Giropay et KBC/CBC
• Module PrestaShop solide maintenu directement par Mollie
• Intégration facile avec approbation rapide du compte

Idéal pour : les boutiques focalisées sur l'UE, en particulier celles vendant dans les régions Benelux ou DACH où les modes de paiement locaux dominent.

Adyen

Adyen est l'option entreprise pour les boutiques à fort volume. Utilisé par des entreprises comme Booking.com et eBay, il propose plus de 250 modes de paiement avec routage intelligent, détection de fraude avancée (RevenueProtect) et acquisition directe — Adyen est à la fois processeur et acquéreur, réduisant les intermédiaires.

Le compromis est la complexité et le coût. Adyen nécessite une intégration personnalisée, a des volumes de traitement minimum et facture des frais mensuels de plateforme. Ce n'est pas pratique pour les petites boutiques, mais pour les marchands traitant plus de 50 000 EUR par mois, les taux d'autorisation améliorés justifient souvent l'investissement.

Amazon Pay

Amazon Pay permet aux clients de payer avec leur compte Amazon existant — adresse, mode de paiement, et tout le reste. Le checkout en un clic avec les informations Amazon enregistrées, la forte confiance dans la marque et la Garantie A à Z de protection des acheteurs en font une option de paiement secondaire efficace aux côtés des cartes et de PayPal. Un module PrestaShop est disponible sur la marketplace Addons.

Module PayPal autonome

Si vous voulez les paiements PayPal sans la couche d'intermédiaire PrestaShop SA, vous pouvez utiliser un module PayPal autonome qui se connecte directement à votre compte PayPal Business. Cela vous donne :

• Contrôle direct sur votre compte PayPal, les règlements et la gestion des litiges
• La même expérience de portefeuille PayPal que les clients attendent
• Les options Pay Later configurées via votre propre tableau de bord PayPal

Idéal pour : les marchands qui veulent PayPal comme option de paiement mais préfèrent une relation directe avec PayPal plutôt que le modèle intermédié de ps_checkout.

Checkout Revolution (par mypresta.rocks)

En toute transparence : c'est notre module. Checkout Revolution combine le one page checkout et l'express checkout en une seule solution propulsée par Stripe. Il place des boutons d'achat sur les pages produits, le panier et le checkout — prenant en charge Apple Pay, Google Pay, PayPal, Link, les cartes et plus de 30 modes de paiement supplémentaires via le Payment Element de Stripe. Les paiements vont directement sur votre compte Stripe — sans intermédiaire.

Nous l'avons créé parce que nous avons vu des marchands installer trois ou quatre modules séparés pour obtenir une fonctionnalité qui devrait fonctionner ensemble de manière transparente. Ce n'est pas adapté à chaque boutique, mais si vous voulez l'express checkout et une stack de paiement moderne dans un seul package, cela vaut le coup d'œil.

Alternatives au PrestaShop Checkout : comparaison rapide

Sécurité du checkout et conformité PCI

La sécurité n'est pas optionnelle pour un checkout en ligne — c'est une exigence légale et commerciale. Les clients confient à votre boutique leurs informations de paiement, et toute violation peut entraîner des sanctions financières, des poursuites judiciaires et des dommages irréparables à votre image de marque.

Ce que PCI DSS signifie pour les marchands PrestaShop

PCI DSS (Payment Card Industry Data Security Standard) est un ensemble de normes de sécurité qui s'applique à toute entreprise qui accepte, traite, stocke ou transmet des informations de carte de crédit. En tant que propriétaire de boutique PrestaShop, votre niveau de conformité PCI dépend de la façon dont votre checkout gère les données de carte :

• SAQ A (charge minimale) — si vous utilisez des champs de paiement hébergés ou des redirections où les données de carte ne touchent jamais votre serveur, vous êtes éligible au questionnaire d'auto-évaluation le plus simple. C'est le cas avec ps_checkout, Stripe Payment Element et le checkout hébergé de Mollie.
• SAQ A-EP — si votre page de checkout charge du JavaScript du fournisseur de paiement qui capture les données de carte sur votre page (même si elles sont envoyées directement au fournisseur), vous relevez de cette catégorie légèrement plus exigeante.
• SAQ D (charge maximale) — si les données de carte passent par votre serveur à un moment quelconque (par ex., un formulaire de paiement personnalisé mal conçu qui envoie les numéros de carte à votre serveur avant de les transmettre), vous faites face à l'évaluation PCI DSS complète. C'est extrêmement coûteux et complexe — évitez-le.

La conclusion pratique : utilisez toujours des modules de paiement qui offrent des champs de paiement hébergés ou des pages de checkout hébergées. Cela garantit que les données de carte ne touchent jamais votre serveur et vous maintient dans la catégorie SAQ A.

Pourquoi les champs de paiement hébergés sont importants

Les champs de paiement hébergés sont des iframes servis par le fournisseur de paiement et intégrés dans votre page de checkout. Les champs de numéro de carte, date d'expiration et CVV ressemblent à une partie de votre formulaire mais fonctionnent sur le domaine du fournisseur — les données de carte ne touchent jamais votre serveur. Tous les grands fournisseurs (ps_checkout, Stripe, Mollie, Adyen) prennent en charge cette approche. Si un module de paiement vous demande de créer des champs de saisie de carte HTML bruts, évitez-le — c'est un signal d'alarme de conformité PCI.

SCA, 3DS2 et exigences SSL

La réglementation européenne sur l'authentification forte du client (SCA) exige 3D Secure 2 (3DS2) pour la plupart des paiements par carte en ligne. Votre module de paiement doit prendre en charge 3DS2 — les modules plus anciens ne supportant que 3DS1 verront des échecs croissants. 3DS2 ajoute une étape d'authentification bancaire au checkout PrestaShop, ce qui peut augmenter l'abandon, donc choisissez un fournisseur avec des taux de réussite 3DS2 élevés. Un échec 3DS ne signifie pas toujours une fraude — affichez un message clair « réessayez » plutôt qu'une erreur générique.

Chaque page de checkout doit fonctionner en HTTPS. Sans certificat SSL valide, les navigateurs affichent des avertissements « Non sécurisé », les fournisseurs de paiement refusent de charger les champs hébergés et Google pénalise votre classement. Les certificats gratuits de Let's Encrypt suffisent. Après l'installation du SSL, vérifiez que tout le trafic HTTP redirige vers HTTPS — le contenu mixte fera dysfonctionner les modules de paiement.

Mesurer les performances du checkout PrestaShop

Vous ne pouvez pas améliorer ce que vous ne mesurez pas. Comprendre les performances de votre checkout nécessite de suivre les bonnes métriques et de savoir ce que « bon » signifie.

Métriques clés

• Taux de complétion du checkout — (commandes finalisées / sessions de checkout) x 100. Votre métrique de checkout PrestaShop la plus importante.
• Taux d'abandon du checkout — le pourcentage de clients qui commencent le checkout mais ne le finissent pas. Cela isole les problèmes de checkout des simples visiteurs.
• Taux d'abandon par étape — quelle étape perd le plus de clients ? Si 40 % abandonnent à la livraison, vos options de transporteurs pourraient être le problème.
• Temps de complétion — des temps plus longs corrèlent directement avec des taux d'abandon plus élevés.
• Taux d'échec de paiement — des taux élevés indiquent des problèmes de configuration 3DS ou des règles anti-fraude trop agressives.

Suivi avec Google Analytics 4

Le suivi e-commerce amélioré GA4 est la méthode standard pour mesurer votre funnel de checkout PrestaShop. Installez un module GA4 qui déclenche des événements pour begin_checkout, add_shipping_info, add_payment_info et purchase. Configurez ensuite un rapport funnel dans GA4 > Explorer > Exploration de funnel avec des étapes correspondant à vos phases de checkout pour visualiser où les clients abandonnent.

Envisagez le suivi côté serveur pour des données plus précises — le suivi JavaScript côté client est bloqué par les bloqueurs de publicités pour 25 à 40 % des visiteurs. Une implémentation côté serveur du GA4 Measurement Protocol (déclenchée par les hooks PrestaShop à la création de commande) capture chaque commande indépendamment des bloqueurs côté client.

À quoi ressemble un « bon » taux de complétion

Benchmarks du secteur : la moyenne est de 45-55 %, bon est 55-65 %, et excellent est 65 %+ (typiquement atteint avec le one page checkout et les options de paiement express). Si votre taux est inférieur à 40 %, vérifiez la création de compte obligatoire, les frais de livraison inattendus, les options de paiement limitées ou les erreurs techniques. Ces benchmarks varient selon le secteur — les achats de valeur élevée ont naturellement des taux plus bas que la mode ou les produits de consommation.

Ce qui arrive : PrestaShop 9.2 et le one page checkout natif

PrestaShop a annoncé que la version 9.2 inclura une option de one page checkout natif. C'est un changement significatif — pour la première fois, les marchands pourront proposer un parcours de checkout en une seule page sans modules tiers.

Mises en garde importantes :

• Il ne fonctionnera qu'avec le thème Hummingbird v2 — les boutiques sur Classic ou d'autres thèmes n'y auront pas accès
• Il sera optionnel, pas le défaut — le parcours multi-étapes reste disponible
• Les auteurs de modules devront adapter leurs modules de paiement et de livraison pour fonctionner dans le nouveau parcours
• Il n'y a pas encore de date de sortie confirmée, et les releases PrestaShop ont historiquement pris du retard par rapport aux calendriers initiaux

Devriez-vous attendre ? Cela dépend de votre calendrier. Si vous lancez une nouvelle boutique aujourd'hui, attendre des mois (ou plus) pour une fonctionnalité qui pourrait nécessiter une migration de thème complète est impraticable. Si vous êtes déjà sur Hummingbird et planifiez une mise à jour future, cela vaut la peine de suivre. Nous couvrons cette décision en détail dans notre article sur les plans OPC natif de PrestaShop.

Choisir le bon checkout pour votre boutique

Il n'existe pas de « meilleure » configuration de checkout PrestaShop unique — cela dépend de votre marché, budget, confort technique et plans de croissance. Voici un cadre pratique :

• Vous démarrez, petit budget — utilisez le checkout multi-étapes par défaut avec ps_checkout. C'est gratuit, ça fonctionne, et vous pourrez améliorer plus tard.
• Boutique établie, taux d'abandon élevé — investissez dans un module one page checkout. L'augmentation de conversion se rentabilise typiquement en quelques semaines.
• Trafic fortement mobile — priorisez l'express checkout avec les paiements par portefeuille (Apple Pay, Google Pay). Les clients mobiles abandonnent les formulaires à des taux bien plus élevés que sur desktop.
• Vente à travers l'Europe — considérez Mollie pour les modes de paiement locaux, ou Stripe pour une couverture internationale plus large.
• Boutique à fort volume — passez à une intégration de paiement directe (Stripe, Adyen) où vous avez un contrôle total sur les règlements, les rapports et la gestion des litiges. Le modèle d'intermédiaire ps_checkout ajoute de la complexité à grande échelle.
• Entreprise avec besoins omnicanaux — évaluez Adyen pour des paiements unifiés en ligne et en magasin via une seule plateforme.
• Tout dans un seul module — regardez les solutions qui combinent l'optimisation du parcours de checkout avec le traitement des paiements, plutôt que de superposer plusieurs modules qui pourraient entrer en conflit.

Quel que soit votre choix, testez votre checkout PrestaShop régulièrement. Passez des commandes test sur différents appareils, essayez différents modes de paiement, appliquez des codes de réduction et vérifiez comment le parcours gère les erreurs. Votre checkout est là où le chiffre d'affaires se réalise — il mérite plus d'attention que la plupart des marchands ne lui en accordent.