Commande PrestaShop : configuration, paiements et diagnostic

Ce que nous ferions

La modification utile dépend de la boutique existante : sa version de PrestaShop, son thème, ses modules de paiement et de transport, son code de commande sur mesure, ainsi que les intégrations de stock, de comptabilité ou de livraison qui reçoivent ses commandes. Établissez quelles données client, adresse et commande chacune de ces intégrations reçoit. Nous suivrions un achat qui échoue, du panier à la confirmation de commande, sur cette combinaison exacte, en tant que nouveau visiteur et en tant que client connu. Comparez chaque restriction avec la règle voulue par la boutique avant de la traiter comme une anomalie, puis corrigez d’abord les erreurs de configuration ou d’intégration avérées. Modifiez la présentation lorsque les preuves désignent des champs ou une navigation déroutants ; modifiez l’intégration de paiement lorsqu’il manque un moyen ou une opération de paiement nécessaire.

Pour les modifications de configuration et de modules du tunnel de commande : reproduisez le problème sur une copie de préproduction de la boutique, isolée des vrais paiements, des emails clients et de l’expédition ; modifiez une seule couche à la fois ; répétez des scénarios d’achat écrits ; puis basculez à une heure planifiée, avec une sauvegarde des fichiers et de la base, un moyen de retour testé et un plan de rapprochement des commandes passées entre-temps. Un tunnel de commande qui répond déjà au besoin reste tel quel. Si les travaux sur le tunnel de commande s’inscrivent dans une reconstruction plus large de la boutique, le parcours sûr habituel est une boutique cible propre en préproduction, une migration répétée des données nécessaires et une bascule planifiée après avoir testé les modules et les intégrations.

Si la cause des commandes perdues n’est pas claire, le PrestaShop B2C Conversion & Revenue Audit examine la découverte des produits, le panier, le tunnel de commande, le paiement et la confirmation, en commençant sur téléphone, et fournit un plan de corrections classé par priorité sans rien installer ni modifier ; la mise en œuvre est distincte.

Comprendre le parcours de commande

Dans PrestaShop 1.7.8 et 9.1, le contrôleur de commande construit quatre étapes logiques : informations personnelles, adresses, livraison et paiement. Un panier exclusivement virtuel omet la livraison. La vérification du panier et la confirmation de commande sont des parties distinctes du parcours. Une seule URL de commande peut contenir plusieurs étapes, requêtes et transferts au prestataire de paiement.

Un client qui revient peut déjà avoir des informations enregistrées. Un thème ou module de commande peut modifier la présentation. Comptez les navigations de documents et les requêtes en arrière-plan dans le navigateur avant de décrire votre commande comme un parcours de quatre ou cinq pages.

PrestaShop 9.2 inclut le module natif ps_onepagecheckout. Il doit être activé et configuré pour que son parcours unifié devienne actif. Le parcours par étapes reste disponible. La documentation actuelle de la commande native explique l'intégration.

Gardez quatre choix distincts : la présentation du tunnel de commande, l’intégration de paiement, le compte chez le prestataire qui se trouve derrière, et la façon dont vous mesurez le parcours.

Consignez la version de PrestaShop installée, la version de PHP, le thème et les versions des modules de commande et de paiement avant de suivre la moindre instruction, et vérifiez ce que ces versions exactes prennent en charge. Évaluez ensemble les options natives du tunnel de commande et les modules tiers ; une ancienne feuille de route n’est pas un guide de configuration.

Associer le symptôme à la prochaine action

Avant de modifier quoi que ce soit

1. Tentez le même achat sur un téléphone, en tant que nouveau visiteur et en tant que client connu. Notez les endroits où des informations doivent être saisies à nouveau ou où une erreur laisse l’action suivante floue.
2. Distinguez la navigation des décisions non résolues. Des frais de livraison annoncés tard, un transporteur inadapté ou un moyen de paiement manquant exigent leur propre correction, même sur une seule page.
3. Rédigez un scénario d’acceptation pour l’obstacle : type de client, panier, destination, moyen de paiement et résultat attendu. Utilisez-le pour comparer le tunnel de commande actuel à toute alternative proposée.

Par exemple, une option de paiement peut apparaître pour un client particulier national, puis disparaître lorsque l’acheteur choisit un autre pays, se connecte à un compte professionnel ou sélectionne un transporteur particulier. Comparez ce contexte de panier avec les règles de paiement voulues avant d’accuser la présentation. Un moyen activé dans le tableau de bord du prestataire peut rester indisponible via l’intégration installée.

Lorsque l’intégration utilise les deux, le retour du navigateur après l’authentification bancaire et la notification serveur du prestataire sont des sources de preuve distinctes. Une page de retour défaillante ne prouve pas que le paiement a échoué, et l’absence de page de confirmation ne prouve pas qu’aucune commande n’existe. Comparez le statut, le montant, la devise et la référence chez le prestataire avec l’enregistrement de la boutique ; les paiements autorisés, en attente, capturés et finalisés peuvent nécessiter des traitements différents.

Un rapport de support utile contient le panier, le type et le groupe du client, le marché et la devise, l’appareil, l’heure de l’échec avec le fuseau horaire, la référence du panier ou de la commande, une référence de transaction du prestataire masquée, les étapes de reproduction et le message exact. Demandez au développeur de corréler les preuves du navigateur et du serveur. Retirez identifiants, données de paiement et données clients inutiles avant de partager des journaux ou des captures d’écran.

Choisir un tunnel de commande après avoir défini le manque

Conservez le parcours natif installé s’il répond au besoin, et conservez une intégration de paiement existante si elle fournit les moyens et le traitement des commandes dont vous avez besoin. N’achetez pas un module parce que son nom paraît plus rapide : une seule page peut encore contenir toutes les décisions nécessaires, et un portefeuille peut réduire la saisie sans régler la livraison ni les options produit.

Checkout Revolution regroupe coordonnées, adresse, livraison, paiement, bons de réduction et récapitulatif de commande sur une seule page, en une, deux ou trois colonnes, avec l’ordre des sections de votre choix et le choix des champs affichés ou obligatoires. Vos transporteurs et moyens de paiement existants y apparaissent, un client connu ne ressaisit pas son adresse, les règles de paiement peuvent dépendre de la boutique, de la langue, du groupe de clients, du pays, de l’appareil et du montant de la commande, et le devis accepté d’un acheteur professionnel peut devenir une commande sans nouvelle saisie. Il inclut aussi une fenêtre d’achat express sur les pages produit, les listes de produits et le panier.

Express Checkout réunit adresse, livraison, paiement et confirmation dans une seule fenêtre sur les pages produit, les listes de produits ou le panier. Les paiements passent par Stripe, sans abonnement mensuel et avec une commission par transaction, pour les cartes, les portefeuilles et les moyens locaux ; comparez ces conditions séparément de la question de savoir si son parcours convient à la boutique. Vous choisissez l’emplacement des boutons, les champs d’adresse obligatoires et l’éligibilité des paiements par public, pays et devise. Les frais de livraison se mettent à jour en direct, les combinaisons paiement et transporteur exclues sont refusées, et les remboursements complets ou partiels se font depuis l’écran de la commande. Un tunnel de commande sur une page, en option, intègre vos autres modules de paiement et de livraison.

Dans les deux cas, un paiement finalisé après la fermeture du navigateur devient tout de même une commande. Aucune des deux fiches produit ne promet de cartes enregistrées ni ne nomme un portefeuille précis comme Apple Pay ou Google Pay : vérifiez donc un tel besoin avec la version et votre compte de paiement avant d’acheter. Aucun nom de produit ne garantit la compatibilité avec votre code sur mesure : incluez dans le besoin les overrides du tunnel de commande, les champs supplémentaires, les intégrations de stock ou de comptabilité et les règles B2B.

Si le choix doit être testé, le PrestaShop Module Selection & Fit Assessment compare réglages natifs, produits déjà achetés, fournisseurs et développement sur mesure pour un besoin donné, teste les candidats sur une copie maîtrisée de la boutique et inclut la configuration, l’adaptation visuelle et le déploiement d’un module prêt à l’emploi retenu ; les licences sont facturées en sus et le développement sur mesure fait l’objet d’un devis séparé. Si vous possédez déjà le module retenu, le PrestaShop Module Installation & Configuration Service installe et configure un module existant selon un périmètre convenu et vérifie le parcours concerné ; les licences, les modules supplémentaires et le développement sont facturés séparément.

Choisir une commande par étapes, sur une page ou intégrée

PrestaShop 1.6 avait un réglage de type de processus de commande. Le parcours reconstruit de 1.7 n'utilisait pas cet ancien interrupteur. En 1.7, 8 et 9.0/9.1, une autre présentation complète nécessite un module adapté ou une implémentation personnalisée. PrestaShop 9.2 fournit un OPC natif : évaluez cette option disponible avant de commander un remplacement.

L'OPC natif n'est pas strictement réservé à Hummingbird. Les thèmes dérivés de Classic et les thèmes personnalisés peuvent respecter son contrat de modèles et JavaScript. Suivez le guide de compatibilité des thèmes et testez votre combinaison installée.

Les achats professionnels complexes, les produits réglementés, la personnalisation et plusieurs choix de livraison peuvent gagner à un regroupement réfléchi. Les commandes simples peuvent convenir à une vue unifiée. Pour un article de grande valeur, comme une montre à 2 000 €, rendez la vérification finale claire. Choisissez la présentation selon vos besoins de commande et vos tests d’utilisabilité : l’objectif utile est d’avoir moins d’étapes inutiles tout en gardant la commande correcte visible pour vérification, pas de réduire le nombre de pages.

Checkout Revolution met en œuvre un tunnel de commande sur une page ainsi que des parcours express et en fenêtre modale ; consultez l’aide de Checkout Revolution. Vérifiez le récapitulatif de commande et les boutons de validation sur ordinateur et sur mobile.

Éviter les modifications du cœur peut réduire la maintenance sans garantir la compatibilité future. Versionnez les changements de thème enfant et testez les mises à jour avec vos modules de transport et de paiement.

Mesurer les événements et diagnostiquer l'abandon

Consignez le passage du panier à la commande, la finalisation de la commande, les échecs de paiement, le temps de finalisation et le montant de la commande. Définissez si la finalisation signifie une commande créée ou un paiement confirmé. Utilisez la même définition tout au long d’une comparaison et enregistrez avec elle les parcours normaux, express et redirigés, afin qu’un parcours par portefeuille ou en fenêtre modale ne manque pas dans les totaux. Ventilez les résultats par appareil, type de client, pays et moyen de paiement lorsque le volume le permet.

Ce sont des événements e-commerce Google, et non un événement par étape native de l'interface. Pour distinguer abandon des informations personnelles et abandon de l'adresse, enregistrez explicitement vues d'étape, soumissions, résultats de validation et événements de finalisation. N'envoyez pas de noms, adresses e-mail, adresses ou détails de paiement aux outils d'analyse.

Vérifiez chaque événement dans les outils de débogage de votre navigateur et de votre outil d’analyse, y compris l’envoi des informations de livraison et de paiement, les paniers virtuels et les nouvelles tentatives. Pour l’intégration Google Analytics GA4, consultez l’aide du module.

Utilisez retours clients, enregistrements de session masqués respectant le consentement et erreurs navigateur pour examiner une baisse. Une sortie à l'étape livraison peut concerner le coût, l'absence de transporteur, les délais ou un défaut technique. La position dans l'entonnoir ne prouve pas le motif du client. Priorisez les défaillances confirmées et les possibilités selon le trafic touché, le coût et l'effet attendu.

Les enquêtes sur les raisons d’abandon peuvent suggérer des pistes. Elles ne mesurent pas votre entonnoir PrestaShop et ne prédisent pas le gain d’une modification, et il n’existe ni taux de finalisation cible universel ni délai de retour sur investissement : comparez à votre propre référence. Choisissez un protocole de comparaison et une taille d’échantillon selon votre référence, l’effet que vous devez détecter et la variabilité du trafic. Maîtrisez les promotions, la saisonnalité et la composition du trafic. L’adoption d’un portefeuille sans évolution de la conversion globale ne prouve pas une cannibalisation.

À titre d'illustration, passer de 30 % à 31 % de finalisation est une hausse relative d'environ 3,33 %. Le chiffre d'affaires évolue dans la même proportion uniquement si le volume d'entrées en commande et le panier moyen restent constants. Ce calcul n'est pas une prévision.

Utiliser les paniers enregistrés sans inventer d'entonnoir

PrestaShop conserve les paniers. Commandes > Paniers vous permet de les examiner, mais une ligne de panier ne prouve pas l'entrée dans le parcours de commande. Choisissez le bon préfixe de table et le bon ID boutique. Cet exemple en lecture seule compte les paniers récemment créés et actuellement non vides, ainsi que le sous-ensemble lié à une commande actuellement valide.

SELECT COUNT(*) AS nonempty_carts,
       SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) AS carts_with_valid_order,
       ROUND(100.0 * SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) / NULLIF(COUNT(*), 0), 1) AS cohort_ratio_pct
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart);

C'est un ratio de cohorte entre paniers non vides et commandes actuellement valides. Ce n'est pas le taux de conversion du parcours de commande. Les paniers récents ont eu moins de temps pour convertir, les commandes en attente peuvent devenir valides plus tard et un panier peut créer plusieurs commandes. EXISTS évite de compter plusieurs fois un panier.

Définissez l'abandon avec un seuil d'inactivité et une politique concernant les commandes. Ce second exemple utilise 24 heures sans mise à jour du panier comme seuil illustratif et exclut chaque panier associé à une commande, y compris impayée.

SELECT CASE
         WHEN c.id_carrier > 0 THEN '3 - carrier value stored'
         WHEN c.id_address_delivery > 0 THEN '2 - delivery address stored'
         ELSE '1 - neither value stored'
       END AS stored_state,
       COUNT(*) AS inactive_nonempty_carts
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 24 HOUR)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart)
  AND NOT EXISTS (SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart)
GROUP BY stored_state
ORDER BY stored_state;

Lisez les libellés d'état littéralement. Les adresses et transporteurs enregistrés peuvent avoir été restaurés ou attribués automatiquement ; ce ne sont que des indices heuristiques. Cette requête ne distingue pas recherche, interruption, trafic de robots ou échec de commande. Appliquez vos exclusions documentées de robots et rapprochez les résultats des événements. Suivez séparément la relance des commandes impayées si c'est votre objectif.

Configurer la commande invité et les champs du compte

1. Ouvrez Paramètres de la boutique > Commandes et examinez Activer la commande express. Sur les versions modernes, ce réglage correspond à PS_GUEST_CHECKOUT_ENABLED. Enregistrez via le back-office dans le contexte boutique voulu.
2. Testez une nouvelle session invité et un compte existant. Dans le parcours natif, la commande invité rend le mot de passe facultatif. La connexion reste disponible.
3. Examinez séparément la date de naissance, les civilités et les champs client supplémentaires. Le mode B2B contrôle certains champs de compte client ; il ne supprime pas systématiquement les champs société ou VAT des adresses.
4. Examinez format d'adresse, code postal et obligations de renseigner un État pour chaque pays desservi dans International > Zones géographiques > Pays. Les exigences des adresses et transporteurs doivent correspondre à l'expédition.

Vous pouvez inspecter les lignes de configuration sans les modifier :

SELECT id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name = 'PS_GUEST_CHECKOUT_ENABLED';

Une adresse e-mail de commande n'autorise pas le marketing. Recueillez un consentement distinct et approprié. Le suivi de commande peut utiliser le parcours natif de suivi invité. La conversion native d'un invité est un processus explicite ; activer la commande invité n'installe pas d'inscription automatique après achat. Testez le traitement d'une adresse e-mail de compte existant plutôt que de promettre des comptes en double ou un acheminement automatique des e-mails.

Les comptes peuvent servir à un accès B2B restreint, à la gestion de services récurrents et aux programmes de fidélité. Décidez à partir de ces besoins : pour la vente aux particuliers, testez si exiger un compte crée un obstacle évitable ; pour la vente aux professionnels, établissez quels acheteurs doivent disposer d’un compte validé ou de coordonnées d’entreprise. Changer de prestataire de paiement ne tranche pas ces règles de compte. Les téléchargements natifs de produits virtuels peuvent utiliser des liens invités protégés ; vendre un produit téléchargeable n’impose pas en soi la connexion à un compte enregistré.

Gardez les adresses de livraison et de facturation modifiables indépendamment. Demandez un numéro de téléphone lorsque votre service de livraison en a besoin. Préservez les caractères internationaux valides et expliquez les erreurs de champ sans effacer les champs déjà remplis. Avant de supprimer un champ obligatoire qui pose problème aux clients, établissez pourquoi il est obligatoire.

Testez les libellés et les erreurs dans chaque langue de la boutique, y compris les messages des modules de paiement, les champs d’adresse propres à chaque pays et les liens vers les conditions. Un thème traduit ne prouve pas que chaque message de module ou de prestataire est traduit : lorsqu’un tunnel de commande en français affiche une erreur d’adresse en anglais, déterminez si elle vient du thème, d’un module ou du prestataire avant de décider où la traduire. Un champ État obligatoire invisible ou une erreur de code postal peu claire peut bloquer un achat avant même le paiement. Le guide des traductions et de la vente à l’international couvre la configuration linguistique dans son ensemble.

Les tests de checkout à grande échelle du Baymard Institute montrent combien de boutiques manquent ces deux points : 98 % des sites n’utilisent pas de messages d’erreur précis, et 62 % ne mettent pas la commande en tant qu’invité en avant comme option principale. Les recherches UX de Baymard sur le checkout expliquent les preuves derrière ces recommandations.

Afficher les coûts, délais de livraison et conditions de retour

Affichez tôt les prix, taxes et frais de livraison connus. Présentez une estimation comme une estimation lorsque l’adresse ou le transporteur final n’est pas encore connu. Configurez les taxes, l’affichage des prix par groupe de clients et les transporteurs pour les destinations que vous desservez ; le guide de la livraison couvre la configuration des transporteurs et les frais de livraison. Livraison > Préférences propose des seuils de livraison gratuite ; un message indiquant le montant restant à dépenser nécessite un rendu par le thème ou un module.

Par exemple, un client s'attendant à 40 € peut hésiter si le total atteint 49 €. Affichez le supplément et son fondement avant l'action finale de commande. Un prix inférieur et une explication plus précoce résolvent des problèmes différents.

Fournissez des informations réalistes sur le délai de préparation et d’acheminement du transporteur. Estimated Delivery Date indique le délai d’expédition ou de livraison ; consultez l’aide d’Estimated Delivery Date. Utilisez un estimateur de prix testé séparément ou une politique claire de frais de livraison pour les coûts d’expédition.

Rendez la véritable politique de retour et le moyen de contact faciles à trouver sur les pages produit et panier. L'activation des retours de marchandises contrôle un processus technique. Elle ne crée ni ne supprime les droits légaux et ne justifie pas d'annoncer des retours sous 30 jours si vous ne les proposez pas. Vérifiez les règles de rétractation et exceptions applicables.

Comprendre les portefeuilles express et l'affichage des boutons

Les portefeuilles peuvent fournir des coordonnées enregistrées et des moyens de paiement tokenisés. Une intégration express complète peut collecter les adresses, proposer les choix de livraison pris en charge et actualiser les totaux dans son parcours. Le client peut toujours devoir confirmer des détails, choisir une livraison, accepter des conditions ou s'authentifier. Un paiement par portefeuille à la dernière étape ne contourne pas automatiquement les formulaires précédents.

La commande express est un parcours utilisateur, pas une obligation d'utiliser l'API Payment Request du navigateur. Les intégrations peuvent utiliser interfaces de portefeuille, SDK de prestataires, fenêtres modales ou redirections. Elles peuvent collecter séparément les coordonnées de facturation et de livraison. Gardez un parcours classique pour les navigateurs, destinations et exigences non pris en charge.

Les boutons peuvent apparaître sur les fiches produit, paniers, mini-paniers ou la commande, selon l'intégration et les hooks rendus. Testez si l'express sur une fiche produit paie l'article sélectionné, tout le panier existant ou un nouveau panier. Mesurez valeur du panier et finalisation plutôt que de supposer qu'Acheter maintenant réduit le montant des commandes.

1. Confirmez que le moyen de paiement est activé pour votre compte marchand, pays, devise et montant de panier.
2. Enregistrez chaque nom d'hôte de commande requis par le prestataire, dont les domaines de paiement intégré concernés.
3. Vérifiez HTTPS, certificats, autorisations iframe et erreurs console ou réseau du navigateur.
4. Vérifiez la matrice navigateur actuelle du prestataire et le portefeuille ou moyen de paiement configuré par le client.
5. Vérifiez les restrictions du module et les emplacements pris en charge. La capacité du prestataire ne prouve pas celle du module.

La prise en charge des navigateurs dépend du portefeuille et de l'intégration. Consultez la matrice de commande express Stripe et les consignes d'achat Apple pour les appareils et options d'autorisation actuels.

Si votre prestataire exige un fichier d'association, ceci vérifie seulement son accessibilité :

curl -I https://example.com/.well-known/apple-developer-merchantid-domain-association

Une réponse réussie ne prouve ni l’enregistrement du domaine ni l’éligibilité du portefeuille. Une passerelle prise en charge peut déjà fournir des boutons express ; un accélérateur distinct est une autre option. Consultez l’aide d’Express Checkout.

Un scénario de panier qui révèle le mauvais comportement

Un acheteur a déjà un filtre dans son panier, sélectionne une déclinaison de recharge sur une page produit et appuie sur le bouton express. Votre cahier des charges doit indiquer si cette action achète la recharge seule, le panier existant, ou les deux après vérification. Affichez le contenu avant le paiement et vérifiez ce qui reste dans le panier ensuite ; le libellé d’un bouton ne détermine pas le comportement du module.

Recommencez avec une personnalisation obligatoire laissée vide, puis remplie : le parcours rapide doit appliquer les mêmes exigences produit que le tunnel de commande principal. Si la destination n’a aucun transporteur adapté, le client a besoin d’une explication et d’un moyen de modifier l’adresse ou le panier avant de payer.

Distinguer les paiements enregistrés de la commande en un clic

Un jeton de paiement réutilisable, un client connu, une adresse actuelle, une option de livraison déterminable, un contexte fiscal correct et un consentement valide peuvent raccourcir un réachat. Revérifiez stock, prix, livraison et options obligatoires avant le débit. Conservez les détails de paiement chez le prestataire et stockez uniquement les identifiants client et moyen de paiement nécessaires à l'intégration. Ne stockez pas les numéros de carte bruts ni le CVV dans PrestaShop.

Par exemple, Anna recommande du café avec une adresse et une carte enregistrées. Sa prochaine commande peut demander peu de saisie, mais un changement de frais de livraison ou une authentification bancaire peut ajouter une étape. Lorsqu’elle envoie le paquet suivant à l’adresse d’une amie, la disponibilité de la livraison et le total doivent être vérifiés à nouveau. Un tunnel de commande rapide et utile lui permet de corriger l’adresse ou de valider l’authentification bancaire, puis affiche un résultat de commande clair ; il ne préserve pas un nombre de clics en réutilisant discrètement d’anciennes informations. Un visiteur qui achète pour la première fois peut aussi avoir un portefeuille configuré, même si votre boutique n’a aucune fiche client antérieure : jugez donc les deux parcours sur l’exactitude des informations et un achat finalisé plutôt que sur l’historique d’inscription.

Reconnaître un client connecté est différent de disposer de l’autorisation et de la prise en charge technique nécessaires pour réutiliser un moyen de paiement. Une entrée du carnet d’adresses ou une commande réussie antérieure n’établit pas que la commande suivante peut être débitée, et enregistrer une adresse n’enregistre pas une carte. Demandez au fournisseur de l’intégration où sont conservées les données réutilisables, comment le client les choisit et comment il peut modifier ce choix.

Un client qui achète activement utilise un parcours de paiement enregistré on-session. Off-session désigne un débit initié par le marchand en l’absence du client. Ne marquez pas comme off-session un débit lors d’un passage de commande interactif dans le seul but d’éviter l’authentification. Gérez l’authentification requise et les résultats asynchrones selon l’intégration du prestataire, et demandez au fournisseur comment sont traités la confirmation du client, l’autorisation de paiement enregistré et une demande d’authentification.

1. Recalculez et validez le panier côté serveur.
2. Confirmez l'autorisation du client via le parcours pris en charge par le prestataire.
3. Vérifiez le résultat de paiement de confiance, le montant, la devise et la correspondance avec le panier.
4. Créez ou mettez à jour la commande PrestaShop de manière idempotente. Gérez callbacks en double et nouvelles tentatives.
5. Rapprochez l'état final payé, échoué, en attente ou remboursé.

Un extrait créant un PaymentIntent ne complète pas ce cycle de commande. Les méthodes hors ligne peuvent aussi simplifier la commande sans tokeniser de carte, mais la commande peut rester impayée et nécessiter un rapprochement bancaire ou un paiement à la livraison. Aucun nombre précis de pressions ni achat sans authentification ne peut être garanti.

Choisir et dépanner les intégrations de paiement

ps_checkout, PrestaShop Checkout, est une intégration de paiement, pas le nom de tout le processus de commande. Elle gère options de paiement, autorisation/capture, transactions et remboursements via son intégration PayPal prise en charge. Le marchand connecte un compte PayPal Business. Examinez les conditions de règlement et de versement de votre compte marchand connecté.

Son inclusion dépend de la distribution et de la date. Vérifiez le module installé et la version prise en charge. Utilisez le dépôt officiel du module pour sa documentation et le guide officiel des transactions pour les états de paiement. Des voies officielles de dépannage de compte et de support existent ; suivez leurs conditions publiées.

Pour l'installation, l'activation du compte et la suppression, consultez la documentation officielle de PrestaShop Checkout. Avant de désactiver un prestataire, confirmez qu'un autre parcours de paiement fonctionnel reste disponible.

Vous pouvez évaluer Stripe, Mollie, PayPal, Adyen, Amazon Pay et des intégrations dédiées au paiement fractionné comme Klarna, Alma ou Clearpay/Afterpay au regard de vos besoins. Vérifiez le module PrestaShop concerné plutôt que le nombre de moyens annoncé dans tout le catalogue du prestataire. Comparez la prise en charge de l’autorisation, les remboursements, les litiges, les versements, les devises, l’éligibilité du compte, les paiements récurrents, les rapports et le support. Le guide des paiements approfondit le choix et l’exploitation des moyens de paiement.

Parmi les méthodes régionales à examiner : iDEAL aux Pays-Bas, Bancontact en Belgique, BLIK ou Przelewy24 en Pologne, SEPA ou paiement sur facture en Allemagne/Autriche, Cartes Bancaires ou paiement fractionné en France, Bizum en Espagne, Satispay ou MyBank en Italie et open banking au Royaume-Uni. Ce sont des pistes de recherche, pas des promesses de disponibilité dans votre module. Ne prévoyez pas de nouvelles intégrations sur les services autonomes SOFORT ou Giropay retirés. Consultez la documentation actuelle des méthodes du prestataire.

Comparez les frais réels pour votre entité juridique, le moyen de paiement, l’origine de la carte, la devise, la conversion de devises, les paiements échoués, les remboursements et les litiges. Un module gratuit peut tout de même entraîner des frais de traitement. Le virement bancaire évite les frais d’une passerelle carte, mais peut entraîner des frais bancaires et un rapprochement manuel. Vérifiez la réception des fonds avant l’expédition ; consultez le module natif de virement bancaire.

Pour tout moyen de paiement différé, définissez à quel moment une commande peut être expédiée et qui confirme la réception des fonds : une confirmation de commande ne prouve pas que le paiement est arrivé, alors intégrez ce travail de rapprochement par le personnel dans votre choix. Si vous recevez des virements sur plusieurs comptes ou dans plusieurs devises, Bank Transfer Accounts indique aux clients le compte correspondant à la devise de leur commande, avec le montant et la référence de commande, sur la page de confirmation, dans l’email d’instructions et sur la page de détail de la commande ; vous confirmez toujours vous-même la réception et mettez à jour la commande.

Questions à poser au prestataire et au fournisseur du module

• Chaque moyen requis est-il disponible pour notre entité juridique, les marchés de nos clients, nos devises et la version du module ?
• Où le personnel retrouvera-t-il les références de transaction, effectuera-t-il le rapprochement des versements et gérera-t-il les remboursements complets ou partiels ?
• Qui gère les défauts d’intégration, les restrictions de compte et les litiges de paiement, et de quelles preuves le support aura-t-il besoin ?
• Après un changement, où sont traités et enregistrés les remboursements des commandes prises via l’ancien module ?

Aucun moyen de paiement disponible

1. Vérifiez les modules actifs et les restrictions par devise, pays, groupe et transporteur dans Paiement > Préférences.
2. Vérifiez identifiants du prestataire, état du compte, limites de montant et mode réel ou test.
3. Inspectez les options réellement renvoyées, journaux PHP et erreurs navigateur.
4. Inspectez les véritables en-têtes de réponse si des scripts sont bloqués. Ne supposez pas que PrestaShop 8/9 standard possède une CSP universelle de commande causant l'échec.

Les intégrations de paiement modernes doivent implémenter paymentOptions. Les cœurs 1.7.8 et 9.1 lisent aussi les chemins de compatibilité displayPaymentEU et advancedPaymentOptions. Chercher uniquement un ancien nom de hook ne diagnostique pas l'invisibilité. Les restrictions de disponibilité diffèrent de l'ordre : inspectez la position de paymentOptions dans Apparence > Positions et tout ordre interne du module de paiement.

Tester livraison dynamique, remises et exigences B2B

Changer pays, code postal, quantité ou produit peut modifier transporteurs, taxes, moyens de paiement admissibles et total. Préservez les choix encore valides, effacez visiblement les invalides et empêchez la validation pendant le recalcul. Testez de vrais paniers lourds, virtuels, mixtes et multicolis.

À titre d'illustration, un article de 0,5 kg et un de 25 kg totalisent 25,5 kg. Cela dépasse un plafond hypothétique de transporteur de 20 kg, mais pas de 30 kg. D'autres dimensions, zones et restrictions peuvent toujours exclure un transporteur. Ce sont des limites d'exemple, pas des conditions publiées par un transporteur.

Les règles panier ont des priorités, règles de compatibilité, restrictions client/produit, dates et limites d'usage. Une règle non cumulable de 20 % et une règle séparée de livraison gratuite nécessitent une compatibilité testée. Un bon fixe de 10 € peut entrer en conflit avec une règle automatique de 15 %. Les conditions d'admissibilité et l'action de remise sont des contrôles distincts.

Le minimum d’une règle panier utilise le total des produits avec les réglages de taxe et de devise sélectionnés, plus la livraison si c’est configuré. Les réductions de prix propres aux produits affectent déjà ces totaux. Dans PrestaShop 9.1, le calcul déduit aussi les cadeaux applicables des règles déjà présentes dans le panier. Testez un seuil de 100 € avec un panier éligible et un panier juste en dessous, avec des produits remisés, des produits offerts, une conversion de devise et la livraison incluse ou exclue.

Répétez aussi un cas combiné. Un panier bénéficie d’une remise automatique sur un produit, le client saisit un bon de réduction et une promotion sur la livraison doit s’appliquer. Notez d’abord le résultat voulu : quelles remises se cumulent, quels transporteurs sont éligibles et le montant final à payer. Recommencez après avoir modifié la quantité, le transporteur et le pays de livraison, et comparez le récapitulatif affiché, le montant envoyé au prestataire et l’enregistrement de la commande. Un bon de réduction refusé doit laisser une explication claire et un chemin utilisable vers le paiement.

Les restrictions de transporteur d'une règle de livraison gratuite doivent correspondre aux choix voulus. Profilez l'évaluation lente des règles avant de supprimer les règles historiques ; les dates expirées affectent déjà l'admissibilité. Conservez la configuration selon vos besoins opérationnels.

Une commande compacte « Vous avez un code ? » peut alléger l'interface en gardant les bons utilisables. L'application d'un code promotionnel doit suivre un parcours panier testé et tenant compte du jeton. L'URL seule addDiscount=1&discount_name=SUMMER10 ne suffit pas partout, surtout pour les clients authentifiés. Validez l'admissibilité sur le véritable panier.

En B2B, précisez facturation et livraison distinctes, coordonnées d'entreprise, références de bon de commande, approbation de compte et conditions de paiement convenues. Une identification VAT valide n'est qu'une partie du traitement de la VAT transfrontalière ; les conditions de l'opération et les justificatifs comptent aussi. Distinguez indisponibilité de VIES et résultat invalide. Consultez les consignes européennes sur la VAT transfrontalière.

Les champs supplémentaires nécessitent un cycle de vie complet : les afficher, les valider, les enregistrer et les rendre disponibles là où c’est nécessaire, dans les commandes, exports ou factures. Une référence de bon de commande n’est utile que si elle est validée, conservée avec la commande et visible pour le personnel ou l’export qui en a besoin ; les instructions de livraison doivent parvenir à l’expédition. Faire apparaître un champ dans un modèle n’est pas une implémentation complète. Les extensions du formulaire client peuvent utiliser additionalCustomerFormFields et validateCustomerFormFields ; le guide des hooks et overrides explique comment les modules s’y rattachent. actionValidateOrder seul ne peut pas implémenter le formulaire.

Ce hook de création de commande s'exécute dans PaymentModule::validateOrder(), avant le traitement ultérieur des états. Il peut s'exécuter pour des commandes en attente ou hors ligne. Vérifiez état de paiement et confirmation navigateur séparément de ce hook. Utilisez callbacks appropriés du prestataire et gestion des états de commande pour les actions de paiement, stock et e-mail.

Rendre le parcours utilisable sur téléphone

Utilisez l'analyse par catégorie d'appareil avec des événements d'achat fonctionnels. L'ancien rapport Navigateurs et systèmes d'exploitation est un rapport de compatibilité, pas un entonnoir moderne de revenu mobile. Intention du trafic, composition de l'acquisition, achats entre appareils et lacunes du suivi peuvent aussi expliquer les différences.

Classic reste courant sur les boutiques anciennes et mises à niveau. Hummingbird est devenu le thème par défaut des nouvelles installations PrestaShop 9.1. Ni l'étiquette responsive ni un nouveau thème ne garantissent l'absence de débordement, des claviers utilisables ou des modules accessibles.

• Utilisez type="email" et autocomplete="email" pour l'e-mail, et type="tel" avec autocomplete="tel" pour le téléphone.
• Utilisez des champs texte pour les codes postaux. Ajoutez inputmode="numeric" uniquement si le format du pays choisi est numérique. Les formats britannique, néerlandais et canadien nécessitent des lettres.
• Utilisez les jetons d'autocomplétion de nom et d'adresse appropriés. Inspectez les champs réellement générés. Le formulaire d'adresse moderne utilise customer/_partials/address-form.tpl et un rendu partagé des champs, pas un fichier de saisie supposé dans les partiels de commande.
• Utilisez des commandes grandes et espacées et des lignes de transporteur/paiement entièrement libellées. Une cible de 44 à 48 pixels CSS est une option pratique ; vérifiez taille et espacement sur de vrais appareils.
• Rendez le total actualisé et l'accès à la vérification faciles à atteindre. Assurez-vous que les boutons fixes de validation ne couvrent pas conditions, erreurs, chat ou contrôles de consentement.
• Préservez les valeurs saisies, le focus visible et les messages d'erreur précis au niveau des champs.

Dans le reste de la boutique mobile, utilisez des menus dépliables au toucher avec liens parents, un tiroir de filtres utilisable, des informations produit lisibles et des popups fermables. Gardez le contenu important et les données structurées disponibles dans le rendu mobile. Utilisez des tailles d'image responsive et le chargement différé sous la ligne de flottaison sans retarder l'image principale.

Les liens téléphoniques peuvent aider sur mobile et dans les applications d'appel compatibles sur ordinateur. Produits récemment vus et ajout au panier fixe sont des options à tester dans le thème ou module installé, pas des comportements natifs universels. Comparez sorties de catégorie, découverte de produits et achats avec la finalisation des commandes.

Profilez les requêtes de commande sur une copie de préproduction isolée. Hooks des modules, appels externes de tarifs/taxes/adresses, résolution des transporteurs, règles panier, requêtes en base et scripts sont des goulots possibles. Utilisez _PS_DEBUG_PROFILING_ uniquement si sa sortie reste privée. Activez cache et options de fichiers de production seulement après test du paiement résultant. Excluez les réponses personnalisées de panier, commande et JSON des caches partagés de page entière ou CDN.

Utilisez les outils actuels PageSpeed Insights/Lighthouse, Search Console et des tests sur appareils réels. L'ancien test d'optimisation mobile Google est retiré. Testez réseau cellulaire, téléphones pris en charge, remplissage automatique activé et désactivé, changements de pays, chaque moyen de paiement proposé, annulation d'authentification et nouvelles tentatives. Une fenêtre d'ordinateur redimensionnée ne teste pas le véritable clavier ou portefeuille.

Restaurer les paniers et examiner les échecs de mise à jour

Les clients connectés peuvent récupérer leurs paniers ouverts utilisables selon le comportement de la boutique à la connexion. La récupération invité repose surtout sur le cookie navigateur identifiant le panier. Effacer les cookies, changer d'appareil ou utiliser une session privée peut rompre cette association alors que la ligne existe encore en base. Les paniers commandés ne sont plus des paniers ouverts.

PS_COOKIE_LIFETIME_FO contrôle la durée du cookie de la boutique, pas la conservation des paniers en base. Trouvez le champ correspondant dans l'administration de votre version et confirmez sa valeur dans le bon contexte boutique. Les paramètres de cookies ont changé de page d'administration selon les versions.

1. Reproduisez le problème avec un produit, une déclinaison, une quantité, un client et un pays précis, et notez l’URL en échec et l’heure. Ouvrez Console et Réseau dans les outils du navigateur.
2. Inspectez la requête et la réponse du panier. Un statut 200 peut contenir une erreur applicative ou du HTML au lieu du JSON attendu. Un 500 nécessite les journaux PHP/serveur ; un 403 nécessite de vérifier jeton, autorisations, WAF et sécurité.
3. Rejouez la véritable requête navigateur uniquement dans un contexte de test sûr, avec ses cookies de session et son jeton actuel. Un exemple curl inventé avec jeton statique n'est pas un test fiable du panier.
4. Videz les caches de modèles et fichiers concernés via Paramètres avancés > Performances. Désactivez temporairement le regroupement en préproduction si un paquet combiné masque l'échec.
5. Vérifiez domaine du cookie, HTTPS, comportement SameSite/Secure et tout stockage de sessions avec répartition de charge. Vérifiez la gestion avec et sans www.
6. Vérifiez les hooks de modules liés au panier et isolez les conflits sur une copie de préproduction sauvegardée, avec un plan de retour arrière. Désactivez des groupes de modules, puis resserrez jusqu’au module responsable. Testez à nouveau les callbacks des prestataires après la modification.

Considérez les constats sur le domaine, les cookies et les modules comme des pistes d’enquête jusqu’à ce que l’échec soit reproduit et que la correction le supprime. Régénérez ou purgez le cache CDN ou des ressources concerné après une correction. Un cache partagé doit contourner les points d’accès du panier propres à chaque client. Une erreur JavaScript peut bloquer le parcours concerné, mais une erreur ne prouve pas automatiquement que tous les scripts de la page ont cessé de s’exécuter.

Sécuriser le paiement et relancer les paniers encore abandonnés

Servez le tunnel de commande et les ressources du prestataire en HTTPS valide. Vérifiez le contenu mixte, les URL de retour et l’accessibilité des callbacks. Privilégiez les champs hébergés par le prestataire ou une page de paiement hébergée lorsque c’est approprié, et tenez les données de carte brutes à l’écart des journaux de l’application et des formulaires de la boutique. N’ajoutez pas de code sur mesure qui fait transiter des données de carte brutes par votre boutique.

Le périmètre PCI dépend de l'implémentation complète. Des iframe hébergées ou redirections ne garantissent pas seules l'admissibilité SAQ A. Pour les formulaires intégrés, les critères SAQ A actuels incluent la confirmation que la page marchande n'est pas vulnérable aux attaques par scripts. Confirmez l'évaluation applicable avec l'entité acceptant votre déclaration de conformité. Suivez les consignes d'admissibilité du PCI SSC ; ne décidez pas entre SAQ A et A-EP sur la seule présence de JavaScript du prestataire.

Les exigences d'authentification forte du client comportent des exemptions et des transactions hors champ. 3D Secure est un mécanisme pris en charge par les intégrations carte, pas la réglementation elle-même. Certaines transactions se terminent sans défi visible ; d'autres demandent une authentification. Testez réussite, refus, annulation, dépassements de délai et retour depuis une page de paiement externe.

La conservation des paniers et l’email de relance sont deux fonctions distinctes. Le stockage natif des paniers n’envoie pas automatiquement de rappels. Un outil dédié ou une intégration marketing peut assurer la relance, sous réserve des règles applicables aux messages, du consentement ou des conditions de soft opt-in. Consultez l’aide de Sales Revolution et l’aide de Klaviyo Integration.

Un rappel peut aider un client interrompu ou souhaitant plus de temps. Il peut aussi le ramener à la même erreur non résolue. Corrigez les défauts confirmés de commande et mesurez la relance séparément. Incluez frais de messagerie, remises, préparation et support pour évaluer le bénéfice. Respectez les désinscriptions et ne supposez pas qu'un rappel sans remise est purement transactionnel.

Répéter le parcours de commande avant la bascule en production

Conservez une référence horodatée et un chemin de retour arrière pour les modifications du tunnel de commande. Avant de remplacer, désactiver ou désinstaller un module de commande ou de paiement, réalisez une sauvegarde des fichiers et de la base, travaillez sur une copie de préproduction et testez le retour. Isolez la préproduction des vrais paiements, des emails clients et de l’expédition. Suivez les instructions de suppression du module et conservez les enregistrements et accès nécessaires aux paiements et remboursements existants ; le guide de suppression des modules indique ce qu’il faut conserver.

• Nouveau client : un achat en invité lorsqu’il est proposé, puis un achat avec compte, sur téléphone et sur ordinateur. Vérifiez les champs obligatoires et la séparation des coordonnées de livraison et de facturation.
• Client connu : sélection d’une adresse enregistrée, modification d’adresse et tout parcours de paiement enregistré ou de portefeuille confirmé par le fournisseur.
• Produit et panier : une déclinaison, une personnalisation obligatoire et un panier de plusieurs articles. Vérifiez qu’une fenêtre express achète le contenu voulu.
• Livraison et totaux : changez de pays et de transporteur en cours de route, appliquez un bon de réduction et vérifiez les montants finaux de taxe et de livraison pour chaque pays, devise et groupe de clients que vous servez.
• Paiement : réussite, refus, authentification validée puis annulée, confirmation différée, fermeture du navigateur et notification répétée, selon la procédure de test prise en charge par le prestataire.
• Exploitation : totaux, factures, mouvements de stock, emails de confirmation, remboursements, enregistrements du prestataire et exports vers la comptabilité ou l’expédition, y compris toute intégration sur mesure.

Jugez chaque scénario sur ces enregistrements, et pas seulement sur l’écran de confirmation. Vérifiez qu’un paiement refusé ou une authentification annulée affiche un résultat de paiement clair, conserve le panier voulu et permet de réessayer ou de changer de moyen de paiement sans double débit involontaire. Consignez l’état de commande et de paiement attendu pour chaque moyen : un virement en attente et un paiement par carte confirmé ne doivent pas partager la même attente d’expédition. Vérifiez explicitement la prévention des commandes en double : actualiser ou revisiter la page de confirmation ne doit pas créer une seconde commande ou un second débit involontaires.

Demander des preuves au fournisseur, pas une simple promesse de rapidité

• Quel parcours utilise vos modules de paiement actuels, et lequel utilise l’intégration de paiement propre au module ? Quelles versions exactes ont été vérifiées ?
• Un bouton sur la page produit achète-t-il l’article sélectionné ou le panier, et comment les variantes, la personnalisation et une adresse modifiée sont-elles vérifiées ?
• Quel besoin de paiement enregistré ou de portefeuille est pris en charge, et que se passe-t-il après une authentification refusée ou annulée ?
• Comment le personnel rapproche-t-il un paiement finalisé après la fermeture du navigateur, et comment restaure-t-il l’ancien tunnel de commande si les contrôles de lancement échouent ?

Demandez à une agence de remettre un inventaire des versions, les scénarios d’achat convenus, les preuves de test, la configuration enregistrée et les étapes de retour arrière, et d’indiquer qui gère les paiements différés, les remboursements et la surveillance après le lancement.

Après le lancement, rapprochez les nouvelles commandes des transactions du prestataire. Si un retour en arrière devient nécessaire, tenez compte des ventes réalisées depuis la sauvegarde avant de restaurer une base de données. Comparez les commandes payées finalisées, les échecs de paiement et les problèmes de support par appareil et type de client avec votre propre référence.

Questions des marchands

La commande en un clic est-elle possible dans PrestaShop ?

Une seule action peut passer une commande lorsque l’identité, l’adresse, la livraison et les modalités de paiement sont déjà déterminées. Les parcours de paiement enregistré exigent une réutilisation prise en charge et l’autorisation du client ; un moyen hors ligne peut passer une commande impayée sans données de carte réutilisables. Même dans ce cas, une adresse modifiée, un transporteur indisponible ou une demande d’authentification bancaire ajoute une étape : présentez donc le tunnel de commande comme rapide sans promettre le même nombre d’actions à chaque acheteur.

Une boutique accueillant surtout de nouveaux clients doit-elle viser le clic unique ?

Commencez par la commande invité lorsque c’est approprié, des totaux affichés tôt et un formulaire utilisable, puis testez un portefeuille pris en charge. Un raccourci pour clients connus règle peu des difficultés que rencontrent les nouveaux acheteurs.

Installer ps_checkout nous donnera-t-il un tunnel de commande sur une page ?

Non. Il ajoute des options de paiement basées sur PayPal à l’étape de paiement. Sur 9.2, la question de la présentation relève du module natif sur une page ; sur les versions antérieures, d’un module de commande ou d’un développement sur mesure.

Avons-nous besoin à la fois de Checkout Revolution et d’Express Checkout ?

En général, non. Les deux proposent une fenêtre d’achat sur les pages produit, les listes de produits et le panier, et les deux transforment en commande un paiement finalisé après la fermeture du navigateur. Choisissez selon que le besoin est une page unique utilisant vos transporteurs et moyens de paiement existants, ou une fenêtre d’achat basée sur Stripe ; aucune des deux descriptions n’établit qu’ils fonctionnent ensemble, alors testez la combinaison en préproduction avant d’activer les deux.