Le développement de cette version a coûté 21 780 euros. Le coût cumulé pour cette année est de 35 130 euros. Le coût cumulé depuis la première version est de 233 860 euros, mais le coût pour vous est seulement la licence de 79€.
Nouvelle branche 32.0.x du plugin Redsys pour WooCommerce de WooCommerce.com.
Le plus important de cette version : votre boutique depuis une application native
Cette version active l'API de gestion qui était jusqu'à présent cachée dans le plugin. Votre boutique peut se connecter à PackDesk, l'application native de gestion pour macOS, pour gérer les commandes, les retours, les produits et les clients sans ouvrir le bureau de WordPress. PackDesk est déjà publiée sur le Mac App Store et nécessite macOS 26 Tahoe ou supérieur.
L'API est strictement optionnelle : elle est désactivée par défaut, nécessite HTTPS et une licence active, et aucune application ne peut accéder à la boutique tant que le commerçant ne l'active pas.
Versions de la branche
32.0.0
Nouveau :
- Gérez votre boutique depuis une application native. Cette version active l'API de gestion qui était jusqu'à présent cachée dans le plugin. Votre boutique peut se connecter à PackDesk, l'application native de gestion pour macOS, pour gérer les commandes, les retours, les produits et les clients sans ouvrir le bureau de WordPress. L'API est servie sous l'espace de noms redsys-manager/v1 et est strictement optionnelle : elle est désactivée par défaut, nécessite HTTPS et une licence active, et aucune application ne peut accéder à la boutique tant qu'un commerçant ne l'active pas. Elle offre une file d'attente de préparation des commandes et des mises à jour des commandes, des itinéraires de produits et de clients, un flux de changements (delta) pour que l'application synchronise uniquement ce qui a changé, des réécritures sécurisées via un en-tête Idempotency-Key, et une limite de requêtes par employé (par utilisateur, jamais par IP), de sorte que plusieurs employés partageant une même connexion n'interfèrent jamais entre eux.
- Nouvelle section "Comportements envers l'APP" dans les paramètres avancés de Redsys (WooCommerce – Paramètres – Redsys – Paramètres avancés) pour contrôler comment la boutique se comporte par rapport à l'application : activer ou désactiver l'API, autoriser ou restreindre les retours au profil Service client (par défaut, les retours sont limités au profil Administrateur), exiger une version minimale de l'application et définir la limite de requêtes par minute et par employé (300 par défaut ; 0 pour désactiver).
- Nouveau "Profil d'application" par utilisateur dans l'écran d'édition des utilisateurs de WordPress, pour que chaque employé se connectant depuis l'application opère sous un profil — par exemple Administrateur ou Service client — qui décide de ce que l'application lui permet de voir et de faire, y compris s'il peut effectuer des retours.
- Nouvelle section "Applications et Plugins" dans les paramètres avancés de Redsys : un résumé en lecture seule de l'application native et des autres plugins, sites et compétences, tout accessible depuis un même endroit.
- PackDesk est déjà publiée sur le Mac App Store, et le bouton officiel "Téléchargez-le sur le Mac App Store" s'affiche en haut de la section "Comportements envers l'APP" et dans la zone d'application mise en avant de "Applications et Plugins", de sorte que l'application peut être installée directement depuis les paramètres de la boutique. Le bouton utilise l'image officielle d'Apple dans la langue de l'administrateur qui le voit — anglais, espagnol, catalan, français ou portugais, avec anglais pour l'euskera et le galicien car Apple ne publie pas de badge pour eux — et ouvre l'App Store du pays de chaque visiteur. La fiche de l'application affiche maintenant la version publiée au lieu de la bêta, et indique qu'elle nécessite macOS 26 Tahoe ou supérieur.
Mis à jour :
- Compatibilité déclarée avec WooCommerce 11. L'en-tête "WC testé jusqu'à" du plugin indique maintenant 11.0, donc WooCommerce ne prévient plus que la passerelle n'a pas été testée avec la version que vous utilisez. La version minimale supportée de WooCommerce ne change pas (7.4).
Corrigé :
- Le code QR du produit n'apparaissait pas dans les boutiques dont la bibliothèque de médias est externalisée à un service comme Cloudflare Images. L'image du QR était correctement enregistrée dans la bibliothèque de médias, mais le plugin enregistrait et affichait une URL construite manuellement à partir du dossier local des uploads au lieu de demander à WordPress l'URL réelle de l'attachement, donc dans une boutique avec le stockage externalisé, cette adresse pointait vers un fichier qui n'est plus servi localement et l'image apparaissait cassée. L'URL du QR est maintenant résolue via la bibliothèque de médias (wp_get_attachment_url), l'id de l'attachement est enregistré avec elle, et l'adresse est résolue chaque fois que le QR est affiché, de sorte qu'elle suit le fichier où qu'il soit servi, y compris une externalisation activée après la création du QR. Les codes QR existants sont automatiquement réparés la première fois que leur produit est ouvert ; si l'un d'eux ne peut pas être apparié, le lien "Régénérer le code QR" le reconstruit correctement.
- Un paiement avec Bizum pouvait être encaissé à la banque et laisser la commande en attente, avec le log affichant "Échec de la vérification de la signature dans successful_request". L'étape de finalisation de la commande de l'une des deux passerelles de Bizum vérifiait la notification bancaire avec la clé de signature configurée dans la passerelle, tandis que l'opération avait été signée avec la clé par commande réellement utilisée pour elle, comme cela se produit dans les boutiques avec terminal par utilisateur ou avec terminal dual/de test, ou avec le filtre bizum_modify_data_to_send. La notification passait la première validation et était ensuite rejetée par cette seconde vérification, donc l'argent était encaissé et la commande restait en attente. L'étape de finalisation de la commande résout maintenant la clé de signature exactement de la même manière que la validation de la notification — et que l'autre passerelle de Bizum, qui le faisait déjà ainsi : d'abord depuis les métadonnées de la commande, ensuite depuis le transient de la requête, et enfin depuis la clé des paramètres pour le client de la commande, de sorte que les deux coïncident.
