Passerelle WooCommerce Redsys 32.1.x

Le développement de cette version a coûté 2 300 euros. Le coût cumulé pour cette année est de 37 430 euros. Le coût cumulé depuis la première version est de 236 160 euros, mais le coût pour vous est seulement la licence de 79€.

Nouvelle branche 32.1.x du plugin Redsys pour WooCommerce de WooCommerce.com.

Versions de la branche

• 32.1.0

32.1.0

Nouveau :

• Le rapport d’état de WooCommerce (WooCommerce – État) liste désormais également ce qui est activé dans l’onglet “Paramètres avancés” de Redsys : notifications push, factures séquentielles, codes QR, cartes enregistrées, écrasement des états de commande, règles conditionnelles, abonnements, réconciliation par e-mail, les protocoles de commerce agentique et l’API de l’application de gestion. Les identifiants ne sont jamais imprimés : pour chacun, il est seulement indiqué s’il est configuré ou non. Cela est inclus lors de la copie du rapport pour l’envoyer au support, ce qui est justement l’objectif : une demande de support arrive déjà avec la configuration à l’intérieur.
• Vous pouvez désormais décider si vos clients se voient proposer “Ajouter une carte de crédit pour les abonnements” dans Mon compte – Méthodes de paiement. Jusqu’à présent, cette option apparaissait seule dès qu’un plugin d’abonnement était actif, sans moyen de l’enlever, et ce n’est pas ce que veut tout magasin : dans un magasin où la carte d’abonnement est toujours capturée lors de l’achat, cela n’invitait que le client à enregistrer une carte qui ne serait jamais débitée. Le nouvel interrupteur se trouve dans Redsys – Paramètres avancés – Cartes enregistrées, il est activé pour que rien ne change dans les magasins qui l’offraient déjà, et en le désactivant, seule la carte de 1 clic reste. Cela est également mentionné dans le rapport d’état de WooCommerce.

Sécurité :

• Le plugin écrivait dans son propre fichier de journal l’adresse de la page de “commande reçue” de chaque achat, pour tous les paiements, et cette adresse contient la clé de la commande : le témoin privé que WooCommerce met dans le lien de paiement de l’acheteur et que ce plugin exige avant d’afficher une commande. Quiconque ayant accès en lecture au fichier de journal pouvait donc ouvrir ces commandes et voir le nom, l’e-mail, le téléphone et les adresses qu’elles contiennent. Cela se produisait que l’enregistrement de débogage soit activé ou non dans le magasin, car ce point précis écrivait dans le journal sans vérifier ce paramètre. Maintenant, il respecte le paramètre de débogage comme le reste des enregistrements que le plugin écrit, et la clé est remplacée par “[redacted]” avant d’écrire quoi que ce soit, de sorte qu’elle n’est pas enregistrée même avec le journal activé. Cette substitution a ensuite été appliquée à toutes les lignes de journal du plugin, et pas seulement à celle qui a été signalée : environ quatre-vingt lignes supplémentaires réparties sur les passerelles imprimaient ces mêmes adresses chaque fois que le débogage était actif, y compris celles qui envoient le message complet envoyé à la banque. Les fichiers de journal déjà écrits continuent de contenir ces adresses : si vous les avez, supprimez-les.
• La page qui redirige l’acheteur vers Redsys (et vers Bizum) acceptait n’importe quel numéro de commande écrit dans son adresse, sans vérifier que celui qui le demandait était celui qui avait passé cette commande. Comme les numéros de commande sont consécutifs, quelqu’un pouvait les parcourir et lire les données que le plugin envoie à la banque des commandes d’autres clients : nom, e-mail, téléphone et les adresses de facturation et d’expédition, ainsi que le montant et la description de ce qui a été acheté. À aucun moment un numéro de carte, un code de sécurité ou une clé de signature n’ont été exposés, et par cette voie, il n’était pas possible de payer ou de modifier quoi que ce soit. Cette page exige désormais la clé de la commande que WooCommerce inclut dans le lien de paiement de l’acheteur lui-même, de sorte qu’une demande qui ne correspond pas à la commande reçoit une page “Interdit” au lieu d’être traitée. La même vérification a été ajoutée à la fenêtre contextuelle de paiement de la page de finalisation de l’achat. Signalé par l’équipe de sécurité de Tivify (TVUP Streaming Media), qui a décrit le problème avec clarté et nous a donné le temps de le corriger avant de le rendre public. Merci.
• Les trois boutons de préautorisation de l’écran de commande (autoriser, annuler et encaisser une partie) et la recherche de clients de PayGold acceptaient leurs demandes sans un témoin de sécurité. La vérification des permissions était déjà en place, donc seul un gestionnaire de magasin ou un administrateur pouvait les utiliser et personne d’autre ne pouvait les exécuter, mais un administrateur avec la session déjà ouverte pouvait être trompé pour les déclencher depuis un autre site sans s’en rendre compte. Les quatre vérifient désormais un témoin de sécurité de WordPress, ce qui ferme cette voie.
• Le Protocole de Commerce Agentique pouvait finir activé sans que personne ne l’ait choisi, dans des magasins qui se mettent à jour automatiquement. Il publie des adresses avec lesquelles des machines peuvent parler, donc il est conçu pour être désactivé sauf si vous l’activez vous-même, et maintenant il l’est. Si vous l’aviez activé, pour vous, rien ne change.
• La bibliothèque Google incluse dans le plugin a été mise à jour, ce qui corrige deux défauts dans la partie qui effectue des requêtes réseau.

Mis à jour :

• Lorsque le renouvellement d’un abonnement échoue, la note ajoutée à la commande indique désormais exactement quelle étape a échoué et avec quel code de commerce et terminal l’essai a été effectué. Jusqu’à présent, les six échecs possibles écrivaient la même note, peu informative, ce qui rendait presque impossible de diagnostiquer un renouvellement échoué sans accès au magasin, en particulier dans les magasins où le journal de débogage n’est pas écrit.
• Lorsque Apple Pay ne parvient pas à valider le magasin avec Apple, le journal recueille désormais l’explication d’Apple elle-même et si les fichiers du certificat peuvent être lus. Apple répond avec un générique “Expectation Failed” et met le véritable motif dans le corps de sa réponse, qui n’était jamais enregistré, donc ces échecs étaient une impasse.
• Le plugin distribué ne contient plus les scripts de développement et de compilation du projet, la configuration de son environnement de test local, ses répertoires d’éditeur et de hooks git, son README pour les développeurs ni un document interne de révision de sécurité. Rien de tout cela n’était chargé lorsque le plugin s’exécute, mais cela ne sert à rien sur le serveur d’un magasin. Ce que contient le paquet est désormais vérifié automatiquement, avant chaque publication, contre une liste de ce que le plugin distribue réellement, de sorte que quelque chose qui serait ajouté au projet à l’avenir ne puisse pas voyager à l’intérieur du zip sans que personne ne s’en rende compte.
• La tâche de réconciliation par e-mail existe désormais uniquement tant que cette fonction est activée, et seulement une fois. Avant, elle était créée dans tous les magasins et se réveillait toutes les cinq minutes sans rien faire.
• Toutes les traductions sont à nouveau complètes. Soixante-neuf textes ajoutés par des versions récentes apparaissaient encore en anglais : étiquettes de paramètres, rapport d’état et certains messages qu’un acheteur peut voir. Espagnol, catalan, basque, galicien, français et portugais sont à nouveau à cent pour cent.
• Le témoin qui protège le lien “ajouter une carte” est désormais comparé en temps constant, comme le reste des secrets que ce plugin compare. Chronométrer cette comparaison via Internet n’est pas une attaque praticable, donc il n’y avait rien d’exploitable ; le défaut était l’incohérence, car c’était la seule comparaison qui était restée en arrière lors de la migration des autres pendant le travail de signatures.

Réparé :

• Avec InSite, payer avec une carte que l’acheteur avait enregistrée pouvait encaisser l’argent et pourtant afficher la commande comme échouée. Lorsque la banque approuve un paiement ainsi sans demander à l’acheteur de confirmer avec l’application de sa banque, ce qui se produit avec une carte enregistrée, le plugin cherchait le résultat au mauvais endroit, ne trouvait rien et traitait ce “rien” comme un rejet. Le débit avait déjà été effectué, donc les acheteurs à qui l’on disait que le paiement avait échoué payaient une seconde fois et étaient débités deux fois. Le résultat est désormais lu à partir de la propre réponse signée de la banque, la même que celle utilisée par le reste du paiement. Cela affectait également le paiement classique et celui par blocs, ainsi que les renouvellements d’abonnements. Signalé par deux magasins avec quelques jours d’intervalle, l’un d’eux le traçant jusqu’à la ligne exacte. Merci.
• Dans la passerelle de carte, un paiement effectué avec une carte enregistrée était considéré comme complété avec seulement le numéro d’autorisation, sans vérifier la réponse réelle de la banque qui va à côté. Un paiement rejeté qui avait néanmoins quelque chose dans ce champ marquait donc la commande comme payée, et le magasin envoyait la marchandise sans avoir encaissé. Il est désormais exigé que les deux correspondent avant de compléter une commande. Si la réponse de la banque manque complètement, le paiement n’est pas complété, car il n’y a rien qui indique qu’il a été approuvé ; un magasin dont la banque omet réellement ce champ peut restaurer intentionnellement le comportement précédent avec le filtre redsys_allow_payment_without_ds_response, qui est documenté et qui ne peut pas être utilisé pour accepter un paiement que la banque a rejeté.
• Dans les magasins utilisant certains plugins de finalisation d’achat, Fluid Checkout parmi eux, tous les paiements étaient rejetés par Redsys avec l’erreur SIS0574. La banque exige une brève description du navigateur de l’acheteur avec chaque paiement (sa langue, la taille de son écran et similaires), que le plugin recueille via des champs cachés qu’il ajoute au checkout. Ces champs étaient ajoutés au moment où la passerelle de carte était construite, ce qui dans ces magasins se produit après qu’un autre plugin ait déjà demandé à WooCommerce la liste définitive des champs du checkout, et WooCommerce construit cette liste une seule fois et jamais plus. Les champs, donc, n’étaient pas créés, n’étaient pas remplis et n’étaient pas envoyés, et la banque rejetait le paiement. Ils sont maintenant ajoutés dès que le plugin se charge, avant que quiconque puisse demander la liste, ce qui affecte toutes les passerelles qui en ont besoin, celle de la carte, Bizum et les portefeuilles, et pas seulement InSite. Dans InSite, la description du navigateur voyage également maintenant avec le reste des données de paiement au lieu de dépendre uniquement de la commande, de sorte qu’elle survive à un checkout qui se reconstruit lui-même. Signalé par un intégrateur qui avait déjà apporté le diagnostic prouvé. Merci.
• Si un paiement était annulé ou rejeté, l’acheteur revenait au magasin mais la commande restait en attente et le panier n’était pas restauré. L’adresse que le plugin donnait à la banque pour renvoyer l’acheteur était écrite dans la forme utilisée pour les liens à l’intérieur d’une page web, pas dans celle utilisée pour une adresse réelle, donc le magasin recevait le retour sans la référence de la commande, sans son numéro et sans son témoin de sécurité, et n’avait rien à annuler. Cela affectait Bizum, Google Pay, Apple Pay, prélèvement bancaire, virement, InSite et la passerelle de carte tant que le paramètre “retour à” est réglé sur annuler la commande. Dans MasterPass, cette même adresse était envoyée directement vide, en raison d’une erreur d’écriture d’un seul caractère répété sur trois lignes. Tout passe désormais par un unique morceau de code partagé, de sorte qu’une passerelle ajoutée à l’avenir ne puisse pas se tromper à nouveau.
• Dans le mode de paiement en fenêtre contextuelle (modal), annuler un paiement ne faisait rien et l’acheteur restait dans le panier avec la commande en attente. L’adresse à laquelle le plugin envoyait le navigateur était écrite sur la page d’une manière que le navigateur interprète comme un lien à l’intérieur d’un document et non comme une adresse web, donc tout ce qui venait après le premier paramètre était rejeté : la référence de la commande, son numéro et son témoin de sécurité disparaissaient, et WooCommerce n’avait rien à annuler. Le même défaut affectait l’adresse à laquelle l’acheteur est renvoyé après avoir payé, où il perdait silencieusement un paramètre de suivi. Les deux sont corrigés, dans la passerelle de carte et dans celle d’InSite, et le comportement corrigé a été vérifié dans un navigateur réel.
• Le checkout pouvait mourir avec une erreur critique, au lieu d’envoyer l’acheteur à la banque, avec un client enregistré dont la fiche client n’avait jamais été modifiée depuis sa création. Le plugin construit un ensemble de données de sécurité pour la banque à chaque paiement, et l’un des champs est la date à laquelle le compte client a été modifié pour la dernière fois, que WooCommerce laisse vide dans un compte qui n’a jamais été touché, normalement créé par une importation, une migration ou automatiquement par un autre plugin. Le plugin lisait cette date vide comme si c’était une date réelle et la page de paiement s’arrêtait là. Maintenant, il recourt à la date de création du compte, qui est ce que signifie “jamais modifié”, et la même protection a été ajoutée au code équivalent utilisé pour les abonnements, où cette même date vide était silencieusement rapportée à la banque comme “modifiée aujourd’hui”, ce qui est une information incorrecte pour ses contrôles de fraude.
• Redsys et les autres passerelles pouvaient disparaître du checkout pour tout le monde, y compris les acheteurs normaux, dans des magasins où la liste “afficher uniquement à ces utilisateurs” du mode de test n’avait jamais été remplie. Le plugin lisait ce paramètre vide comme “l’afficher à un utilisateur dont l’id est rien”, ce qui ne correspond à personne, donc la méthode de paiement restait cachée pour tous les visiteurs. Cela n’affectait que les

• Des magasins dont les paramètres auraient été écrits par autre chose que l’écran de paramètres, une importation, une migration ou l’API de gestion du plugin elle-même, car sauvegarder cet écran manuellement stocke une valeur vide différente qui ne l’a jamais provoquée. Corrigé dans les neuf passerelles qui partageaient le même code.
• Les abonnements payés avec Apple Pay ou Google Pay par un client sans compte n’obtenaient jamais de la banque l’autorisation de paiement récurrent, donc le premier renouvellement échouait avec une note disant qu’il n’y avait pas de carte. Cela se produisait dans des magasins où l’option générale « permettre aux clients de créer un compte lors du paiement » est désactivée, ce qui est courant dans les magasins qui acceptent l’achat en tant qu’invité : les chemins de paiement des portefeuilles ne voyaient pas la surcharge que fait cette option par WooCommerce Subscriptions lui-même, donc aucun compte n’était créé et, sans compte, l’autorisation de la banque ne pouvait pas être sauvegardée. Corrigé dans les quatre sites qui le gèrent (Apple Pay et Google Pay, tant dans le paiement classique que dans celui par blocs).
• Le script de paiement du paiement par blocs était compilé contre une version de React que WordPress lui-même n’accepte pas. Une dépendance uniquement de développement entraînait un React plus récent dans la compilation, et WordPress rejette les éléments produits par celui-ci, donc la méthode de paiement pouvait ne pas apparaître dans le paiement par blocs. La compilation fixe maintenant la version utilisée par WordPress et le script a été régénéré.
• Le panier et le paiement pouvaient devenir remarquablement lents, même pour les visiteurs non identifiés, dans des magasins avec des cartes enregistrées ou des abonnements. L’assistant interne WCRed() du plugin construisait une nouvelle copie de son objet global chaque fois qu’il était appelé, et cet objet enregistre trois hooks de WordPress au moment de sa construction. WordPress ne remplace pas ces hooks, il les ajoute, donc dans un magasin où l’assistant est appelé une fois pour chaque carte enregistrée ou abonnement, les mêmes trois vérifications finissaient par être enregistrées des centaines de fois et étaient réexécutées, toutes, chaque fois que WooCommerce montait la liste des passerelles de paiement disponibles. Dans un magasin qui a signalé le problème, cela atteignait environ 438 enregistrements dupliqués par chargement de page et près de 1,7 secondes de travail PHP sur la page du panier, dont seulement 56 millisecondes étaient des requêtes à la base de données. L’assistant construit maintenant cet objet une seule fois et le réutilise, de sorte que les hooks sont enregistrés exactement une fois par requête. Le comportement du plugin ne change en rien : l’objet ne conserve pas de données propres à chaque requête. Le même traitement d’un objet par requête a été appliqué à l’assistant WCPSD2(), qui avait la même forme identique.
• Dans une petite partie des magasins, la clé de signature des messages de Commerce Agéntico (UCP) était sauvegardée d’une manière qui ne pouvait jamais être utilisée, donc toute vérification de signature contre elle échouait et le document de clé publié ne respectait pas la norme. Lorsque le plugin créait cette clé, une de ses deux coordonnées revenait de temps en temps d’OpenSSL un octet plus courte que ce que la norme exige, environ 1 magasin sur 135, et le plugin la sauvegardait telle quelle au lieu de la remplir. Depuis ce moment, le magasin ne pouvait pas vérifier ses propres signatures, ni aucun agent externe, jusqu’à ce que la clé soit renouvelée. La clé est maintenant sauvegardée remplie jusqu’à la longueur exigée, et une clé déjà sauvegardée sous la forme courte est automatiquement réparée la première fois qu’elle est lue, donc aucun commerçant n’a besoin de renouveler quoi que ce soit.
• Dans des magasins avec PHP 8.0 ou antérieur, activer la réconciliation par e-mail cassait la page avec une erreur de serveur au lieu de simplement ne pas fonctionner. Le plugin le vérifie maintenant avant et laisse une note claire dans son journal. La fonction elle-même nécessite toujours PHP 8.1.
• Les tâches en arrière-plan s’accumulaient en dizaines de copies d’elles-mêmes dans la liste des actions programmées de WooCommerce. Corrigé dans tous les sites où le plugin programme quelque chose, et les copies qui y étaient déjà sont automatiquement nettoyées.
• Une notification à l’application mobile pouvait se perdre sans donner d’erreur si elle était envoyée au mauvais moment.
• Des avertissements PHP apparaissaient dans le journal du serveur à chaque visite de la page « payer commande », provenant des passerelles Apple Pay et Google Pay. Pour les acheteurs, rien n’était cassé, mais le journal de débogage de ces passerelles n’enregistrait rien de cette étape, donc quiconque essayait de diagnostiquer un problème là-bas regardait un échec et non un silence. Signalé par un commerçant, et trouvé dans trois passerelles au lieu de celle qui a été signalée. Merci.
• Activer le journal de débogage pour enquêter sur un problème de paiement par carte produisait des avertissements au lieu des informations pour lesquelles il avait été activé.
• Le bouton « Se connecter avec Google » des paramètres de réconciliation par e-mail ne s’affichait jamais. Accorder l’accès était déjà possible en remplissant les informations de Google et en cliquant sur « Enregistrer les modifications », donc cela restaure un raccourci, ne débloque pas la fonction.
• Le plugin envoyait au magasin un e-mail disant « Redsys n’envoie pas de champs de tokenisation » après des paiements où Redsys avait envoyé chacun d’eux. La vérification derrière cet avis testait une variable qui n’existe nulle part dans le plugin, et un test sur quelque chose qui n’existe pas est toujours vrai, donc l’avis apparaissait à chaque paiement qui sauvegardait une carte. Les commerçants l’emmenaient à leur banque, qui répondait à juste titre que le terminal était en bon état. L’avis informe maintenant uniquement des absences réelles, et indique dans le journal quel champ manquait, la date d’expiration, la marque de la carte ou le numéro, au lieu de dire uniquement qu’il manquait quelque chose. Il a également dû cesser de lire la marque après que le plugin l’ait convertie en un nom à afficher, car cette conversion répond « Inconnu » lorsqu’il n’y a pas de marque, ce qui aurait rendu l’avis impossible à apparaître. Ce même bloc écrivait « inconnu » comme numéro de carte dans le journal de débogage à chaque paiement, à cause d’un nom de variable avec une lettre de trop ; maintenant il écrit le numéro masqué réel.
• Rechercher dans l’écran des tokens de Redsys (WooCommerce – Tokens Redsys) par e-mail ou par nom d’utilisateur ne trouvait aucune carte sauvegardée à partir de la vingt-cinquième. L’écran demandait à la base de données une page de tokens et cherchait ensuite à l’intérieur de cette page, et comme il les demandait sans aucun ordre spécifique, cette page était toujours les vingt-cinq tokens les plus anciens du magasin, donc les cartes récemment sauvegardées, qui sont les seules que quelqu’un recherche, devenaient inaccessibles. La recherche se fait maintenant dans la base de données, sur tous les tokens, et la liste arrive du plus récent au plus ancien. Le compteur au-dessus du tableau et la liste en dessous ne peuvent plus différer, trier par nom d’utilisateur ou par e-mail trie maintenant tout le tableau au lieu de la page visible, et l’écran ne charge plus en mémoire tous les tokens du magasin juste pour les compter, ce qui dans des magasins avec des milliers de cartes sauvegardées se produisait à chaque chargement de page.