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écapitulable 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 les 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 en mode ajout uniquement (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, constituer 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 seulement si vous devez confirmer des commandes préautorisées en masse.
Note :
- 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, surtout en Europe, où les exigences SCA/3DS, PSD2 et 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 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 verrouillage de paiement dupliqué 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 appliquée aux renouvellements InSite est désormais utilisée par la passerelle de redirection.
- 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 qui se comportaient mal, 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 l'enregistrement 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 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 sans taxes. Le callback d'envoi maintient désormais le dernier total renvoyé par le serveur.
- Lors de l'enregistrement des paramètres d'Agentic Commerce, l'envoi "Enregistrer 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 Enregistrer.
- Les boutons Express d'Apple Pay et Google Pay sur la page produit attribuaient 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 coûteuse (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 l'enregistrement était exécuté 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 désormais correctement 5 minutes, et le contrôle du 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 demande n'incluait pas le paramètre DS_MERCHANT_PRODUCTDESCRIPTION, de sorte que la "Description de Redsys" configurée (par exemple "Order ID") arrivait vide au panneau de Redsys. La description est désormais calculée à partir du réglage sélectionné et envoyée dans la demande REST.
31.0.2
Mis à jour :
- Le filtre redsys_modify_data_to_send reçoit désormais 'context' => 'add_payment_method' et 'user_id' dans le tableau de données pour le flux "Ajouter un mode de paiement", de sorte que les snippets personnalisés et les règles conditionnelles peuvent router la tokenisation au terminal correct (terminal + SHA256) sans dépendre d'une commande qui n'existe pas dans ce flux.
- Toutes les traductions mises à jour.
Corrigé :
- Ajouter une carte depuis Mon compte ("Ajouter un mode de paiement") dans des boutiques multidevises pouvait être rejeté par Redsys avec une erreur de devise. La demande é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 ne route la demande vers un autre terminal, la devise de base de la boutique est désormais envoyée, ce qui correspond toujours à la configuration du terminal par défaut.
- Ajouter une carte depuis Mon compte (ou via le lien de l'email de 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 ultérieur des renouvellements d'abonnement (MIT) effectués avec ces tokens par certains émetteurs. Les cartes ajoutées avec l'option d'abonnements envoient désormais correctement DS_MERCHANT_COF_TYPE 'R'. Les tokens créés pendant que l'erreur était présente ne peuvent pas être reclasifié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 plus tard échouait dans Redsys avec SIS0059 ("Aucune opération sur laquelle effectuer la confirmation n'existe"). Les deux flux envoient désormais 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 active également les renouvellements d'abonnement préautorisés (par exemple, des produits vendus au poids, où chaque renouvellement est ajusté avant le prélèvement final).
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 désormais la clé, affichant seulement ses 4 derniers caractères, via le nouvel helper WCRed()->mask_secret(). Appliqué dans 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 désormais vérifiées avec hash_equals() (comparaison en temps constant) dans tous les gestionnaires de notification, les unifiant avec la vérification déjà utilisée par InSite et le client REST. Renforcement contre les attaques par temporisation (timing attacks).
- Le gestionnaire AJAX de suppression d'un seul token dans l'écran de gestion des tokens nécessite désormais la capacité manage_woocommerce en plus du nonce, l'alignant sur le gestionnaire de suppression massive.
