15 versions
Woocommerce Redsys Gateway history.
Every release of Woocommerce Redsys Gateway is archived here with its changelog, file size, and security scan result. Use the archive to roll back to a stable release or audit what changed between updates.
15 of 15 releases scanned clean
v32.1.0Latest
September 9, 20268.0 MBScanned
Other
- SECURITY: The plugin was writing the address of every shopper's order-received page into its own
- log file on every payment, and that address contains the order key - the private token that
- WooCommerce puts in the shopper's payment link and that this plugin requires before it will show
- an order. Anyone able to read the log file could therefore open those orders and see the name,
- email, telephone and addresses on them. It happened whether or not the shop had switched debug
- logging on, because this one place wrote to the log without checking that setting. It now respects
- the debug setting like every other log the plugin writes, and the key is replaced with
- "[redacted]" before anything is written, so it is not recorded even with logging switched on. That
- replacement was then applied to every log line the plugin writes rather than to the one that was
- reported: around ninety further lines across the gateways printed the same addresses whenever
- debug logging was on, including the ones that dump the whole message sent to the bank. Log files
- already written still contain those addresses: if you have them, delete them.
- order as failed. When the bank approves such a payment without asking the shopper to confirm with
- their bank app - which is what happens with a saved card - the plugin was looking for the result
- in the wrong place, found nothing, and treated "nothing" as a refusal. The charge had already gone
- through, so shoppers who were told the payment had failed paid a second time and were charged
- twice. The result is now read from the bank's own signed answer, the same one the rest of the
- payment already uses. It affected the classic checkout and the block checkout equally, and it also
- affected subscription renewals. Reported by two shops within days of each other, one of whom
- traced it to the exact line - thank you.
- authorisation number alone, without checking the bank's actual answer beside it. A refused payment
- that still carried something in that field would therefore mark the order as paid, and the shop
- would send the goods without having been paid. Both are now required to agree before an order is
- completed. If the bank's answer is missing altogether the payment is not completed, because there
- is nothing left that says it was approved; a shop whose bank genuinely omits that field can
- restore the previous behaviour on purpose with the redsys_allow_payment_without_ds_response
- filter, which is documented and which cannot be used to accept a payment the bank actually
- refused.
- refused by Redsys with the error SIS0574. The bank requires a short description of the shopper's
- browser with each payment (its language, its screen size and similar), which the plugin collects
- through hidden fields it adds to the checkout. Those fields were being added at the moment the
- card gateway was built, which on those stores happens after another plugin has already asked
- WooCommerce for the definitive list of checkout fields - and WooCommerce builds that list once and
- never again. The fields were therefore never created, never filled in and never sent, and the bank
- refused the payment. They are now added as soon as the plugin loads, before anything can ask for
- the list, which affects every gateway that needs them - the card gateway, Bizum and the wallets -
- not only InSite. In InSite the browser description now also travels with the rest of the payment
- data instead of depending on the order alone, so it survives a checkout that rebuilds itself.
- Reported by an integrator who had already proved the diagnosis - thank you.
- SECURITY: The page that forwards a shopper to Redsys (and to Bizum) accepted any order number
- typed into its address, without checking that the person asking for it was the person who placed
- that order. Because order numbers run in sequence, someone could step through them and read the
- data the plugin sends to the bank for other customers' orders: name, email, telephone and the
- billing and delivery address, together with the amount and the description of what was bought. No
- card number, no security code and no signature key were ever exposed, and nothing could be paid or
- modified this way. That page now requires the order key that WooCommerce puts in the shopper's own
- payment link, so a request that does not belong to the order is refused with a "Forbidden" page
- instead of being answered. The same check was added to the payment pop-up on the checkout page.
- Reported by the security team at Tivify (TVUP Streaming Media), who described the problem clearly
- and gave us the time to fix it before saying anything publicly - thank you.
- left pending and the bask
Fixed
- With InSite, paying with a card the shopper had saved could take the money and still show the
- On the card gateway, a payment made with a saved card was completed on the strength of an
- On stores using certain checkout plugins - Fluid Checkout among them - every payment was
- If a payment was cancelled or refused, the shopper came back to the shop but the order was
July 28, 20267.9 MBScanned
Added
- Manage your store from a native app. This release turns on the management app API that
- A "Behaviors towards the APP" section in the Redsys advanced settings to enable or
- A per-user "App profile" on the user edit screen, so each employee connecting from the
- An "Apps and Plugins" section in the Redsys advanced settings: a read-only overview of
- PackDesk is published on the Mac App Store, and the official "Download on the Mac App
Other
- until now shipped hidden. Your store can be connected to PackDesk, the native macOS
- management app, to work with orders, refunds, products and customers. The API (namespace
- redsys-manager/v1) is strictly opt-in: OFF by default, it requires HTTPS and an active
- license, and no app can reach the store until a merchant enables it. It offers an order
- picking queue and order updates, product and customer routes, a "changes" delta feed for
- efficient sync, safe write retries via Idempotency-Key, and a per-employee rate limit
- (applied per user, never per IP).
- disable the API, allow or restrict refunds for the Customer service profile, require a
- minimum app version, and set the per-employee requests-per-minute limit (default 300).
- app operates under a profile (for example Administrator or Customer service) that gates what
- they can see and do, including whether they may issue refunds.
- the native app and the rest of the plugins, websites and skills.
- WooCommerce no longer warns that the gateway is untested on the version you run. The minimum
- supported WooCommerce is unchanged (7.4).
- Store" button now appears at the top of "Behaviors towards the APP" and in the featured-app
- area of "Apps and Plugins", so the app can be installed straight from the store settings. It
- uses Apple's own artwork in the administrator's language (English, Spanish, Catalan, French
- or Portuguese; English for Basque and Galician, which Apple does not publish) and opens each
- visitor's own country store. The app entry now shows the published version and states that
- it requires macOS 26 Tahoe or later.
- external service such as Cloudflare Images. The plugin saved and showed a URL it had built by
- hand from the local uploads folder instead of the media library's real attachment URL, so on
- an offloaded store that address pointed at a file no longer served locally and the image was
- broken. The QR URL is now resolved through wp_get_attachment_url, the attachment id is stored,
- and the address is resolved every time the QR is shown, so it follows the file wherever it is
- served - including offloading enabled after the QR was created. Existing QR codes are healed
- automatically the first time their product is opened; otherwise the "Regenerate QR Code" link
- rebuilds them correctly.
- showing "Signature verification failed in successful_request". The order-completion step in one
- of the two Bizum gateways verified the bank notification with the gateway's plain configured
- signature key, while the operation had been signed with the per-order key actually used for it -
- as happens on stores with a per-user or dual/test terminal, or the bizum_modify_data_to_send
- filter. The notification passed the first validation and was then rejected by this second check,
- so the money was taken but the order stayed pending. The completion step now resolves the signing
- key exactly like the notification validation - and like the other Bizum gateway already did -
- from the order meta, then the request transient, then the settings key for the order's customer,
- so both agree.
Improved
- Compatibility declared with WooCommerce 11 ("WC tested up to" is now 11.0), so
Fixed
- The product QR code did not appear on stores whose media library is offloaded to an
- A Bizum payment could be charged at the bank yet leave the order pending, with the log
July 2, 20267.8 MBScanned
Fixed
- Subscription renewals could still get stuck in an endless SIS0051 ("número de
Other
- 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.
v31.0.3Unavailable
June 27, 20266.9 MBScanned
Fixed
- InSite card payments on the block-based (Blocks) checkout were rejected by Redsys
- InSite card payments on the block-based (Blocks) checkout were rejected with
- InSite card payments on the block-based (Blocks) checkout failed with a
Other
- 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.
- 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.
- 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
- order while it is created (woocommerce_store_api_checkout_update_order_from_request),
- before process_payment runs, and the order-number transient is re-mapped to the real
- order id so the notification (IPN) resolves the order. The classic/shortcode checkout
- is unaffected.
- Security Fix: Added Inespay notification signature (signatureDataReturn / HMAC-SHA256)
- and amount verification in the Inespay callback to prevent unauthenticated payment
- forgery. The signature gate covers both the single-payin and the periodic-mandate
- notifications. Thanks to Shivamani Vastrala for the responsible disclosure.
v31.0.2Unavailable
June 16, 20266.9 MBScanned
Improved
- La sección "Comportamientos hacia la APP" (conexión con la app
- El filtro redsys_modify_data_to_send ahora recibe
- Actualizadas todas las traducciones.
Other
- Redsys Manager) se oculta de los ajustes de Redsys Avanzado mientras la
- app sigue en desarrollo. La API REST y sus gestores se mantienen; solo se
- elimina el enlace del menú de ajustes.
- 'context' => 'add_payment_method' y 'user_id' en el flujo de "Añadir
- método de pago", para poder enrutar la tokenización al terminal correcto.
- rechazado por Redsys con error de divisa. Ahora se envía la divisa base
- de la tienda, que coincide con el terminal por defecto.
- se creaba como 'C' (one-click) en Redsys. Ahora se envía correctamente
- DS_MERCHANT_COF_TYPE 'R'.
- suscripción no respetaban la preautorización. Ahora se envía una
- preautorización real de tipo 1 que puede confirmarse después.
- SECURITY: La clave secreta SHA-256 ya no se escribe en texto plano en los
- logs de depuración; se enmascara mostrando solo los 4 últimos caracteres.
- SECURITY: Las firmas de las notificaciones (IPN) de Redsys se verifican
- con hash_equals() (comparación en tiempo constante) en todos los
- gestores de notificación.
- SECURITY: El gestor AJAX de borrado de un token ahora exige la capacidad
- manage_woocommerce además del nonce.
Fixed
- Añadir una tarjeta desde Mi Cuenta en tiendas multidivisa podía ser
- Al añadir una tarjeta con la opción de suscripciones, el acuerdo COF
- Los pagos con tarjeta guardada (token R) y las renovaciones de
v31.0.1Unavailable
June 9, 20267.3 MBScanned
Fixed
- Bizum en página de pago (Bizum InSite) no enviaba la descripción
- La cuenta atrás del modal de Bizum en página de pago mostraba
Other
- a Redsys. El cobro real del modal usa la API REST (trataPeticionREST)
- y esa petición no incluía DS_MERCHANT_PRODUCTDESCRIPTION, por lo que la
- "Descripción Redsys" configurada (p. ej. "ID Pedido") llegaba vacía al
- panel de Redsys. Ahora se calcula con el ajuste seleccionado y se envía
- en la petición REST.
- 7 minutos. Ahora muestra 5 minutos y el control de tiempo en servidor
- que redirige al checkout se ajusta en consecuencia (60 iteraciones *
- 5 segundos = 5 minutos).
May 5, 20266.8 MBScanned
Added
- "Redsys email to customer" toggle in Redsys Advanced Settings → General to control whether DS_MERCHANT_EMAIL_TITULAR is sent to Redsys. When enabled and the Redsys terminal is configured to notify customers, Redsys sends its own purchase confirmation email to the buyer. Disabled by default — WooCommerce already sends its own order email, so existing installations stop forwarding the customer email to Redsys after the update. Applied to both Redsys Redirection and InSite gateways (classic and Blocks checkouts).
- Inline Express custom fields on the product page. When the feature is enabled and there are fields to collect, the form is now rendered above the Apple Pay / Google Pay buttons instead of in a post-click modal, with debounced auto-save to session. The click handler validates locally and starts ApplePaySession.begin() synchronously, preserving the iOS user gesture.
- Inespay periodic mandate now sends the recurring amount of the subscription instead of the parent order total. The gateway reads the recurring price from WooCommerce Subscriptions, SUMO Subscriptions, YITH WooCommerce Subscriptions, Subscriptions for WooCommerce (WP Swings) and Advanced Subscriptions for WooCommerce, and falls back to the order total only when no subscription amount can be detected. The order note created on mandate creation now includes the recurring amount that was actually sent to Inespay.
- Advanced Subscriptions for WooCommerce (ASWC) support in Inespay — the gateway detects the subscription id from order meta (aswc_subscription) and reads frequency, next payment date, end date and recurring amount via aswc_get_meta_data() to build the periodic mandate.
Fixed
- Apple Pay Express button on the product page failed to open the payment sheet on iOS Safari mobile when the Express custom fields feature was enabled. The pre-payment AJAX call (modal lookup or modal save) ran between the click handler and ApplePaySession.begin(), invalidating the iOS user-activation gesture so Safari silently aborted the session. The button still worked on desktop because desktop Safari is more permissive about gesture propagation.
- Express custom fields modal AJAX no longer fires when there are no fields to collect on the current page. The product page now precomputes whether any classic or Blocks-registered additional fields exist and disables the modal lookup entirely when the field set is empty, avoiding the gesture-breaking AJAX even on pages where the feature is enabled but no fields apply.
- Inline Express custom fields on the product page now try both Blocks and Classic contexts when reading additional fields, so fields registered through the Blocks API are also rendered on classic product pages.
- Inespay return handler now keeps the intermediate "Creating the mandate…" screen visible for a few seconds even when the periodic mandate link is already known on first load, so customers can read what is happening before being redirected back to Inespay to authorize the recurring mandate.
- Limited Inespay and Google Pay Redirection gateway icons to the same maximum size as Google Pay (max-width 110px, max-height 40px) in the classic checkout, preventing oversized logos when the bank-supplied image is too large.
- PHP warnings "Undefined variable $ship_address_usage / $ship_address_usage_ind" in class-wc-gateway-redsys-psd2.php when a guest customer (not logged in and no user id) checked out with a shipping address. Both variables were only initialized inside the logged-in branch but read in the outer block; they now default to first-use today, matching the existing else-branch behavior.
v30.3.1Unavailable
March 25, 20266.1 MBScanned
Other
- SECURITY [Medium]: Fixed an authenticated account takeover vulnerability that could allow an attacker to assume any user account, including administrators.
- SECURITY [Low]: Fixed unauthenticated access to order status and user data.
Fixed
- PayGold link generated from admin order metabox was never saved correctly due to an impossible response code condition in send_paygold_link(). The function now uses the same validation logic as the checkout flow (response code 9998).
- Fixed undefined $description variable in paygold_metabox_save() when sending a PayGold link from the order edit screen.
- Custom notification domain (redsys_url_notify) was broken by check_url() prepending home_url() to URLs that already had a different domain. check_url() now detects absolute URLs and preserves them as-is.
- get_notify_home_url() now automatically adds https:// when the custom notification domain is saved without a scheme.
- PHP 8.3+ compatibility — Fixed deprecated warnings for passing null/false to string functions (trim, strlen) from get_option() calls in get_txnid(), get_token_type(), and connect_standard_imap().
- PHP 8.3+ compatibility — Fixed add_submenu_page(null,...) in setup guide causing strpos()/str_replace() deprecation warnings.
v30.3.0Unavailable
March 11, 20266.1 MBScanned
Added
- Virtual / Downloadable Products order status override in Advanced Settings. When all products in an order are virtual or downloadable, the order status can be automatically set to Completed instead of Processing.
- Redsys response code 0115 (card cancelled or account closed) now automatically deletes the stored card token, notifies the customer with instructions to add a new payment method (My account > Payment Methods), and notifies the admin.
- Admin email notification when a customer's credit card is automatically removed due to Redsys hard-decline response codes (0115, 0172, 0173).
- Improved customer email when a card is removed — now includes the last 4 digits of the card, the error code, and a direct link to add a new payment method.
- COF_INI (Credential on File initial) flag is now saved to order meta (_redsys_cof_ini) for all COF transaction types (R and C), preventing duplicate token creation when COF_INI=N.
Fixed
- Conditional Rules test mode now correctly applies to the Redsys gateway URL. Previously, orders with conditional rules overriding test mode still used the default gateway URL.
- Fixed duplicate token creation when customer already has a saved card and COF_INI=N is sent to Redsys.
- Fixed undefined array key warnings in save_field_update_order_meta() when conditional rules data is incomplete.
- Fixed $redsys->debug reference using wrong variable in preauthorization logging (now uses $this->debug).
- Fixed sanitize_text_field applied before substr for HTTP_ACCEPT_LANGUAGE in Google Pay and Apple Pay Checkout, ensuring correct sanitization order.
- Google Pay Checkout now ensures WooCommerce transactional emails are initialized before calling payment_complete() in payment callbacks.
Why archive
Sometimes the latest release isn't the one you need. The archive lets you pin Woocommerce Redsys Gateway to a known-good version, or roll back while a bug is investigated. Every release stays scanned and reachable.