Préciser quelle option manque et à quel endroit
Une méthode apparaît activée dans l’administration, mais le client ne la trouve pas à la commande. Une passerelle active n’est pourtant pas une promesse d’affichage pour tous les paniers. Le pays, la devise, le montant, le type de produit, le transport et le formulaire peuvent intervenir. Le résultat recherché est une méthode visible pour les achats auxquels elle est réellement destinée.
Commencez par distinguer la passerelle, qui relie la boutique au service, et le moyen précis qu’elle propose. Une même extension peut offrir carte, virement local et boutons express. La présence de l’extension dans la liste ne garantit pas que chaque méthode est activée. Un bouton express placé au-dessus du formulaire ne remplace pas nécessairement une ligne de paiement classique plus bas.
Ce guide concerne une boutique WordPress utilisant déjà WooCommerce, avec des droits d’administration pour les réglages. L’espace du prestataire peut nécessiter une autre autorisation. Sur un réseau multisite, contrôlez le bon site. Sur WordPress.com, ouvrez les réglages WooCommerce dans l’administration de la boutique ; les conditions propres au service de paiement restent distinctes de l’offre d’hébergement.
WooCommerce est une extension gratuite ; les moyens de paiement ont leurs propres conditions et parfois des frais de service. Le paiement n’est pas une fonction du cœur WordPress seul. Il n’est pas utile d’installer une nouvelle passerelle avant de comprendre pourquoi celle qui est prévue ne s’affiche pas.
Construire un cas de comparaison sans passer de paiement
Notez le nom exact de la méthode attendue, la page, le montant après remise, la devise, le pays de facturation et de livraison, le transport et les produits du panier. Précisez si le visiteur est connecté. Comparez un cas dans lequel la méthode manque avec un cas réellement connu comme éligible, plutôt qu’avec un ancien souvenir d’affichage.
Vérifiez le total final. Si le panier ne demande aucun règlement après une remise complète, WooCommerce peut ne pas afficher la sélection habituelle de paiement. Ce comportement n’est pas une panne de connexion au prestataire. Ne modifiez pas le prix d’un produit public pour tester : utilisez une copie isolée et un produit de diagnostic.
Identifiez aussi le type de commande. Dans WooCommerce, Réglages, Avancé, relevez la page assignée ; ouvrez-la dans Pages. La Vue en liste indique un bloc Commande ou un formulaire classique par code court, à moins qu’un constructeur ne fournisse son propre module. Une intégration compatible avec l’un n’est pas automatiquement compatible avec tous les autres.
Pour les comparaisons qui modifient les réglages, utilisez une copie à base distincte, avec la passerelle reliée à son environnement de test et les autres effets externes neutralisés. Employez des coordonnées fictives de test, jamais les coordonnées ou les moyens de paiement d’un client. Le simple examen du formulaire sur le site actif ne nécessite pas de cliquer sur Commander. Ne demandez pas au client de multiplier les achats ou de changer son adresse réelle pour faire apparaître un moyen interdit dans son pays.
- Méthode désactivée ou réglage non enregistré : appliquez le premier parcours.
- Méthode active mais absente pour certains paniers : examinez les conditions de disponibilité.
- Méthode attendue pour un cas éligible mais invisible : contrôlez compatibilité et chargement du formulaire.
- Paiement déjà encaissé : changez de diagnostic et rapprochez la commande avant toute nouvelle tentative.
Parcours 1 : vérifier l’activation qui gouverne réellement la méthode
Ouvrez WooCommerce, Réglages, Paiements. Retrouvez le service déjà utilisé, vérifiez son état puis ouvrez Gérer ou ses réglages. Une extension installée mais inactive dans Extensions ne peut pas fournir son formulaire. À l’inverse, une extension active peut garder son option de paiement désactivée. Notez les valeurs avant toute correction.
Si une activation a été oubliée, confirmez que ce service fait partie des moyens autorisés par la boutique. Ne changez pas simultanément le compte marchand, le mode de paiement et la devise : vous ne sauriez plus quelle valeur explique le retour de l’option.
Les moyens hors ligne inclus dans WooCommerce, comme le virement ou le paiement à la livraison, se trouvent dans la zone Take offline payments ou son équivalent traduit des réglages Paiements actuels. Utilisez Activer puis Gérer pour le moyen voulu. Ne les ajoutez pas comme faux substituts d’un paiement par carte : ils engagent un autre processus de suivi.
Le résultat attendu est une méthode proposée dans le cas compatible, avec le titre et les instructions prévus. Son activation ne déclenche aucun encaissement à elle seule, mais la rend disponible aux clients ; vérifiez donc que l’organisation sait traiter ce moyen. Pour annuler une activation de diagnostic inadaptée, remettez son état initial et enregistrez.
Si tous les états sont corrects, poursuivez avec les conditions de panier et le compte prestataire. Réinstaller une extension ou recréer des clés n’est pas la prochaine étape automatique : l’absence peut être une décision normale de disponibilité.
- Dans Extensions installées, confirmez que la passerelle prévue est active.
- Dans WooCommerce, Réglages, Paiements, ouvrez Gérer pour cette passerelle et relevez son état initial.
- Activez seulement le moyen prévu puis enregistrez les modifications.
- Rechargez ce même écran pour vérifier la valeur conservée, puis actualisez le panier témoin sans passer de commande.
- Si cette activation n’était pas justifiée, remettez l’état initial et enregistrez le retour.
Parcours 2 : corriger une condition de disponibilité incohérente
Ce parcours convient lorsque la méthode manque seulement pour un groupe de paniers. Commencez par le cas le plus simple : un produit en stock, un montant positif et une destination que la boutique dessert. Changez ensuite une seule caractéristique à la fois sur la copie isolée. Un changement d’adresse peut modifier transport et taxes en même temps ; notez le résultat final, pas seulement la valeur saisie.
Pour le paiement à la livraison inclus dans WooCommerce, ouvrez ses réglages depuis Paiements, Take offline payments, puis Gérer. Examinez Enable for shipping methods : une restriction à certains transports doit correspondre aux méthodes et tarifs réellement sélectionnés. Un transport recréé ou une autre instance de tarif peut ne plus correspondre au choix initial.
Examinez aussi Accept for virtual orders. Un panier sans livraison peut être exclu si cette option n’autorise pas les commandes virtuelles. N’activez cette possibilité que si votre organisation accepte réellement ce paiement pour ces produits. Faire apparaître une méthode impossible à encaisser ne constitue pas une réparation. Conservez les valeurs initiales et enregistrez seulement la correction justifiée.
Pour une passerelle en ligne, vérifiez les devises, pays, montants et catégories de produits qu’elle prend en charge. Les achats récurrents, réservations ou précommandes peuvent demander un support spécifique. La disponibilité d’un paiement ponctuel ne garantit pas celle d’un abonnement. Ne forcez pas son affichage avec un extrait de code qui ignorerait ces conditions.
Le résultat attendu est une méthode présente pour les cas autorisés et absente pour les cas volontairement exclus. Reprenez ensuite le panier initial pour confirmer la différence. Si l’ajustement était injustifié ou ne change rien, remettez la valeur sauvegardée avant une autre comparaison. Les règles d’une extension de restrictions doivent être examinées dans cette extension, sans supposer qu’elles appartiennent au cœur de WooCommerce.
Contrôler les deux niveaux de réglages de Stripe
Si la boutique utilise précisément WooCommerce Stripe Payment Gateway, ouvrez WooCommerce, Réglages, Paiements, Stripe. Cette extension gratuite est distincte de WooPayments et des autres extensions qui utilisent Stripe. Les frais et conditions du service de paiement restent séparés. Vérifiez son nom exact dans Extensions installées avant d’appliquer ce parcours.
Dans les réglages généraux, contrôlez Enable Stripe. Dans Payment Methods, vérifiez ensuite le moyen individuel attendu, cochez-le si cela correspond à votre politique et enregistrez. Quand la synchronisation est active, ces choix sont également transmis à la configuration Stripe associée à WooCommerce. Une modification depuis une copie peut donc dépasser cette copie si elle utilise le compte réel : confirmez l’environnement test avant de changer les méthodes.
Consultez aussi Account details pour vérifier le compte connecté et ses éventuelles restrictions. Sur la copie, ouvrez Configure connection puis l’onglet Test pour vérifier la connexion de test ; dans General, cochez Enable test mode et enregistrez. Si cette connexion manque, faites-la préparer par le responsable du compte avant un essai. Ne basculez pas le mode réel ou test de la boutique active pour diagnostiquer sa copie. Une restriction de compte doit être résolue dans le compte concerné, pas contournée avec les clés d’une autre organisation.
Si vous venez de changer une méthode, actualisez la page Payment Methods de l’extension puis le formulaire de commande. Une mise à jour de configuration peut nécessiter le rafraîchissement de ses données ; cela ne justifie pas de supprimer tous les réglages temporaires de WordPress. Gardez un cas de panier éligible identique pour comparer.
Le résultat attendu est l’activation cohérente de la passerelle et du moyen pris en charge, dans le bon compte. Si Account details affiche Sync désactivé, ne supposez pas qu’un changement a été répercuté entre les deux espaces. Une méthode visible dans le tableau de bord Stripe peut aussi ne pas être prise en charge par l’extension WooCommerce. Avant d’en déduire un bug, vérifiez cette compatibilité précise. Pour annuler une activation inutile, remettez la méthode à son état initial et enregistrez.
Distinguer bouton express absent et paiement classique absent
Les boutons express dépendent aussi du navigateur, de l’appareil et de la configuration du portefeuille du client. Leur absence sur une machine ne signifie pas que la carte classique est indisponible. Comparez l’emplacement express et la liste des paiements ordinaires avant de conclure que toute la passerelle manque.
Avec Stripe, un portefeuille attendu doit être utilisé dans un environnement pris en charge, avec un moyen de paiement configuré lorsque cela est requis. Un navigateur privé peut aider à isoler un cache ou une extension, mais il peut aussi modifier l’accès au portefeuille. Il ne constitue donc pas, à lui seul, le témoin universel de l’affichage express.
Vérifiez également la page sur laquelle les boutons sont autorisés et la compatibilité des produits. Un bouton présent sur la commande peut ne pas être activé sur la fiche produit ou le panier. Ne déplacez pas toute la zone de paiement pour imiter une autre boutique dont les réglages et produits diffèrent.
Le résultat utile est plus précis que « je vois un bouton » : le moyen attendu apparaît au bon emplacement pour un environnement et un panier pris en charge. Gardez un paiement classique fonctionnel lorsque votre politique le prévoit. Ne demandez pas de données personnelles de portefeuille ni d’achat réel pour prouver cette éligibilité. Utilisez le parcours de test documenté pour le portefeuille concerné ; une réussite sur un appareil ne garantit pas l’affichage sur tous les autres.
Parcours 3 : vérifier le formulaire et les scripts sur une copie isolée
Si le cas est éligible et les réglages sont corrects, examinez le formulaire utilisé. Pour le bloc Commande, la passerelle doit proposer une intégration compatible avec les blocs, avec ses scripts et ses contrôles de disponibilité. Une ancienne intégration classique peut être active dans l’administration sans pouvoir fournir l’interface attendue dans ce bloc.
Dans l’éditeur de la page Commande, ouvrez la Vue en liste et sélectionnez le bloc Payment Options, ou Options de paiement. Sa barre latérale liste les intégrations actives et peut signaler celles qui sont incompatibles. L’aperçu de l’éditeur ne vérifie cependant pas l’éligibilité du panier réel : ce contrôle doit être effectué sur le formulaire public de la copie.
Sur la copie isolée, vérifiez la compatibilité déclarée de la version installée et ses dépendances. Mettez à jour seulement dans un ensemble de versions compatible et sauvegardé. Ne basculez pas immédiatement toute la production du bloc vers un formulaire classique : d’autres champs, règles de livraison ou intégrations peuvent dépendre du parcours actuel.
Dans Chrome, ouvrez les outils de développement depuis le menu Plus d’outils, puis l’onglet Réseau. Effacez seulement la liste de requêtes affichée, rechargez la page Commande et cherchez le script de paiement qui échoue. Sélectionnez sa ligne pour lire le statut et les en-têtes ; consultez ensuite Console pour l’erreur associée. Gardez le fichier et la première erreur pertinente, sans partager de jeton ni exporter toutes les données de la session. Si le formulaire est simplement caché par une règle de style, supprimer cette règle peut révéler l’élément ; cela ne rend pas une méthode non éligible utilisable.
Comparez ensuite sans la transformation de scripts suspecte, uniquement sur cette page et dans la copie. Utilisez les options de l’outil déjà présent et leur documentation, sans ajouter un deuxième optimiseur. Si une protection bloque la requête, faites examiner la règle précise. Ne rendez pas toute l’API publique et ne retirez pas globalement le contrôle de sécurité pour afficher le formulaire.
Le résultat attendu est une interface chargée sans l’erreur identifiée. Confirmez-le en rétablissant le composant suspect sur la copie : la panne doit être attribuable au même scénario. Rétablissez les réglages qui n’ont aucun effet. Si un composant reste incompatible, conservez la configuration de production comprise et faites choisir une correction compatible avant un déploiement.
- Relevez le type de formulaire et le signal de compatibilité dans l’éditeur, sans publier un autre formulaire.
- Rechargez la page publique de la copie avec le même panier et relevez l’erreur réseau ou JavaScript.
- Modifiez seulement l’exclusion de script suspecte dans l’optimiseur déjà présent, en conservant sa valeur initiale.
- Comparez le résultat, puis remettez ce réglage sur la copie pour vérifier si la même erreur revient.
- Conservez uniquement une correction expliquée ; rétablissez les essais sans effet avant de préparer sa mise en production.
Lire les journaux sans confondre visibilité et autorisation bancaire
Dans WooCommerce, État, Journaux, examinez les événements de la passerelle au moment où vous ouvrez le formulaire. Une erreur de connexion au compte ou de récupération des méthodes fournit une piste différente d’un refus bancaire après soumission. L’absence de paiement dans le journal est normale si vous n’avez fait qu’afficher la page.
Pour l’extension Stripe citée, le réglage se trouve dans Advanced settings : Debug mode, Log error messages. Relevez sa valeur, activez-le temporairement et enregistrez, puis rechargez une fois le cas sûr. Consultez le journal Stripe correspondant dans WooCommerce, État, Journaux. Après collecte, remettez la valeur de journalisation initiale et enregistrez. Pour une autre passerelle, suivez son propre chemin documenté. Ces journaux concernent les événements futurs, pas ceux qui n’étaient pas enregistrés. Retirez les données personnelles, jetons et secrets avant de partager un extrait ciblé.
Dans WooCommerce, État, État du système, examinez les versions et les modèles de thème remplacés. Un modèle de commande ancien peut expliquer une différence d’affichage, mais sa présence ne prouve pas à elle seule qu’il est responsable. Comparez sur la copie avec le modèle compatible avant de modifier le thème actif.
Pour demander une correction, fournissez le moyen précis, le panier anonymisé, pays et devise, type de formulaire, versions et première erreur. Une demande formulée seulement comme « les paiements ne marchent pas » mélange affichage, autorisation et encaissement. Les vérifications précédentes permettent au responsable de traiter le bon niveau sans solliciter une nouvelle carte du client.
Vérifier les cas autorisés et les exclusions conservées
Après correction, reprenez un cas qui doit afficher la méthode et un cas qui doit rester exclu. Par exemple, une restriction de transport volontaire doit continuer à agir sur les livraisons non prévues. Un changement qui rend le moyen visible pour tous peut avoir supprimé une condition commerciale nécessaire.
Sur la copie sécurisée, terminez ensuite une seule commande en mode test si la correction a touché l’intégration ou ses scripts. La présence de la ligne de paiement ne prouve pas que la soumission aboutit. Vérifiez l’unique commande, le résultat de test et le statut attendu sans rejouer un paiement réel.
Conservez les valeurs définitives et la procédure de retour arrière : état de la méthode, règle ciblée ou version compatible du composant. Ne restaurez pas toute la base de la boutique pour annuler une activation. Les commandes récentes doivent être préservées lors de la mise en place de la correction.
La méthode manquante est rétablie lorsque son activation, ses conditions et son interface correspondent au besoin réel du client. Si le paiement devient visible mais reste ensuite sur un chargement sans fin, reprenez le diagnostic de la requête. Si un encaissement existe déjà sans statut cohérent, rapprochez cette transaction avant toute nouvelle tentative.
