Le développement de cette version a coûté 2.800 euros. Le coût cumulé pour cette année est de 13.350 euros. Le coût cumulé depuis la première version est de 212.080 euros, mais le coût pour vous est seulement la licence de 79€.
Nouvelle version 31.0.0 du plugin Redsys pour WooCommerce de WooCommerce.com.
31.0.0
Nouveau :
- Nouvelle surface du protocole A2A (Agent2Agent). Optionnel et désactivé par défaut. Publie une Agent Card dans /.well-known/agent-card.json et un endpoint JSON-RPC 2.0 dans /wp-json/wc-redsys-a2a/v1/rpc avec sept compétences : query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card et recurrent_charge. L'authentification réutilise le serveur d'autorisation OAuth 2.1 + PKCE de UCP avec des scopes a2a:payments:* (et un bearer de sandbox optionnel pour les tests sous WP_DEBUG).
- Stream d'événements envoyés par le serveur réactivable dans /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream pour des mises à jour de tâches en direct, avec reprise via Last-Event-ID et des battements (heartbeats) toutes les 15s.
- Notifications push sortantes signées à une push_url enregistrée par le client. En-tête X-A2A-Signature : sha256=<hmac> sur <timestamp>.<body>, avec des réessais à 1m/5m/30m/2h (maximum 4), livrées via Action Scheduler.
- Nouvel onglet d'administration "A2A (Agent2Agent)" dans Redsys Avancé -> Agentic Commerce, avec État / Clients (créer / révoquer / faire tourner des bearers de sandbox) / Limites et modes (max_amount, sensitive_threshold et modes de paiement exposés) / Confirmations (approuver les remboursements ou les charges récurrentes arrêtées dans input-required).
- Plafonds par compétence : max_amount est une limite maximale stricte qui échoue la tâche avec limit_exceeded ; sensitive_threshold arrête la tâche dans input-required jusqu'à ce qu'un administrateur la confirme. Les deux sans limite par défaut (optionnel).
- Journal d'audit uniquement en ajout (append-only) dans wp_redsys_a2a_audit_log. Les payloads bruts ne sont jamais stockés : seulement un hash SHA-256 plus un résumé assaini d'une ligne qui masque PAN, tokens, secrets et la partie locale des emails.
- Stockage auto-réparable. Les quatre tables A2A sont recréées à la demande via le ensure_table() de chaque store, de sorte qu'une table supprimée ne provoque jamais d'erreur fatale.
- Support pour les agents d'achat avec IA (ChatGPT, Claude, Gemini, Perplexity et autres). Les agents IA peuvent désormais découvrir vos produits, créer des paniers, finaliser des paiements et recevoir des mises à jour de commandes depuis votre boutique. Les normes ACP d'OpenAI/Stripe ainsi que la norme ouverte UCP (soutenue par Google, Shopify et autres) sont prises en charge, et chacune peut être activée ou désactivée indépendamment.
- Nouvelle sous-section "Agentic Commerce" dans les paramètres de Redsys Avancé, avec des interrupteurs par fonction (paniers, remises, fulfillment, consentement de l'acheteur, enregistrement dynamique des clients, etc.) et des boutons à un clic pour tester les flux de découverte des agents, OAuth et webhook.
- Signature des webhooks avec un bouton "Faire tourner la clé de signature". Les clés tournées restent valides pendant 7 jours pour que les intégrations existantes continuent de fonctionner pendant la transition.
- Le modal des champs personnalisés d'Express (Apple Pay / Google Pay) collecte désormais également les champs enregistrés via l'API de Blocks dans les checkouts classiques, de sorte que NIF/DNI et champs similaires apparaissent toujours indépendamment du checkout que vous utilisez.
- Action massive optionnelle "Approuver la préautorisation" pour la liste des commandes (Redirection Redsys). Désactivée par défaut pour des raisons de sécurité ; activez-la dans les paramètres de la passerelle uniquement si vous devez confirmer des commandes préautorisées en masse.
Remarque :
- Activer ce support NE signifie PAS que les assistants IA vont commencer à finaliser des achats dans votre boutique dès le premier jour. Le flux complet de checkout dirigé par des agents est encore en cours de déploiement, notamment en Europe, où les exigences SCA/3DS, PSD2 et le consentement RGPD font que la plupart des agents s'arrêtent aujourd'hui à la découverte de produits ou au pré-panier et renvoient le paiement final au client. Votre boutique est prête pour le jour où chaque agent activera le flux complet sur votre marché.
Mis à jour :
- Le modal des champs personnalisés d'Express précharge désormais sa configuration lors du chargement de la page et lance Apple Pay de manière synchrone au clic, corrigeant les cas où iOS Safari annulait la feuille de paiement.
- Les champs personnalisés d'Express sur la page produit réutilisent à nouveau le modal par défaut. Le formulaire en ligne introduit dans 30.4.1 est désormais optionnel via un filtre.
Corrigé :
- [Critique] Les renouvellements d'abonnements pouvaient échouer avec l'erreur Redsys SIS0502 ("Id Oper ne correspond pas") sur des hébergements avec Redis, Memcached ou d'autres caches d'objets persistants. Deux workers de renouvellement en parallèle pouvaient envoyer deux références de commande distinctes à Redsys pour le même abonnement, provoquant l'échec du renouvellement et de multiples réessais. Le blocage de paiement en double et la référence de commande sont désormais stockés de manière fiable indépendamment du backend de cache. Cela affecte les passerelles de Redirection et InSite de Redsys.
- Les renouvellements d'abonnement InSite n'avaient aucune protection de concurrence (le verrou était supprimé en cas d'erreurs mais jamais créé). La même protection utilisée par la passerelle de redirection s'applique désormais aux renouvellements InSite.
- L'état interne mis en cache utilisé pendant le checkout (données 3DS, identifiant de carte enregistrée, cache de signature, état OAuth, état temporaire IMAP, etc.) est désormais stocké de manière à fonctionner correctement sur des hébergements avec des caches d'objets persistants. Auparavant, sur des caches mal comportés, cet état pouvait disparaître silencieusement au milieu du checkout et provoquer des erreurs SIS0502.
- Les boutons Express d'Apple Pay et Google Pay (checkout de blocs et page produit) échouaient sur iOS Safari avec "Must create a new ApplePaySession from a user gesture handler" lorsque le modal des champs personnalisés d'Express était activé. Le modal ne consomme plus le clic de l'utilisateur avant de lancer Apple Pay.
- L'IRPF des Autonomes Premium était mal calculé dans le Paiement Express (Apple Pay / Google Pay) sur la page produit lorsque le client choisissait le type d'utilisateur dans le modal d'Express, car la sauvegarde du modal était en concurrence avec le premier appel du serveur d'Apple Pay. Le type d'utilisateur est désormais envoyé avec chaque demande de Paiement Express, de sorte que les totaux sont toujours corrects.
- Sur les pages de produit avec des produits virtuels, la feuille d'Apple Pay affichait brièvement le total correct (sous-total + taxes) puis revenait au prix du produit hors taxes. Le callback d'envoi maintient désormais le dernier total renvoyé par le serveur.
- Lors de la sauvegarde des paramètres d'Agentic Commerce, l'envoi "Sauvegarder les modifications" de WooCommerce était silencieusement rejeté à cause de formulaires HTML imbriqués. La page des paramètres a été restructurée et tous les boutons d'action unique (tester la découverte, tester OAuth, actions de webhook, etc.) fonctionnent désormais correctement avec le bouton principal de Sauvegarder.
- Les boutons Express d'Apple Pay et Google Pay sur la page produit assignaient la zone d'expédition incorrecte lorsque la région du client était restreinte par province. Apple/Google Pay envoient le nom localisé de l'état (par exemple, "Barcelone") dans administrativeArea, mais les zones d'expédition de WooCommerce correspondent par code d'état (par exemple, "B") ; la zone pays-par-état ne correspondait pas et le panier tombait dans une zone plus chère (par exemple, "Reste de l'Europe"). Les noms d'état sont désormais normalisés en codes d'état de WooCommerce avant la recherche de zone d'expédition et la création de la commande.
- Le checkout InSite avec Blocs pouvait créer des commandes dupliquées lorsque Redsys émettait le même postMessage de token de paiement plus d'une fois (ou lorsque la sauvegarde était exécutée de manière concurrente). Une protection empêche désormais la création de commandes dupliquées/concurrentes et se réinitialise si le formulaire de paiement est rafraîchi après une erreur.
- Le journal de débogage REST d'InSite faisait référence à l'objet incorrect pour lire le flag de débogage, de sorte que le payload "REST traitePeticion" pouvait être enregistré (ou sauté) indépendamment du réglage de débogage de la passerelle. Il utilise désormais le propre flag de débogage de la passerelle.
31.0.1
Mis à jour :
- Le compte à rebours du modal de Bizum sur la page de paiement affichait 7 minutes. Il affiche maintenant correctement 5 minutes, et le contrôle de temps côté serveur qui redirige vers le checkout a été ajusté en conséquence (60 itérations * 5 secondes = 5 minutes).
Corrigé :
- Bizum sur la page de paiement (Bizum InSite) n'envoyait pas la description à Redsys. Le prélèvement réel depuis le modal se fait via l'API REST (trataPeticionREST), et cette requête n'incluait pas le paramètre DS_MERCHANT_PRODUCTDESCRIPTION, ce qui faisait que la "Description de Redsys" configurée (par exemple "ID de commande") arrivait vide au panneau de Redsys. La description est maintenant calculée à partir de l'ajustement sélectionné et est envoyée dans la requête REST.
31.0.2
Sécurité :
- La clé secrète SHA-256 du commerce n'est plus écrite en texte clair dans les journaux de débogage de WooCommerce. Toutes les entrées de débogage masquent maintenant la clé, ne montrant que ses 4 derniers caractères, grâce au nouvel helper WCRed()->mask_secret(). Appliqué à toutes les passerelles (Redirection, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliation Bancaire et les classes de support de Blocks).
- Les signatures des notifications (IPN) de Redsys sont maintenant vérifiées avec hash_equals() (comparaison en temps constant) dans tous les gestionnaires de notifications, les unifiant avec la vérification déjà utilisée par InSite et le client REST. Durcissement contre les attaques par temporisation (timing attacks).
- Le gestionnaire AJAX de suppression d'un seul token sur l'écran de gestion des tokens nécessite maintenant la capacité manage_woocommerce en plus du nonce, l'alignant sur le gestionnaire de suppression massive.
Mis à jour :
- Le filtre redsys_modify_data_to_send reçoit maintenant 'context' => 'add_payment_method' et 'user_id' dans le tableau de données pour le flux de "Ajouter un moyen de paiement", afin que les snippets personnalisés et les règles conditionnelles puissent acheminer la tokenisation vers le terminal correct (terminal + SHA256) sans dépendre d'une commande qui n'existe pas dans ce flux.
- Toutes les traductions ont été mises à jour.
Corrigé :
- Ajouter une carte depuis Mon Compte ("Ajouter un moyen de paiement") dans des magasins multidevises pouvait être rejeté par Redsys avec une erreur de devise. La requête était envoyée avec la devise de la session du client (par exemple ARS, 32) mais avec le terminal par défaut, qui est configuré pour une autre devise (par exemple EUR, 978). La tokenisation de carte est une opération de montant zéro sans commande derrière, donc si aucun filtre ou règle conditionnelle n'achemine la requête vers un autre terminal, la devise de base du magasin est maintenant envoyée, correspondant toujours à la configuration du terminal par défaut.
- Ajouter une carte depuis Mon Compte (ou via le lien email du profil) enregistrait toujours la carte dans Redsys comme one-click (DS_MERCHANT_COF_TYPE 'C'), même lorsque le client sélectionnait l'option d'abonnements. Le type de token était lu à partir de la clé interne incorrecte, donc 'R' n'était jamais envoyé. Le token était correctement enregistré comme R dans WooCommerce, mais l'accord COF était créé comme C dans Redsys, ce qui pouvait entraîner le rejet de renouvellements d'abonnement (MIT) ultérieurs effectués avec ces tokens par certains émetteurs. Les cartes ajoutées avec l'option d'abonnements envoient maintenant correctement DS_MERCHANT_COF_TYPE 'R'. Les tokens créés pendant que l'erreur était présente ne peuvent pas être reclassés ; si un renouvellement est rejeté, demandez au client de réajouter la carte.
- Les paiements effectués avec une carte enregistrée (token R) et les renouvellements d'abonnement ne respectaient pas les réglages de préautorisation. Avec "Préautoriser toutes les commandes" activé (ou un produit marqué pour préautorisation), le prélèvement était exécuté comme une vente normale (type 0) mais la commande était également marquée comme "Préautorisée", de sorte que la confirmation de la préautorisation échouait plus tard dans Redsys avec SIS0059 ("Aucune opération sur laquelle effectuer la confirmation"). Les deux flux envoient maintenant une préautorisation réelle de type 1 qui peut être confirmée par la suite, et une commande n'est marquée comme "Préautorisée" que lorsqu'une préautorisation réelle a été exécutée. Cela permet également les renouvellements d'abonnement préautorisés (par exemple biens vendus au poids, où chaque renouvellement est ajusté avant le prélèvement final).
31.0.3
Nouveau :
- Section "Apps et Plugins" dans Redsys Avancé -> Réglages Avancés de Redsys. Une page d'atterrissage en lecture seule qui montre l'application native de gestion pour macOS (avec téléchargement, exigences et plateformes "à venir") et liste le reste des plugins gratuits et premium, sites web et portails, compétences de Claude et profils de développeur de José Conti, chacun regroupé par type avec un lien. Chaque liste est filtrable (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
Sécurité :
- Un contournement de vérification de signature de notification a été supprimé, ce qui pouvait permettre à une requête anonyme de marquer une commande comme payée lorsque le secret SHA-256 était laissé vide ou mal configuré. Le listener IPN de Redsys (point d'accès public wc-api) avait un fallback hérité qui, lorsqu'aucun secret n'était configuré, acceptait une notification uniquement parce que le Ds_MerchantCode envoyé correspondait au FUC du commerce, une valeur publique et non secrète qu'un attaquant peut fournir. Cette acceptation basée uniquement sur le code de commerce a été supprimée de toutes les passerelles (Redirection, Bizum, Bizum InSite, Google Pay checkout et redirection, Apple Pay, PayGold, Domiciliation Bancaire, MasterPass et Virement Bancaire) : lorsqu'il n'y a pas de secret pour vérifier le HMAC, la requête échoue maintenant de manière sécurisée (rejet HTTP) au lieu d'être considérée comme fiable. De plus, la routine de vérification partagée (WooRedsysAPI::verify_signature_notif) renvoie maintenant false chaque fois que la clé du commerce ou la signature reçue sont vides, de sorte que ni check_ipn_request_is_valid() ni successful_request() ne peuvent compléter un paiement avec un HMAC de clé vide calculable par l'attaquant. InSite exigeait déjà une signature valide (sans fallback par code de commerce) et Inespay n'est pas affecté (relie les commandes par son propre id de payin). Les magasins réels ne sont pas affectés, car avoir un secret configuré est obligatoire pour pouvoir encaisser.
Corrigé :
- Les notifications de Bizum étaient rejetées avec une erreur de vérification de signature, laissant la commande non payée bien que le paiement ait été autorisé dans Redsys. La clé du commerce et le numéro de commande étaient corrects (la signature de la requête correspondait parfaitement), mais la signature de la notification est un HMAC calculé sur la chaîne Ds_MerchantParameters exactement comme elle est reçue, et les notifications de Bizum arrivent avec le remplissage (padding) final "=" de base64 supprimé, tandis que Redsys signe sur la valeur avec le padding canonique, donc le HMAC calculé localement ne correspondait jamais. La routine de notification partagée (create_merchant_signature_notif dans WooRedsysAPI) remplit maintenant à nouveau le payload à un multiple de quatre avant de hasher, et la vérification (verify_signature_notif) compare maintenant les deux signatures en ignorant le padding final "=" (qui n'apporte pas d'entropie, donc la comparaison reste en temps constant). Les payloads de carte sont déjà canoniques et restent intacts, de sorte que le reste des passerelles continue de fonctionner sans changements. Cette routine est partagée par tous les gestionnaires de notification (Redirection, Bizum, InSite, PayGold, Google Pay, Apple Pay, Domiciliation Bancaire, Virement Bancaire et les clients REST/A2A).
- Les notifications de carte et de portefeuille pouvaient être rejetées avec un "signature mismatch", de sorte que le client revenant à la page de remerciements (et l'IPN serveur à serveur) ne parvenait pas à marquer la commande comme payée jusqu'à ce qu'une nouvelle tentative ultérieure d'IPN réussisse par hasard ; les remboursements et les liens de PayGold payés plus tard pouvaient rester non confirmés. Il y a deux problèmes de padding impliqués : en plus du padding du payload de Bizum précédent, Redsys fournit la signature de la notification (Ds_Signature) en base64 URL-safe avec le "=" final supprimé, tandis que la signature calculée localement le maintient, donc une comparaison stricte échoue également pour les paiements de carte normaux. La comparaison tolérante au padding se trouve dans verify_signature_notif(), mais la plupart des gestionnaires continuaient à comparer la signature en ligne avec un hash_equals()/!== strict qui réintroduisait la sensibilité. Maintenant, tous les gestionnaires délèguent à verify_signature_notif(), de sorte que la correction atteint tout le monde : Redirection de carte (les deux validateurs d'IPN et les vérifications de réponse REST-SOAP de capture/remboursement), Bizum, Bizum InSite, InSite (IPN, successful_request et les deux validateurs de réponse REST), PayGold, Google Pay (checkout et redirection), Apple Pay, Domiciliation Bancaire, Virement Bancaire, MasterPass et le client REST d'InSite. Régression introduite lors de l'unification des vérifications de signature par passerelle dans verify_signature_notif() avec une comparaison stricte et sensible au padding.
- Les notifications de Bizum dans des magasins multidevises / à double terminal (celles qui acheminent chaque commande vers un terminal distinct via le filtre bizum_modify_data_to_send ou une règle conditionnelle) résolvent maintenant la clé de signature réelle par commande avant de vérifier la signature (la clé des réglages ajustée par le client, le transient enregistré lors de la génération du formulaire de paiement, ou le méta de commande _redsys_secretsha256), et une notification non vérifiable est rejetée avec HTTP 400.
- Les paiements par carte InSite nécessitant un challenge 3DS affichaient un écran de vérification blanc sur Safari (iPhone/Mac), empêchant le client de saisir le code SMS/PIN et entraînant l'échec du paiement (le même flux fonctionnait sur Chrome). Le challenge lui-même était déjà une navigation de page complète et de niveau supérieur, mais avant cela, le plugin redirigeait le navigateur vers l'URL du 3DS Method de l'émetteur (threeDSMethodURL) pour prendre l'empreinte du navigateur, et la Prévention de Suivi Intelligent (ITP) de Safari bloque les cookies tiers nécessaires à cette étape, laissant une page ACS blanche (symptôme : l'URL de l'ACS arrive avec ";jsessionidpa=" car les cookies ne circulent pas). L'étape du 3DS Method dans le navigateur est optionnelle, donc le plugin ne redirige plus le navigateur vers threeDSMethodURL : il envoie toujours threeDSCompInd = 'N' et passe directement à l'authentification. Appliqué à tous les flux InSite – nouvelle carte et carte enregistrée (one-click/token), tant dans le checkout de blocs que classique (shortcode) – et aux flux REST/token de la passerelle de Redirection (pay_with_token_c, receipt_page et successful_request), car le même écran blanc pouvait apparaître lors de la facturation d'un token de carte enregistrée.
- Lorsque le paiement par carte InSite échouait en raison d'un champ obligatoire manquant dans le checkout ou de données non correspondantes (par exemple, un nom de famille vide produisait un "signature mismatch"), le message d'erreur blâmait la carte ("…veuillez ressaisir les données de votre carte"), ce qui amenait les clients à penser que leur carte avait été refusée et à abandonner la commande. Le message est maintenant neutre et pointe d'abord vers les champs du checkout : il demande au client de vérifier que tous les champs du checkout (prénom, nom, adresse, etc.) et les données de la carte sont correctement remplis avant de réessayer. Appliqué aux checkouts classique et de blocs (Blocks).
- Les remboursements et paiements différés des commandes avec de grands IDs de commande (le "bug des milliards" déjà corrigé pour le checkout instantané) étaient enregistrés contre la mauvaise commande, ou n'étaient pas enregistrés du tout. La notification (IPN) de Redsys récupère l'ID de commande de WooCommerce à partir du numéro de commande via clean_order_number(), qui cherche d'abord un transient enregistré lorsque le numéro de commande a été généré et, à défaut, recourait à une heuristique substr/ltrim qui écartait les chiffres de commande élevés des IDs de 10 chiffres ou plus. Ce transient a un TTL de 1h, donc le fallback s'activait chaque fois que la notification arrivait plus d'une heure après la génération du numéro de commande : chaque remboursement (traité des jours ou semaines plus tard) et les liens de paiement de PayGold (payés par le client plus tard), entre autres. Trois changements le rendent robuste pour tous les méthodes de paiement : (1) la routine de remboursement partagée (ask_for_refund) enregistre maintenant à nouveau le mappage numéro de commande -> ID réel de commande au moment du remboursement avec un TTL de 24h ; (2) clean_order_number(), lorsque le transient n'existe plus, recherche maintenant la commande de manière inverse par le méta persistant du numéro de commande (_payment_order_number_redsys / _redsys_transaction_id2) avant d'utiliser jamais l'heuristique avec perte ; et (3) PayGold persiste maintenant le numéro de commande dans le méta lors de la création du lien, de sorte qu'un lien payé beaucoup plus tard continue de se résoudre à la commande exacte. Cela s'applique à toutes les passerelles (Redirection, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold et Domiciliation Bancaire). Inespay n'est pas affecté (il relie les commandes par son propre id de payin).
- Les paiements par carte InSite dans le checkout de blocs (Blocks) échouaient la PREMIÈRE fois avec "msg18" (le client voyait "vérifiez que les champs du checkout/carte sont remplis") et ne fonctionnaient qu'au deuxième essai. Le SDK InSite de Redsys nécessite que la page envoie un message "domain" à l'iframe de la carte pour que Redsys puisse valider le commerce ; le SDK le fait via un onload="setMerchantDomain(0)" en ligne dans l'iframe. Le script de blocs écrasait ce gestionnaire avec son propre iframe.onload (utilisé pour dimensionner l'iframe) juste après le premier rendu, donc le domaine du commerce n'était jamais envoyé et Redsys rejetait la tokenisation avec msg18 ("validation incorrecte par le commerce"). Lors du rafraîchissement automatique du formulaire, l'écrasement ne s'exécutait pas, donc le deuxième essai fonctionnait. Le plugin appelle maintenant explicitement setMerchantDomain après avoir construit le formulaire (comme le fait l'intégration du bouton de paiement du SDK) et n'écrase plus l'onload de l'iframe, de sorte que le premier essai fonctionne.
- Checkout InSite de blocs : la gestion du postMessage de Redsys a été rendue plus robuste et des diagnostics de bout en bout ont été ajoutés. Le gestionnaire accepte maintenant des messages de n'importe quel sous-domaine de Redsys (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) au lieu d'exiger une correspondance exacte d'hôte/port (Redsys publie depuis plus d'un hôte), élimine tout listener laissé par un rendu précédent afin qu'un seul token ne puisse pas déclencher plusieurs envois, et nettoie les champs de token/erreur après les avoir lus pour qu'un re-déclenchement obsolète ne puisse pas les renvoyer. Lorsque l'enregistrement de débogage d'InSite est activé, tout le processus de tokenisation côté client (numéro de commande, postMessage de Redsys, token/code d'erreur, sauvegarde et place-order) se reflète dans le log "insite" de WooCommerce, de sorte que les échecs du premier essai qui n'atteignent jamais PHP puissent être diagnostiqués.
- Les paiements par carte InSite dans le checkout de blocs (Blocks) étaient rejetés par Redsys avec SIS0574 ("opération d'authentification EMV3DS rejetée, browserUserAgent non indiqué") : l'empreinte 3DS du navigateur (user agent, taille d'écran, langue, profondeur de couleur, fuseau horaire) n'arrivait jamais à la commande, car le hook qui la copie normalement à la commande (woocommerce_checkout_create_order) ne s'exécute pas dans le checkout de l'API Store (Blocks). Le formulaire InSite de Blocks collecte maintenant l'empreinte et l'envoie avec le token d'opération, et elle est écrite dans la commande réelle (avec le token) avant que process_payment ne soit exécuté, de sorte que l'authentification EMV3DS dispose des données nécessaires.
- Les paiements par carte InSite dans le checkout de blocs (Blocks) étaient rejetés avec un "code d'erreur sans token" (affiché au client comme "vérifiez que les champs du checkout/carte sont remplis"), de sorte que la carte ne pouvait même pas être tokenisée après quelques tentatives. Comme la commande n'existe toujours pas dans le checkout de Blocks (id de commande 0), le numéro de commande préparé de Redsys était généré à partir de l'id 0, ce qui produisait une valeur presque constante -seulement ~999 numéros possibles, tous se terminant par neuf zéros- et Redsys rejette un numéro de commande réutilisé ("commande répétée", SIS0051). Lorsque l'id de la commande brouillon n'est pas encore disponible, le formulaire InSite de Blocks utilise maintenant le même numéro de commande temporaire que le checkout shortcode d'InSite (create_checkout_insite_number : commence toujours par 1, globalement unique grâce à un compteur incrémental partagé), donc il ne peut jamais entrer en collision ; lorsque l'id de la commande brouillon est disponible, le numéro de Redsys est construit à partir de celui-ci. Le numéro est à nouveau lié à l'id réel de la commande lorsque la commande est passée.
- Les paiements par carte InSite dans le checkout de blocs (Blocks) échouaient : le client voyait un message trompeur "vérifiez que les champs du checkout/carte sont remplis" et la commande n'était jamais payée (la console du navigateur affichait un 404 dans la requête save_order_data). La cause est que le WooCommerce actuel ne crée plus la commande tant que le client n'appuie pas sur "Passer la commande" -pendant la saisie de la carte, le store du checkout de Blocks renvoie l'id de commande 0- donc le token d'opération d'InSite (idOper) et le numéro de commande préparé de Redsys ne pouvaient pas être persistés : le flux précédent les envoyait à une route REST (save_order_data) qui tentait de les attacher à la commande 0 et renvoyait "Commande invalide" (404), et le numéro de commande généré était mappé à la commande 0 (de sorte qu'aucune notification ultérieure ne pouvait trouver la commande). Maintenant, lorsque la carte est tokenisée, le token et le numéro de commande préparé sont sauvegardés dans la session de WooCommerce via admin-ajax (la session de WC n'est pas disponible dans les routes REST personnalisées, raison pour laquelle l'approche REST précédente ne pouvait pas l'utiliser), et ils sont transférés à la commande réelle pendant que WooCommerce la crée à partir de la requête du checkout (woocommerce_store_api_checkout_update_order_from_request), avant que process_payment ne soit exécuté, de sorte que process_payment_block() trouve _insite_token et _payment_order_number_redsys comme dans le checkout classique. Le transient du numéro de commande est également à nouveau mappé à l'id réel de la commande pour que la notification (IPN) résolve la commande. Les données d'empreinte du navigateur (3DS) utilisaient déjà ce même chemin de session. Le checkout classique/shortcode n'est pas affecté.
Développement :
- La sortie de débogage bruyante console.log des scripts frontend de production (minifiés) a été supprimée : Apple Pay, Google Pay, capture-order-id et les modaux de express-checkout. Le script de Apple Pay Express en particulier enregistrait à chaque changement du DOM (surveille tout le document à la recherche de son bouton), ce qui inondait la console du navigateur dans le checkout de Blocks. Les fichiers minifiés suppriment maintenant console.log/console.warn/console.info/console.debug tout en maintenant console.error ; les sources non minifiées restent inchangées pour le développement.
31.0.4
Corrigé :
- Les renouvellements d'abonnement (avec n'importe quel plugin d'abonnement) respectent désormais le type de numéro de commande Redsys configuré et ne échouent plus lors de la nouvelle tentative avec "numéro de commande répété" (SIS0051). Deux problèmes sont corrigés.
- Le premier : le frais de renouvellement générait le numéro de commande Redsys en ignorant le paramètre "Type de numéro de commande" (redsysordertype/subfix) ; il recourait toujours au schéma aléatoire par défaut au lieu du type configuré pour la passerelle, contrairement au paiement initial du checkout. Désormais, la passerelle permet aux renouvellements de respecter le même type de numéro de commande que le checkout.
- Le second : le numéro de commande était conservé pendant toute la durée de la commande, de sorte que lorsqu'un frais de renouvellement était rejeté et que le plugin d'abonnement le réessayait sur la même commande de renouvellement, le même DS_MERCHANT_ORDER était renvoyé exactement et Redsys bloquait la nouvelle tentative légitime comme un duplicata. Maintenant, la distinction entre "flux" et "nouvelle tentative" est explicite : un unique flux de paiement (son pair initiePeticion/trataPeticion, les processus concurrents de renouvellement et toute réexécution via Action Scheduler d'un processus qui est mort au milieu du frais) maintient le même numéro de commande pour ne pas croiser les Id Opers (SIS0502) et être idempotent face aux frais dupliqués ; mais une fois que Redsys confirme un rejet (une réponse signée sans code d'autorisation, c'est-à-dire sans mouvement d'argent), le numéro est libéré pour que la prochaine nouvelle tentative génère un nouveau et unique numéro respectant le type configuré. Le redémarrage se produit UNIQUEMENT en cas de rejet confirmé, jamais en cas d'erreurs de transport ou de délai d'attente où le résultat est inconnu, de sorte qu'une réexécution en raison d'une réponse perdue ne peut jamais dupliquer le frais.
- Cela s'applique aux passerelles de Redirection et InSite et à tous les plugins d'abonnement qui les utilisent (WooCommerce Subscriptions, Subscriptions for WooCommerce, YITH, WebToffee, SUMO, Advanced Subscriptions ; Google Pay et Apple Pay délèguent à la passerelle de Redirection).
- Comme filet de sécurité, lorsqu'aucun type de numéro de commande valide n'est configuré (vide ou une valeur héritée ou non reconnue), le générateur recourt TOUJOURS au schéma par défaut "3 chiffres aléatoires + zéros + id de la commande", le seul qui ne rentre jamais en collision lors des nouvelles tentatives. Remarque : le type "numéro de commande simple" n'a pas de composant aléatoire, il est donc incompatible par conception avec les nouvelles tentatives d'abonnement et ne devrait pas être utilisé lorsque des abonnements sont actifs.
