One Page Checkout natif de PrestaShop 9.2 : ce qu'il fait et quand il vous faut plus

Comment il fonctionne

• C'est un module séparé. Le tunnel est livré avec la 9.2 sous le nom ps_onepagecheckout et peut être mis à jour indépendamment de PrestaShop lui-même, alors vérifiez à la fois la version du cœur et celle du module sur votre boutique.
• Il est désactivé tant que vous ne l'activez pas. Une nouvelle installation de la 9.2 garde le tunnel classique en quatre étapes. Vous choisissez la mise en page en une page sous Design > Checkout et pouvez revenir en arrière à tout moment.
• Il nécessite la 9.2. Le module déclare PrestaShop 9.2.0 comme minimum. Les boutiques en 1.7, 8, 9.0 ou 9.1 ne peuvent pas l'installer.
• Il se branche sur le cœur, sans le contourner. Le module fournit son propre processus de commande via le hook actionCheckoutBuildProcess au lieu de surcharger le contrôleur de commande, et remplace les quatre classes d'étapes (informations personnelles, adresses, livraison, paiement) par une seule étape combinée.
• La page se met à jour par sections. Un client invité est créé dès que l'e-mail et les consentements requis sont valides, le formulaire d'adresse est reconstruit quand le pays change, et les transporteurs et options de paiement se rafraîchissent à mesure que l'adresse est complétée. Les options de paiement viennent toujours du mécanisme standard de découverte des options de paiement de PrestaShop.
• La connexion et l'inscription ont leurs propres pages. Le tunnel classique permet à l'acheteur de définir un mot de passe et de créer un compte pendant la commande. Le One Page Checkout renvoie plutôt vers les pages séparées de connexion et d'inscription. Les acheteurs invités ne le remarqueront pas ; une boutique qui compte sur les créations de compte au moment de l'achat, si.

Le module est encore en dessous de la version 1.0, et son README déconseille toujours de l'utiliser sur des boutiques en production. La version 0.6.6 a ajouté un hook displayExpressCheckout au-dessus du formulaire de commande, la validation du code postal pour les invités et un ordre des champs d'adresse par pays. Lisez les notes de version de la version que vous comptez utiliser.

Avant de l'activer

• Thème. L'annonce de PrestaShop indique que le tunnel est conçu pour les thèmes basés sur Hummingbird. Classic n'est pas pris en charge par défaut, et vous devrez peut-être surcharger certains templates du module.
• Modules de paiement et de transport. Les hooks existants sont conservés, donc beaucoup de modules apparaissent sans modification. Mais tout s'affiche désormais sur un seul écran et se rafraîchit par sections, alors testez chaque module de paiement et de transport sur une copie de préproduction, surtout les transporteurs qui calculent le prix selon le code postal et les modules de paiement qui affichent leur propre balisage.
• Le paiement peut encore quitter la page. Un formulaire en une page supprime les étapes avant le paiement. Une vérification de carte avec 3D Secure, une page de paiement hébergée ou une confirmation bancaire peut encore emmener l'acheteur ailleurs puis le ramener.
• Codes promo. Le champ de bon de réduction n'apparaît que lorsque votre boutique a au moins une règle panier, car PrestaShop désactive toute la fonction de règles panier quand il n'y en a aucune. Un champ vide sur une boutique de test n'est pas un bug.
• Un autre module de commande. Si un tunnel de remplacement est déjà actif, lisez d'abord ses instructions de changement et ses dépendances. N'empilez pas deux tunnels de remplacement sans avoir confirmé qu'ils peuvent coexister.
• Code de commande sur mesure. Demandez à votre développeur de lister ce qui modifie les templates, les champs, les choix de paiement ou la sélection du transporteur dans le tunnel, y compris les scripts liés à l'ancien balisage des étapes et les sélecteurs de points relais. Une recherche dans le code montre ce qu'il faut examiner ; un hook ou un nom de fichier correspondant ne prouve pas un conflit.

Décidez en partant de votre configuration existante : notez les versions exactes de PrestaShop et de PHP, le thème et sa version, les versions des modules de paiement et de transport, les règles de commande sur mesure et les systèmes connectés. Essayez d'abord la modification sur une copie de préproduction. Sauvegardez les fichiers et la base de données, passez une commande de référence avec le tunnel actuel, puis changez la mise en page sans aucune autre modification du thème ou des paiements en même temps. Répétez les mêmes commandes et comparez les enregistrements obtenus, pas des captures d'écran :

• Un client invité et un client connu, sur téléphone et sur ordinateur, y compris une adresse de facturation distincte si vous en utilisez une.
• Un panier avec un bon de réduction ou une promotion sur la livraison : saisissez une adresse, choisissez un transporteur, puis passez à un autre pays dans lequel vous vendez. La livraison, les taxes, la promotion et les choix de paiement doivent tous être recalculés avant le paiement.
• Des paiements réussis, refusés et annulés, le 3D Secure, et un paiement confirmé après la fermeture du navigateur par l'acheteur, avec les outils de test du prestataire.
• La commande obtenue, la référence de paiement, l'e-mail de confirmation et le mouvement de stock, ainsi que tout export connecté vers l'expédition ou la comptabilité. Si vous utilisez des boutons express, testez séparément chaque point d'entrée activé, y compris les déclinaisons de produits, les quantités et un panier existant.
• Les champs obligatoires des acheteurs professionnels et les règles de paiement par groupe de clients, comme cas distincts : une commande invité réussie ne les couvre pas.

Arrêtez le déploiement si le total affiché diffère du montant envoyé au prestataire de paiement ou enregistré sur la commande. Utilisez des identifiants de paiement de test, dirigez les e-mails de préproduction vers une boîte de test et désactivez les exports réels vers l'expédition et la comptabilité.

Avant de basculer en production, réalisez une nouvelle sauvegarde des fichiers et de la base, notez la configuration actuelle et confirmez la procédure de retour arrière testée en préproduction. Revenir en arrière tient à un seul réglage, mais cela n'annule pas les paiements. Préservez et rapprochez les commandes et transactions du prestataire enregistrées depuis la sauvegarde avant d'envisager une restauration de la base. Après la bascule en production, comparez les commandes finalisées, les échecs de paiement et les demandes au support avec votre référence, à trafic et offres comparables, séparément sur mobile et sur ordinateur. Gardez la même définition d'un début de commande entre les deux mises en page. Une mise en page en une page n'apporte aucune hausse de conversion garantie.

Le tunnel natif vous suffit-il ?

C'est un bon choix par défaut si vous êtes en 9.2, utilisez Hummingbird ou un thème enfant basé sur Hummingbird, et avez un tunnel B2C standard : quelques transporteurs, des moyens de paiement courants et la commande invité comme norme. Dans ce cas, testez-le en préproduction avant d'acheter un module. Ne l'utilisez en production que lorsque la version choisie est documentée comme adaptée à la production et réussit les scénarios de commande convenus.

Cherchez plus loin lorsque vous pouvez nommer un besoin qu'il ne couvre pas, par exemple si :

• votre boutique tourne sur PrestaShop 1.6 à 9.1 et aucune mise à jour n'est prévue prochainement ;
• vous voulez des boutons de portefeuille électronique sur les pages produit et panier, pas seulement dans le tunnel. Le module natif donne aux modules de paiement un emplacement pour afficher des boutons express, mais ne les fournit pas lui-même ;
• vous voulez que les acheteurs créent un compte pendant leur commande ;
• vous dépendez de champs de commande sur mesure, de règles B2B ou de restrictions de paiement par groupe de clients. Notez d'abord ces règles (qui peut payer sur compte, où une référence d'achat doit apparaître, comment un devis accepté devient une commande), puis vérifiez que les modules qui les fournissent fonctionnent dans le parcours en une page avant de basculer.

Faut-il l'attendre ?

• Déjà en 9.2 : le code est disponible, mais l'avertissement du README reste une raison d'attendre avant de l'utiliser en production. Vu le statut antérieur à la 1.0 du module et l'avertissement de son README, gardez votre tunnel actuel en production jusqu'à ce qu'une version que vous avez testée réussisse vos commandes en préproduction.
• En 9.0 ou 9.1 : le tunnel natif arrive avec la mise à jour vers la 9.2. Planifiez cette mise à jour pour ses propres mérites (thème, modules, PHP) et testez le tunnel dans ce cadre. Si votre tunnel actuel fonctionne, attendre cette mise à jour est raisonnable.
• En 1.6, 1.7 ou 8 : passer à la 9.2 exige un plan de migration fondé sur vos modules, intégrations, thème et données existants. Pour les boutiques anciennes ou très personnalisées, le parcours sûr habituel est une boutique 9.2 propre en préproduction, une migration des données répétée et une bascule planifiée ; la checklist de migration vers PrestaShop 9 détaille la démarche. Ne changez pas de version majeure pour la seule mise en page du tunnel.
• Vous perdez des commandes maintenant : n'attendez pas. Une erreur de paiement reproductible ou un point d'abandon connu doit être diagnostiqué dès aujourd'hui, et une nouvelle mise en page ne corrige pas une erreur de paiement.

Si vous ne savez pas où les acheteurs abandonnent, le PrestaShop B2C Conversion & Revenue Audit examine le parcours d'achat des particuliers et fournit un plan de corrections classé par priorité, sans rien installer ni modifier.

Checkout Revolution propose un tunnel en une page et une fenêtre modale de commande express également sur PrestaShop 1.6 à 9.1, avec des règles de champs et de paiement par groupe de clients et par pays, et des devis professionnels acceptés qui deviennent des commandes. Express Checkout ajoute une fenêtre d'achat Stripe (cartes, portefeuilles et moyens locaux) sur les pages produit, les listes de produits ou le panier, à côté de votre tunnel existant, et propose en option un tunnel sur une page qui intègre vos autres modules de paiement et de livraison. Les autres options sont comparées dans notre guide du tunnel de commande.

Une fois le module choisi, le PrestaShop Module Installation & Configuration Service installe et configure un module existant et vérifie le parcours concerné, avec des étapes de retour arrière documentées.