Télécharger WooCommerce – RedSys Gateway v31.0.5

Quoi de neuf (Journal des modifications - Changelog) dans WooCommerce – RedSys Gateway version 31.0.5

• = 31.0.5 =
• Solution : Les renouvellements d’abonnement pourraient encore rester bloqués dans une SIS0051 sans fin (« número de numéro de abonnement »
• boucle pedido repetido ») après 31.0.4 : Redsys rapporte un numéro de commande en double comme un
• simple ErrorCode (pas comme un refus signé), donc le numéro stocké n’a jamais été publié
• Et chaque tentative de réception se ressent la même DS_MERCHANT_ORDER. Les frais de renouvellement sont désormais TOUJOURS facturés
• Générez un tout nouveau numéro de commande au début de chaque essai et ne lisez jamais un
• Un précédemment stocké. La paire iniciaPeticion/trataPeticion de la tentative partage le
• Un numéro nouveau, les travailleurs concurrents en double sont arrêtés par le verrou de renouvellement, et le
• Le dernier numéro envoyé est toujours maintenu, donc les remboursements et l’IPN résolvent la bonne commande.
• Les magasins coincés dans la boucle s’auto-guérissent lors de la prochaine tentative programmée après mise à jour.
• = 31.0.4 =
• Correction : Les renouvellements d’abonnement (avec n’importe quel plugin d’abonnement) respectent désormais la configuration
• Redsys type de numéro d’ordre et ne plus échouer à la réessaie avec « número de pedido repetido »
• (SIS0051). Le frais de renouvellement utilisé pour générer le numéro de commande ignorant le « Type de
• Numéro d’ordre » (il est revenu au schéma aléatoire par défaut au lieu du type
• configuré pour la passerelle, contrairement à la première vérification), et il a maintenu ce chiffre
• Pendant toute la durée de vie de la commande, donc une nouvelle tentative lors d’un renouvellement refusé provoque exactement la même réimpression
• DS_MERCHANT_ORDER et Redsys ont bloqué la tentative légitime en tant que doublon. Maintenant, le
• La distinction entre un « flux » de paiement et un « réessai » est explicite : un flux unique (its
• paire iniciaPeticion/trataPeticion, travailleurs concurrents, ou une reprise Action-Scheduler de
• un processus qui s’est arrêté en plein charge) garde le même nombre pour éviter SIS0502 et doubler
• charges ; une fois que Redsys confirme une baisse (aucun argent déplacé), le chiffre est publié afin que le
• La prochaine tentative génère une nouvelle tentative unique, honorant le type configuré. Le reset se déclenche
• Seulement sur une baisse confirmée, jamais sur des erreurs de transport ou de timeout, donc une réponse perdue
• Re-run ne peut jamais doubler la charge. Cela concerne Redirection et InSite (et Google Pay /
• Apple Pay, qui délègue à la Redirection). Le type « simple numéro d’ordre » n’a pas de « nombre d’ordre simple »
• et est incompatible avec les réessais par abonnement par conception.
• Dev : Les onglets « Comportements envers l’APP » et « Applications et plugins » sous Redsys Advanced
• sont à nouveau cachés jusqu’au lancement public de l’application de gestion native (la section
• les superviseurs restent branchés ; seules les entrées du menu sont cachées).
• = 31.0.3 =
• Correction : Les paiements par carte InSite lors du paiement basé sur les blocs (Blocks) ont été rejetés par Redsys
• avec SIS0574 (« browserUserAgent non indiqué ») : l’empreinte digitale du navigateur 3DS ne jamais
• Atteindre l’ordre parce que l’accroche qui le copie (woocommerce_checkout_create_order)
• ne fonctionne pas lors du checkout de l’API du magasin. Le formulaire InSite Blocks collecte désormais les
• empreinte digitale et l’envoie avec le jeton, et il est écrit dans l’ordre réel avant
• process_payment s’enfuit.
• Correction : Les paiements par carte InSite lors du paiement basé sur les blocs (Blocks) ont été rejetés avec
• un « code d’erreur sans jeton » après quelques tentatives (affiché comme « vérifie que le
• Les champs de paiement/carte sont remplis »). Parce que l’ordre n’existe pas encore sur le
• Blocs le paiement (ID commande 0), le numéro de commande Redsys préparé était presque constant
• (~999 valeurs possibles, toutes se terminant par zéros) et Redsys rejette un numéro d’ordre réutilisé.
• La forme InSite Blocks utilise désormais une séquence incrémentale unique comme identifiant substitutif.
• Correction : Les paiements par carte InSite lors du paiement basé sur les blocs (Blocks) ont échoué avec un
• erreur trompeuse « vérifie que les champs de paiement/carte sont remplis » et la commande
• n’a jamais été payé (la console du navigateur affichait un 404 sur save_order_data). Actuel
• WooCommerce ne crée plus la commande tant que « Placer commande » n’est pas pressé, donc pendant
• saisie de la carte : le compte de retour Blocks, l’identifiant de commande 0 et le jeton InSite (idOper) et
• Le numéro de commande préparé n’a pas pu être enregistré dans la méta. Ils sont maintenant cachés dans le
• Session WooCommerce via admin-ajax lorsque la carte est tokenisée et déplacée sur la vraie