Download WooCommerce – RedSys Gateway v31.0.5

List of improvements in WooCommerce – RedSys Gateway version 31.0.5

• = 31.0.5 =
• Fix: Subscription renewals could still get stuck in an endless SIS0051 (“número de
• pedido repetido”) loop after 31.0.4: Redsys reports a duplicate order number as a
• plain errorCode (not as a signed decline), so the stored number was never released
• and every retry resent the same DS_MERCHANT_ORDER. Renewal charges now ALWAYS
• generate a brand-new order number at the start of every attempt and never read a
• previously stored one. The attempt’s iniciaPeticion/trataPeticion pair shares the
• fresh number, duplicate concurrent workers are stopped by the renewal lock, and the
• last number sent is still persisted so refunds and the IPN resolve the right order.
• Stores stuck in the loop self-heal on the next scheduled retry after updating.
• = 31.0.4 =
• Fix: Subscription renewals (with any subscription plugin) now respect the configured
• Redsys order-number type and no longer fail on retry with “número de pedido repetido”
• (SIS0051). The renewal charge used to generate the order number ignoring the “Type of
• order number” setting (it fell back to the default random scheme instead of the type
• configured for the gateway, unlike the initial checkout), and it persisted that number
• for the whole order lifetime, so a retry on a declined renewal resent the exact same
• DS_MERCHANT_ORDER and Redsys blocked the legitimate retry as a duplicate. Now the
• distinction between a payment “flow” and a “retry” is explicit: a single flow (its
• iniciaPeticion/trataPeticion pair, concurrent workers, or an Action-Scheduler re-run of
• a process that died mid-charge) keeps the same number to avoid SIS0502 and double
• charges; once Redsys confirms a decline (no money moved), the number is released so the
• next retry generates a fresh, unique one honouring the configured type. The reset fires
• only on a confirmed decline, never on transport/timeout errors, so a lost-response
• re-run can never double charge. Applies to Redirection and InSite (and Google Pay /
• Apple Pay, which delegate to Redirection). The “simple order number” type has no random
• component and is incompatible with subscription retries by design.
• Dev: The “Behaviors towards the APP” and “Apps and Plugins” tabs under Redsys Advanced
• are hidden again until the native management app is publicly launched (the section
• handlers stay wired; only the menu entries are hidden).
• = 31.0.3 =
• Fix: InSite card payments on the block-based (Blocks) checkout were rejected by Redsys
• with SIS0574 (“browserUserAgent not indicated”): the 3DS browser fingerprint never
• reached the order because the hook that copies it (woocommerce_checkout_create_order)
• does not run on the Store API checkout. The InSite Blocks form now collects the
• fingerprint and sends it with the token, and it is written onto the real order before
• process_payment runs.
• Fix: InSite card payments on the block-based (Blocks) checkout were rejected with
• an “error code without token” after a few attempts (shown as “check that the
• checkout/card fields are filled in”). Because the order does not exist yet on the
• Blocks checkout (order id 0), the prepared Redsys order number was almost constant
• (~999 possible values, all ending in zeros) and Redsys rejects a reused order number.
• The InSite Blocks form now uses a unique incremental sequence as a surrogate id.
• Fix: InSite card payments on the block-based (Blocks) checkout failed with a
• misleading “check that the checkout/card fields are filled in” error and the order
• was never paid (the browser console showed a 404 on save_order_data). Current
• WooCommerce no longer creates the order until “Place order” is pressed, so during
• card entry the Blocks checkout returns order id 0 and the InSite token (idOper) and
• prepared order number could not be saved to order meta. They are now stashed in the
• WooCommerce session via admin-ajax when the card is tokenised and moved onto the real