Configurer les paiements sur WooCommerce correctement

Une passerelle ici est un module, et le compte est distinct

WooCommerce le dit clairement : « Une passerelle de paiement, au sens de WooCommerce, est un module WordPress qui permet à WooCommerce de connecter un client à un processeur de paiement afin qu'il puisse payer des biens et services. » Il ajoute que tous les processeurs exigent un compte, habituellement appelé compte marchand, et que chaque processeur a ses propres modalités et frais, distincts du coût du module lui-même, dirigeant les commerçants vers le processeur pour les exigences de compte, les modalités et les frais. Deux conséquences en découlent. Le prix du module n'est pas le prix du traitement, et le fournisseur du module n'est pas la partie qui peut répondre à une question de tarification. Les commerçants qui traitent l'achat d'une extension premium comme la fin de la décision commerciale sont habituellement surpris plus tard par le propre barème du processeur. Notre guide sur la différence entre une passerelle et un processeur explique quelle partie possède quelle portion de la transaction.

Le choix redirection ou direct est la décision qui fixe votre portée

La documentation de WooCommerce présente le choix de sécurité comme deux options. Redirection : « Le client est redirigé vers le site de la passerelle de paiement pour traiter le paiement, puis renvoyé sur votre site pour terminer la commande. » Direct : « Le client achète et paie directement sur votre site, ce qui nécessite un certificat SSL dans le cadre de la conformité PCI. » Il note que la plupart des passerelles exigent un certificat SSL pour chiffrer les communications entre votre site et les clients, et entre votre site et le processeur, et que la norme PCI DSS s'applique à quiconque stocke, traite ou transmet des données de carte de crédit. Sur une pile auto-hébergée, vous faites ce choix délibérément chaque fois que vous installez un module, ce qui est exactement la flexibilité qui cause des problèmes — personne ne le choisit à votre place, et la valeur par défaut est celle du module tel qu'il est livré.

Ce que le Conseil PCI dit réellement des formulaires intégrés

Le Conseil décrit le SAQ A comme couvrant les commerçants dont les fonctions de données de compte sont entièrement externalisées à des tiers validés et conformes à la norme PCI DSS, où le commerçant ne conserve que des rapports papier ou des reçus contenant des données de compte, et où le commerçant ne stocke, ne traite ni ne transmet aucune donnée de compte sous forme électronique sur ses systèmes ou ses locaux. En janvier 2025, il a retiré les exigences 6.4.3 et 11.6.1 sur la sécurité des pages de paiement, ainsi que l'exigence 12.3.1, du SAQ A, et a ajouté un critère d'admissibilité exigeant que les commerçants confirment que leur site n'est pas vulnérable aux attaques de scripts pouvant toucher leurs systèmes de commerce électronique. Sa FAQ limite ce critère : il « s'applique uniquement aux commerçants de commerce électronique dont la page Web comprend une page ou un formulaire de paiement intégré d'un TPSP ou d'un processeur de paiement (par exemple, une ou plusieurs iframes) » et « ne s'applique pas » lorsque la page du commerçant redirige le client vers le fournisseur — par redirection HTTP 30x, balise meta de redirection ou redirection JavaScript — ou lorsque les fonctions de paiement sont entièrement externalisées, par exemple en envoyant au client un courriel avec un lien pour payer sur le site du fournisseur.

Les scripts tiers sont le risque propre à WordPress

La raison pour laquelle ce critère existe est une réalité propre à WordPress. Un site auto-hébergé accumule des modules, et chaque module qui charge un script sur la page de paiement devient une partie prenante de la page de paiement, que ce soit voulu ou non. Un paiement par formulaire intégré comporte donc l'obligation de pouvoir dire quelque chose de défendable sur ce qui s'exécute à ses côtés. Un paiement par redirection déplace entièrement la saisie de la carte hors de votre page, ce qui explique pourquoi le critère du Conseil ne s'y applique pas. Aucune des deux options n'est automatiquement la bonne — une redirection vous coûte la continuité du paiement, et c'est une véritable question de conversion — mais les deux ont des conséquences de conformité différentes et devraient être choisies en tenant compte des deux aspects. Notre comparaison des SAQ précise vers quel questionnaire chaque forme de paiement pointe.

Les paramètres à corriger avant le lancement, et pourquoi

Quelle que soit la forme choisie, les règles des réseaux de cartes s'appliquent toujours à ce que le module envoie. Un commerçant doit soumettre une demande d'autorisation pour le montant final de la transaction lorsque ce montant est connu et qu'il dépasse la limite plancher applicable, et au-dessus de cette limite, le montant de compensation et le montant d'autorisation doivent correspondre, sauf si la transaction relève d'une des exceptions listées par Visa. Sur une boutique WooCommerce, cela signifie que le comportement de capture, les remboursements partiels et tout changement de montant après l'achat doivent être testés avant le lancement, pas après la première plainte. Le Tableau 5-14 de Visa exige aussi qu'un commerçant soumette une annulation d'autorisation lorsque le montant final de la transaction est inférieur à la somme des montants autorisés. Testez un refus, un remboursement partiel, un remboursement complet et une mise à jour de carte enregistrée, et confirmez que la gestion des webhooks du module enregistre les quatre cas.

Un exemple illustratif d'une configuration conforme et d'une autre qui ne l'est pas

Exemple illustratif, chiffres ronds inventés. Deux boutiques installent l'extension du même processeur. La boutique A utilise le flux de redirection; sa page de paiement charge 12 scripts de modules, dont aucun ne touche un champ de carte, et elle se situe hors du critère d'admissibilité relatif aux scripts du Conseil. La boutique B utilise le flux à iframe intégré sur la même page avec les mêmes 12 scripts, et doit maintenant pouvoir confirmer que le site n'est pas vulnérable aux attaques de scripts touchant ses systèmes de commerce électronique. Même processeur, mêmes frais, obligation différente. Décider laquelle vous voulez avant l'installation prend dix minutes de discussion; le découvrir pendant une évaluation, non. Ceci est une information générale et non un avis juridique (17 septembre 2026); confirmez vos exigences de validation auprès de votre acquéreur, qui les fixe.