PrestaShop checkout : processus, module et meilleures options

“PrestaShop checkout” veut dire deux choses différentes — clarifions

La moitié des demandes que nous recevons sur “checkout” parlent en réalité de deux choses différentes. Il y a le processus de checkout, le flux multi-étapes intégré à chaque boutique PrestaShop, et ps_checkout, un module de paiement précis développé par PrestaShop SA avec PayPal. Les noms se ressemblent, mais remplacer l’un ne remplace pas l’autre.

Nous développons Checkout Revolution depuis 2018 parce que le checkout natif ne suffisait pas à nos clients : paniers vidés à l’étape paiement, “no payment method available” avec plusieurs modules actifs, redirections 3DS en 404. Cet article est le guide que nous aurions aimé avoir au départ.

Comment fonctionne le processus de checkout PrestaShop

Le flux multi-étapes par défaut

Chaque boutique PrestaShop suit la même logique de base :

1. Résumé panier — produits, quantités, totaux
2. Informations personnelles — connexion, inscription ou invité
3. Adresse — livraison et facturation
4. Livraison — transporteur selon adresse, poids et dimensions
5. Paiement — méthode de paiement et confirmation

Après paiement, le client arrive sur la page de confirmation. C’est la base héritée par les thèmes et utilisée par les modules de paiement. C’est aussi la friction que l’on cherche à réduire.

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

Cette planche vient d’un parcours réel sur ps9.dev.mypresta.rocks : produit ajouté, invité, adresse, transporteur, étape paiement. Quand le prestataire échoue au dernier écran, les étapes précédentes peuvent rester saines.

Ce qui a changé entre 1.7 et 8/9

Le flux reste similaire, mais la plomberie a beaucoup évolué.

• Architecture thème. Classic garde beaucoup de jQuery et AJAX par étape ; Hummingbird modernise le front.
• Hooks paiement. paymentOptions remplace displayPayment/displayPaymentEU. Sur 8/9, un module encore sur les anciens hooks peut devenir invisible.
• Migration Symfony. La gestion de commandes back office est Symfony ; le OrderController front reste legacy.
• CSP plus strict sur 8+. Des headers Content Security Policy peuvent bloquer le JavaScript des prestataires.
• PHP 8.1+ sur PS 9. Les modules écrits avec des hypothèses PHP 7 cassent plus vite.

OrderController et déclenchement du flux

Le checkout passe par controllers/front/OrderController.php. Il charge le panier, lance les hooks et traverse un objet CheckoutProcess composé d’étapes comme CheckoutAddressesStep, CheckoutDeliveryStep et CheckoutPaymentStep, héritées de AbstractCheckoutStep.

Cette architecture est bien pensée, mais pas toujours simple à déboguer. Quand cinq modules touchent cinq étapes, il faut lire le flux complet.

Ce qui se passe à chaque étape

Validation et hooks s’enchaînent derrière chaque écran :

• Validation adresse. Champs requis, pays/état, recalcul des taxes.
• Sélection transporteur. Zone, poids, dimensions, restrictions ; actionCarrierProcess permet d’intervenir.
• Rendu paiement. Les modules actifs renvoient leurs options via paymentOptions.
• Validation commande. actionValidateOrder déclenche paiement, stock, emails et lignes commande.

C’est extensible, mais deux modules mal écrits peuvent se perturber et laisser seulement var/logs/ comme piste.

Pourquoi votre checkout est lent

Un checkout lent coûte des ventes. Les causes fréquentes :

• Trop de modules sur les hooks checkout. Chaque module ajoute des millisecondes.
• Appels API externes. Transporteurs, taxes, validation adresse peuvent bloquer le rendu.
• Configuration transporteur excessive. Trop de règles zone/poids créent des requêtes longues.
• Trop de règles panier. Les règles expirées doivent être supprimées, pas seulement désactivées.
• Index manquants. Tables cart-rule et specific-price énormes sur les vieilles boutiques.
• Pas d’OPcache, pas de Redis. Le reste ne compense pas une base runtime faible.

Sur staging, activez le profiler :

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

Ne laissez jamais cela en production. Le module le plus lent est souvent visible directement.

Les erreurs checkout les plus fréquentes

“No payment method available.” Aucun module n’a renvoyé d’option via paymentOptions. Causes courantes :

• Restriction devise ou pays
• Payment > Preferences exclut transporteur, pays ou groupe client
• Erreur PHP silencieuse dans le module — voir var/logs/
• CSP bloque le JavaScript du module sur PS 8+

Souvent une incompatibilité de configuration, pas un problème de thème.

Dans cette capture PS9, panier, adresse et transporteur fonctionnent, mais l’étape paiement revient vide. La matrice back office montrait que les modules étaient limités à un autre pays que le panier France de test.

Payment > Preferences est le premier endroit à regarder.

Devise, groupe client, pays et transporteur décident si un module apparaît. Un module installé peut rester invisible si une restriction exclut le panier.

“An error occurred while processing your order.” Message générique : commencez par les logs PHP et PrestaShop, puis vérifiez stock et conflits de règles panier.

Panier vidé au checkout. Problème de cookie ou session : SSL, domaines shop/SSL, partition de session ou module qui réinitialise le panier.

Échecs validation adresse. État obligatoire invisible, format adresse mal configuré ou regex code postal trop stricte. Voir International > Locations > Countries.

Échecs redirection 3DS. Retour HTTP au lieu de HTTPS, session expirée, callback inaccessible ou domaine différent.

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

Règles panier, vouchers et prix spécifiques interagissent parfois de façon peu intuitive.

• Cart rules évaluées par priorité.
• Specific prices appliqués avant les règles panier.
• Restrictions de cumul parfois difficiles à prévoir en multi-devise.

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

La liste back office montre priorité, code, quantité, expiration et statut. Quand une remise agit bizarrement, nous commençons ici.

Règles de livraison gratuite et transporteurs

Une règle “free shipping” ne rend pas forcément tous les transporteurs gratuits. Les restrictions transporteur, pays et zone décident où elle s’applique.

Le piège priorité et cumul

Cas classique :

• Rule A (priority 1): 20% off entire cart, non-combinable
• Rule B (priority 2): Free shipping over 50 EUR

Comme Rule A est non combinable et prioritaire, Rule B ne s’applique pas. Le client obtient 20% mais paie la livraison.

Autre cas : un voucher de 10 EUR est refusé parce qu’une remise automatique de 15% non combinable existe déjà. Le message “not valid” n’aide personne.

Montant minimum sur les règles panier

Le minimum peut inclure ou non taxes et livraison, avant ou après remises. Testez avec de vrais paniers et pays avant mise en ligne.

Guest checkout vs création de compte

Guest checkout est un réglage commande, pas un réglage paiement — Shop Parameters > Order Settings sur PS 8. En B2C, nous l’activons presque toujours ; en B2B, le compte peut rester justifié.

Guest checkout vit dans Order Settings.

Le toggle Enable guest checkout change la première étape avant même que transporteurs et modules de paiement interviennent.

Le module ps_checkout — ce qu’il est vraiment

Ce que ps_checkout fait, et ne fait pas

PrestaShop Checkout, nom technique ps_checkout, est un module de paiement gratuit développé par PrestaShop SA et PayPal, préinstallé depuis PrestaShop 1.7.5.

ps_checkout est un module de paiement, pas le flux checkout. Il ne change ni étapes, ni layout, ni ordre des champs. Il affiche seulement des moyens de paiement à l’étape paiement.

Ce qu’il propose

• Paiement carte via champs hébergés PayPal
• Wallet PayPal
• Apple Pay et Google Pay selon disponibilité
• Méthodes locales — iDEAL, Bancontact, BLIK, selon marché
• Pay Later / Pay in 3-4
• 3DS2
• 20+ devises via le réseau PayPal

Source : dépôt GitHub ps_checkout.

Frais de transaction

Le module est gratuit, le processing ne l’est pas. Les frais varient par pays marchand, type de carte, devise, volume et risque.

Références prix, vérifiées en mai 2026 : Stripe France, Mollie, Adyen, PayPal UK.

Comparer les prestataires — les frais ne suffisent pas

Un écart de 0,3 EUR par commande ne compense pas une méthode locale absente. Taux d’autorisation, couverture locale, remboursements, support et lisibilité back office comptent autant.

ps_checkout vs Stripe vs Mollie en bref

Installer et configurer ps_checkout

Installez le module, liez un compte PrestaShop Addons, connectez PayPal Business via l’assistant, choisissez les méthodes, vérifiez arrondis/devises et testez en sandbox.

La configuration combine onboarding compte et réglages paiement.

Module installé ne veut pas dire paiement prêt. Compte PrestaShop lié, PayPal Business associé, arrondis compatibles et test confirmé : seulement là, c’est fini.

Désinstaller ps_checkout

Modules > Module Manager, trouvez ps_checkout, Disable d’abord, puis Uninstall si nécessaire. Configurez un autre module avant, sinon le checkout affichera “No payment method available”.

L’architecture intermédiaire

Stripe, Mollie et Adyen versent directement sur votre compte marchand. ps_checkout passe par le compte plateforme PayPal de PrestaShop SA : PrestaShop SA agit comme facilitateur.

• Vous liez PayPal Business via le flux PrestaShop
• Le timing de règlement dépend de PayPal et de la configuration plateforme
• Les litiges passent par une couche supplémentaire
• Les données brutes de transaction sont moins visibles

Ce n’est pas forcément mauvais, mais les marchands à volume ou régulés doivent le savoir.

Les limites que nous voyons souvent

• Compatibilité thème. Meilleur sur Classic ; les thèmes très custom cassent parfois les champs hébergés.
• Spinner infini. Conflit JavaScript ou CSP bloquant PayPal.
• Erreurs 3DS peu utiles. Le client abandonne au lieu de réessayer.
• Pas de support direct fort. Douloureux pendant une panne paiement.
• Risque d’upgrade. Testez chaque mise à jour en staging.

Quand ps_checkout a du sens

• Nouvelles boutiques qui doivent encaisser vite
• Marché unique sans complexité multi-devise
• Budget serré, paiement à la transaction
• Catalogues simples, sans abonnements ni workflows exotiques

Personnaliser le checkout PrestaShop

Ce que vous pouvez changer sans module

• Templates thème. Layout, ordre des champs, contenu entre étapes.
• CSS. Couleurs, espacements, boutons.
• Transporteurs. Noms, descriptions, délais, ordre.
• Ordre des paiements. Payment > Preferences.
• Champs requis. Customers > Addresses.

Ces changements sont sûrs avec un child theme. Notre guide d’optimisation checkout va plus loin.

Le format d’adresse est intégré à PrestaShop.

L’éditeur pays contrôle les champs et leur ordre. La livraison pilote validation, taxes et transporteurs.

Champs checkout personnalisés

Beaucoup de marchands ont besoin de champs que PrestaShop ne collecte pas : mobile SMS, TVA B2B, digicode, instructions livraison, référence PO. Utilisez un module custom via actionValidateOrder ou un module de champs checkout Addons.

Traduire le checkout

Un checkout en anglais sur une boutique française perd des commandes.

• Libellés d’étapes. International > Translations > Front office translations.
• Chaînes des modules paiement. Chaque module a ses propres traductions.
• Messages d’erreur. Ceux qui apparaissent au pire moment.
• Conditions générales. Page CMS disponible dans chaque langue.
• Libellés adresse. Formats adaptés au pays.

Piège classique : installer un pack langue ne traduit pas forcément les modules.

Cherchez la chaîne checkout, puis éditez le domaine thème.

Le même workflow s’applique aux labels, boutons et messages front office.

One page checkout

La personnalisation la plus demandée : adresse, livraison et paiement visibles sur une seule page, avec total mis à jour en AJAX et validation inline.

Le gain varie selon trafic, mobile, transporteurs, méthodes de paiement et champs requis. Mesurez, ne croyez pas un pourcentage universel.

Du point de vue UX, c’est plus calme : tous les champs visibles, résumé persistant, moins de navigation.

PrestaShop n’a pas encore de one page checkout natif généralisé. La roadmap annonce PrestaShop 9.2 avec Hummingbird v2, mais ce sera optionnel.

C’est le terrain de Checkout Revolution, que nous avons construit parce que les alternatives étaient datées ou fragiles.

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

À gauche, le multi-step PrestaShop 9 ; à droite, Checkout Revolution avec contact, livraison, paiement et résumé visibles.

Express checkout — encore autre chose

Express checkout n’est pas one-page checkout. One page checkout remplace le flux multi-étapes ; express checkout ajoute des boutons wallet (Apple Pay, Google Pay, PayPal Express, Link) sur produit ou panier pour sauter le checkout.

Sur mobile, c’est souvent l’amélioration la plus forte. Nous le vendons séparément : Express Checkout. Pour avoir wallet buttons et one-page checkout : Checkout Revolution.

Express checkout commence avant la page panier.

Selon prestataire, navigateur, pays et éligibilité wallet, le bouton visible peut être générique ou Apple Pay, Google Pay, PayPal ou BNPL.

Checkout embarqué et modal

Plus rare : le formulaire de paiement apparaît en modal ou inline. Stripe Payment Element et PayPal in-context le permettent. La distance psychologique entre “je veux” et “j’ai acheté” diminue.

Alternatives à ps_checkout

Si ps_checkout ne convient pas, plusieurs options matures existent.

Stripe

Stripe Payment Element est l’intégration paiement la plus développeur-friendly. Nous l’utilisons dans Checkout Revolution pour sa couverture et son API.

• Compte marchand direct
• 135+ devises, FX automatique
• Apple Pay, Google Pay, Link, 40+ méthodes locales
• Excellente documentation API
• Stripe Radar contre la fraude

Idéal pour : boutiques internationales, équipes techniques, contrôle des données paiement.

Mollie

Prestataire européen fort aux Pays-Bas, Belgique, Allemagne et France.

• Tarif par transaction, pas d’abonnement
• iDEAL, Bancontact, SOFORT, EPS, Giropay, KBC/CBC
• Module PrestaShop maintenu par Mollie
• Onboarding rapide

Idéal pour : boutiques UE, surtout Benelux ou DACH.

Buy now, pay later : Klarna, Alma, Clearpay/Afterpay

Le BNPL vaut le coup quand le panier est assez élevé pour que le fractionnement change la décision d’achat.

• Klarna — DACH, Nordics, UK, Europe large.
• Alma — fort en France et Europe du Sud sur paniers élevés.
• Clearpay/Afterpay — marchés Afterpay, UK sous Clearpay.

Les frais sont plus élevés et la gestion litiges/remboursements plus lourde.

Méthodes locales par marché

En Europe, la couverture locale compte autant que le prix carte.

Support actuel : méthodes Stripe, méthodes Mollie et dépréciation Giropay.

Adyen

Option enterprise : 250+ méthodes, routing intelligent, RevenueProtect, acquiring direct. Plus complexe, mais souvent pertinent à gros volume.

Amazon Pay

Le client utilise son compte Amazon, adresse et paiement inclus. Bon en option secondaire, moins en méthode principale.

Module PayPal standalone

Pour PayPal sans couche PrestaShop SA, un module direct se connecte à votre compte PayPal Business. Vous gardez plus de contrôle sur règlement et litiges.

Idéal pour : marchands qui veulent PayPal avec relation directe PayPal.

Bank transfer — l’option zéro frais oubliée

Le module natif ps_wirepayment affiche vos coordonnées bancaires. Utile en B2B, commandes sur mesure, wholesale ou paniers élevés, au prix d’un rapprochement manuel.

Référence : PrestaShop ps_wirepayment.

Checkout Revolution (oui, le nôtre)

Checkout Revolution combine one-page checkout et boutons express dans un module Stripe-powered. Apple Pay, Google Pay, PayPal, Link, cartes et 30+ méthodes via Stripe Payment Element, avec paiement direct vers votre compte Stripe.

Nous l’avons construit pour éviter d’empiler trois ou quatre modules. Si vous voulez one-page checkout, express buttons et stack paiement moderne chez un seul vendeur, c’est notre recommandation.

Comparaison rapide

Sécurité checkout et conformité PCI

Ne sautez pas cette partie : une fuite de paiement coûte clients, argent et visibilité.

Ce que PCI DSS signifie pour votre boutique

• SAQ A. Champs hébergés ou redirection ; la carte ne touche jamais votre serveur.
• SAQ A-EP. JavaScript prestataire sur votre page ; charge un peu plus lourde.
• SAQ D. La carte passe par votre serveur. À éviter presque toujours.

Confirmez le SAQ exact avec votre prestataire ou acquirer.

Champs hébergés, pas inputs carte bruts

Les champs hébergés sont des iframes du prestataire. Le numéro de carte semble dans votre formulaire mais ne touche pas votre serveur. Si un module demande des inputs carte HTML bruts, refusez.

SCA, 3DS2 et SSL

En UE, SCA impose 3DS2 pour la plupart des paiements carte. Votre module doit le supporter, avec des erreurs compréhensibles. Le checkout doit aussi être HTTPS, sans mixed content.

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

Le checkout doit charger en sécurité avant que les champs hébergés soient fiables.

Mesurer la performance checkout

On n’améliore pas ce qu’on ne mesure pas.

Métriques clés

• Taux de complétion checkout — commandes / sessions checkout.
• Taux d’abandon checkout — clients qui commencent sans finir.
• Drop-off par étape — où les clients partent.
• Temps de complétion — plus long signifie souvent plus d’abandon.
• Taux d’échec paiement — 3DS, fraude ou config.

A/B tester les changements checkout

Comparez à votre baseline avec trafic comparable : complétion, échecs paiement, AOV et tickets support.

GA4 enhanced ecommerce

Mesurez begin_checkout, add_shipping_info, add_payment_info et purchase. Pour revenus critiques, préférez aussi du server-side via Measurement Protocol.

À quoi ressemble un “bon” taux ?

Il n’y a pas de chiffre universel. Construisez votre baseline, puis surveillez les variations : création de compte forcée, frais livraison surprise, méthodes absentes, validation adresse et erreurs paiement.

À venir : one-page checkout natif en 9.2

La roadmap PrestaShop liste 9.2 pour Q2-Q3 2026 avec un one-page checkout natif.

• Hummingbird v2 seulement.
• Optionnel, pas par défaut.
• Les modules paiement/livraison devront s’adapter.
• Une roadmap n’est pas une date de sortie.

Faut-il attendre ? Pas si vous lancez aujourd’hui. Notre analyse est dans les plans OPC natifs PrestaShop.

Choisir le bon checkout pour votre boutique

• Début, budget serré. Multi-step natif + ps_checkout.
• Boutique établie, abandon élevé. Module one page checkout.
• Trafic mobile fort. Express checkout avec Apple Pay et Google Pay.
• Vente en Europe. Mollie pour méthodes locales ou Stripe pour couverture large.
• Gros volume. Stripe ou Adyen en direct.
• Enterprise / omnicanal. Adyen.
• Tout chez un seul vendeur. Module combinant optimisation du flux et paiement.

Quel que soit le choix, testez : appareils, méthodes, codes promo, cas d’erreur. Le checkout est l’endroit où le revenu se décide.

Lectures liées

• Guide d’optimisation du checkout PrestaShop — changements concrets qui améliorent la complétion
• PrestaShop 9.2 Native One Page Checkout — notre lecture de la roadmap
• Checkout Revolution — notre module one-page + express
• Express Checkout — boutons wallet sans remplacer votre checkout
• PrestaShop Hooks & Overrides — les hooks checkout et comment s’y brancher proprement