Woocommerce Redsys Gateway Changelog - Version History & Release Notes

v32.2.1Latest

October 20, 20268.0 MBScanned

Fixed

Google Pay, Apple Pay, Direct Debit and PayGold in test mode (or test mode for some users) with a live key configured: Redsys authorised the payment but the order stayed pending and was later cancelled, with "Signature verification failed in successful_request" in the log. The notification is now verified with the key the payment was signed with. Live payments are unchanged.

Improved

The WooCommerce system status report shows next to each active Redsys gateway whether it is in test or production, and which users pay in test when test mode for users is on.

v32.2.0

October 15, 20268.0 MBScanned

Fixed

ACP (off by default): with ACP on, WordPress could log "Translation loading for the woocommerce
Duplicated scheduled actions left by earlier versions are now removed on their own: the paired
The plugin's text domain is now its slug, woocommerce-gateway-redsys (it was woocommerce-redsys).
Three strings used WooCommerce's text domain and four order-status counters had none.
Subscription renewals sent no description to Redsys (empty description in the TPV). They now send
Paying at checkout with a saved card (redirect gateway) always sent "Order N" as the description,
(security): UCP MCP (off by default): lookup_catalog takes at most 50 products and no tool returns
(security): UCP MCP (off by default) now writes every agent tool call to an audit log (client, tool,
(security): UCP MCP (off by default) now checks a per-address budget before authentication (300 calls
(security): UCP MCP (off by default) now limits each agent client to 60 tool calls per minute, 600
ACP (off by default): the public ACP document no longer announces a 60 requests/minute limit that
(security): ACP (off by default): the "HTTPS required" check believed X-Forwarded-Proto from anyone.
(security): UCP OAuth (off by default): authorization codes are now stored hashed, like tokens.
(security): A2A (off by default): after card authentication the shopper could be sent to any
(security): UCP MCP (off by default): when a tool failed inside the store, the agent received the
(security): UCP OAuth (off by default): two token requests sent at the same time with the same
(security): Inespay: after checking the notification's signature, the plugin still let unsigned
(security): Apple Pay and Google Pay marked the order paid without checking that the amount Redsys
UCP OAuth (off by default): two refreshes sent at the same time with the same refresh token could
(security): A2A (off by default): when an operation failed inside the store, the agent received the

Other

domain was triggered too early" when the hourly ACP clean-up was first scheduled. It is now scheduled
on init.
redsys_acp_process_webhooks / redsys_ucp_process_webhooks workers, a redsys_check_emails_cron with no
group, and repeated daily clean-ups. Since 32.1.0 no new ones were created, but existing ones stayed.
Custom translation files saved under the old name keep working; translations stored in the database
by a multilingual plugin and code that filters gettext by the old domain need the new name.
the description chosen in the gateway settings, as first payments do.
whatever the gateway setting said.
more than 1 MB (both adjustable with filters).
result; arguments only as a fingerprint and a masked summary), kept for 90 days.
per minute by default) and takes at most 20 calls per batch request.
per hour and 5000 per day (adjustable with the redsys_ucp_mcp_rate_limits filter).
BEHAVIOUR CHANGE (security): UCP MCP (off by default): tool arguments are checked against each tool's
published input schema before the tool runs; calls that do not match get a -32602 error.
was never applied.
BEHAVIOUR CHANGE (security): UCP (off by default): Dynamic Client Registration is now off by default and
switched off once on update. If your agents register themselves, turn "Allow Dynamic Client
Registration" back on in the UCP settings.
It now does only from the proxies in the "Trusted proxies" setting (A2A > Status); behind a proxy that
ends HTTPS, list its addresses there after updating.
BEHAVIOUR CHANGE (security): UCP OAuth (off by default) accepts only the S256 PKCE method; "plain" is
refused unless the redsys_ucp_allow_pkce_plain filter allows it.
BEHAVIOUR CHANGE (security): UCP OAuth (off by default): the token introspection endpoint answered
anyone. It now requires the calling client's credentials and only reports on that client's own tokens.
address the agent gave, including plain http or internal ones. Only https addresses on public hosts
are used now; otherwise the shopper lands on the order page.
internal error text (which can include server paths). It now receives a correlation id; the detail is
written to the plugin log.
BEHAVIOUR CHANGE (security): UCP and A2A (off by default) no longer accept the access token in the URL
(?access_token=), where it ends up in server logs; send it in the Authorization header. The
redsys_allow_bearer_in_query_string filter restores the old behaviour.
authorization code could both succeed. The code is now redeemed atomically; only one gets tokens.
fields of the request fill in values the signed data did not carry (such as the payment id). Only the
signed data is used now.
charged matched the order total, as card and Bizum payments already do. A different amount now puts
the order on hold with a note, for you to review.
both obtain a new token pair. The refresh token is now spent atomically; the second gets invalid_grant.
internal error text (which can include server paths). It now receive

v32.1.0

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

v32.0.0

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

v31.0.5

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).

v30.4.1Unavailable

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.4.0Unavailable

April 28, 20266.8 MBScanned

No changelog available for this version.

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.

v30.2.1Unavailable

March 5, 20266.1 MBScanned

Fixed

Google Pay Express Checkout now triggers WooCommerce transactional emails after successful payment (customer and admin).

v30.1.0Unavailable

February 21, 20266.1 MBScanned

Added

Conditional Rules — visual rule builder to override payment parameters (terminal, merchant code, SHA256, transaction type, test mode, etc.) based on order conditions (category, tag, amount, currency, language, user role).
Added preauthorization support for Google Pay and Apple Pay.
Google Pay and Apple Pay now save merchant code to order meta for preauthorization operations.
Added post_payment_complete hooks for Bank Transfer, IMAP email processing and Inespay gateways.

Improved

Refactored InSite payment form error handling with AJAX-based refresh instead of full page reload.

Fixed

Fixed InSite COF_TYPE detection that caused incorrect credential-on-file type in REST payments.
Fixed Ds_Card_PSD2 using wrong variable in REST payment path.
Fixed InSite orders being marked as paid without Redsys authorization when a third-party plugin filters woocommerce_cart_needs_payment.
Improved InSite checkout routing using REST_REQUEST instead of checkout_use_block() for reliable shortcode/block detection.

Other

SECURITY: Masked secret SHA256 key in debug logs.

v30.0.1Unavailable

February 14, 20266.1 MBScanned

Fixed

Fixed Express Payment (Google Pay / Apple Pay) not applying IRPF correctly when using Autonomos Premium. Totals now reflect the correct amount including retention.
Improved compatibility between Express Payment custom fields and Autonomos Premium surcharge calculation.
Fixed EMV 3DS timezone fields not being saved for users in UTC+0 timezone (e.g. Canary Islands), which could cause errors in 3D Secure authentication.

Woocommerce Redsys Gateway history.