Todas las versiones registradas, de la más nueva a la más antigua, con lo que cambió en cada una.
Última 32.2.19 versiones
Sin fecha · 9 versiones
32.2.1
Última
1 mejora1 corrección
Mejora
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.
Corregido
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.
32.2.0
1 mejora14 correcciones25 cambios
Mejora
Compatibility declared with WooCommerce 11.2 ("WC tested up to" is now 11.2).
Corregido
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
FIX (security): UCP MCP (off by default): lookup_catalog takes at most 50 products and no tool returns
FIX (security): UCP MCP (off by default) now writes every agent tool call to an audit log
FIX (security): UCP MCP (off by default) now checks a per-address budget before authentication
FIX (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
FIX (security): ACP (off by default): the "HTTPS required" check believed X-Forwarded-Proto from anyone.
FIX (security): UCP OAuth (off by default): authorization codes are now stored hashed, like tokens.
FIX (security): A2A (off by default): after card authentication the shopper could be sent to any
Cambios
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
32.1.1
2 nuevos7 correcciones31 cambios
Nuevo
new card reference while telling it that the reference already existed, and when the bank sent it
Deleting the plugin now removes its settings - the configuration of every payment method, the
Corregido
With the card gateway's "Pay with 1 click", a customer with no saved card who ticked "Save
With InSite, one subscription payment could leave the customer with the same card saved twice
The "Add a card for Subscriptions" option added in 32.1.0 (Redsys Advanced > Saved Cards)
With InSite, saving a new card during an ordinary one-click purchase asked the bank for a
With InSite, a card saved for a subscription could be stored with an invalid type, which made
When collecting the remainder of a deposit, the plugin charged whichever saved card came
Orders paid by bank transfer or by Google Pay (redirection) were reported to AI shopping
Cambios
payment information" paid normally, but the card was never saved. The plugin asked the bank for a
back the plugin believed its own message and threw the reference away. It now asks for a new card
correctly, so the card is saved, and it only asks for one when the customer actually ticked the
box. The same mismatch existed for subscriptions in InSite and is fixed too. Reported by a shop
that had already found the cause - thank you.
under "Payment methods". The bank reaches the shop by two routes for the same payment - the answer
to the payment itself and a separate notification - and each route saved the card. Every place
that saves a card now first checks whether this customer already has that card from that same
operation (the same card reference, type and transaction) and reuses it. A card saved again from a
different operation is still saved, because that is a genuine new card record. Cards that are
already duplicated are not removed: they can be deleted from "Payment methods". Reported with a
full production trace - thank you.
worked the wrong way round: the offer only ever appeared when a subscriptions plugin was active
and the option could only hide it. Products can save a subscription card without any subscriptions
plugin, and when that card expired or was stolen the customer had no way to add a new one. The
offer now appears whenever a supported subscriptions plugin is active, and also whenever the
option is ticked, with or without a plugin. The option is now off by default, so a shop that never
touches it behaves as it did before 32.1.0.
recurring (subscription) card instead of a one-click card. The value that should have decided it
was never filled in, so every new card was treated as recurring. Orders that contain a
subscription from any supported subscriptions plugin, or a product set to save a subscription
card, still ask for a recurring card; ordinary one-click purchases now ask for a one-click card.
it invisible to anything looking for one-click or subscription cards. It is now always stored as
one or the other.
first, of any type. It now charges the customer's most recent subscription card - the kind of card
meant for charges the shop starts itself, and which also picks up a card the customer replaced
from My account. A customer with no subscription card is charged exactly as before.
Reported by a shop that pointed at the exact line - thank you.
uninstalls it is left clean. It never touches customers, orders or subscriptions, nor anything
tied to them: saved cards, the order and invoice numbering and payments still in progress are all
kept, so reinstalling the plugin carries on where it left off.
32.1.0
3 correcciones1 de seguridad36 cambios
Corregido
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
Seguridad
The plugin was writing the address of every shopper's order-received page into its own
Cambios
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
32.0.0
5 nuevos1 mejora2 correcciones32 cambios
Nuevo
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
Mejora
Compatibility declared with WooCommerce 11 ("WC tested up to" is now 11.0), so
Corregido
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
Cambios
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
redsys-manager/v1) is strictly opt-in: OFF by default, it requires HTTPS and an active
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
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
31.0.7
7 correcciones33 cambios
Corregido
Subscription products from Advanced Subscriptions for WooCommerce were never detected
Any anonymous visitor could trigger a fatal error through admin-ajax.php. The AJAX
The Redsys Tokens admin page registered a form handler that was never written, so
Twelve user-facing texts said "Redys" instead of "Redsys" — nine email titles and three
A malformed or tampered bank notification could fill the log with "Trying to access
With the order number format set to "Number created by WooCommerce only with zeros"
The InSite tokenization number could collide with the default order number format.
Cambios
as subscriptions. The check guarded on a function name with one letter too many, so it
always returned false regardless of the product, and the card could be tokenised as a
one-off payment instead of as a recurring one.
action check_token_insite_from_action was registered, for logged-in and logged-out visitors
alike, against a method that does not exist; the working implementation and the name the
JavaScript posts are check_token_insite_from_action_checkout, registered separately. The two
obsolete registrations have been removed.
admin-post.php?action=redsys_tokens_search was a fatal for any logged-in user. Searching on
that page has always worked through the page itself; the obsolete registration is gone and
nothing changes for the user.
in the Bank Transfer gateway description. The Catalan, Basque, Galician, Spanish, French and
Portuguese translations were updated in the same release, so no translated text is lost.
array offset on null" warnings. Reading the order number from an undecodable notification now
returns empty, which callers already treat as unresolvable.
(simpleorder), adding a payment method could be rejected by Redsys as a repeated order
number (SIS0051). Real orders and card-additions were numbered from the same 12-digit
zero-padded space, and the add-card counter started at 1 and walked straight through the
range of existing order ids. The collision had a second, more damaging consequence: the
plugin decides whether a bank notification belongs to a card-addition by reading a
transient that lives 48 hours and is keyed on the number alone, so a real order paid with
a number a card-addition had reserved in the previous two days was processed as a
card-addition and returned without marking the order as paid — the money was taken and
the order stayed pending. Card-addition numbers now use the reserved prefix 200 plus a
9-digit counter, and the order-number generator can no longer produce that prefix: under
the default format the number is a random 1-999 prefix followed by the last 9 digits of
the order id, so the two values that would land in a reserved space, 100 and 200, are
re-rolled. The card-addition decision is now taken from the number itself plus a check
that no real order carries it, keeping the transient as a fallback so operations already
in flight when the plugin is updated keep working. Nothing is migrated and no pending
card-addition is lost. The "only with zeros" format keeps working; its remaining and
inherent limitation — paying the same order twice reuses the number and Redsys answers
SIS0051 — is now stated in the setting itself.
It begins with 1, while the default format uses a random 1-999 prefix, so a random prefix
31.0.6
1 mejora3 correcciones20 cambios
Mejora
Apple Pay and Google Pay now always use the Secure terminal, and the "Terminal type"
Corregido
Apple Pay in the block checkout could fail to pay when the shopper typed the address on
Apple Pay in the block checkout could open the payment sheet with required checkout
Apple Pay in the block checkout still produced a paid order with no customer data when the
Cambios
the opposite behaviour. Express brings its own data from the Apple Pay sheet, so letting
WooCommerce Blocks re-sync the order destroys it; standard mode has no data of its own, so
letting Blocks fill the order in is the only thing that populates it. This is now decided
per mode. Apple Pay Express keeps the 31.0.6 behaviour and is unaffected.
the page. The sheet showed the pre-tax amount while the server charged the real total, and
the payment was rejected on the mismatch. The amount was calculated once when the page was
rendered and never updated as taxes and shipping were recalculated; it now follows the live
cart total, so it always matches what is charged.
fields still empty, and left WooCommerce's "Place order" button visible next to the Apple
Pay button. Required fields are now checked before the sheet opens, and the "Place order"
button is hidden while Apple Pay is the selected method.
gateway's terminal type was "mixed" instead of "secure". The earlier fix in this version fills
the order on the payment page, but a mixed terminal charges directly and never loads that page.
On a mixed terminal the order is now filled from the checkout form before the charge is sent.
Secure terminals and Apple Pay Express are unaffected.
selector has been removed from both. For a wallet the terminal type only affected the first
payment (renewals go through the card/redirection gateway), and Secure already charges and
requests the recurring subscription token. The Mixed terminal used a path with no payment page
which is where Apple Pay as a normal method lost the customer's data on the block checkout.
Stores set to "mixed" move to Secure automatically on update; no data is lost.
31.0.6
2 correcciones12 cambios
Corregido
The ACP webhook dispatcher no longer floods the logs with "as_next_scheduled_action /
Apple Pay Express orders were saved without any customer data
Cambios
as_schedule_recurring_action was called before the Action Scheduler data store was
initialized" notices. The worker was scheduled on plugins_loaded, where the as_* functions
already exist but Action Scheduler has not yet initialized its data store. Scheduling is now
deferred to the action_scheduler_init hook when the store is not ready, keeping the WP-Cron
fallback unchanged when Action Scheduler is absent.
phone, billing and shipping address) and were recorded as guest purchases, even though the
payment completed correctly. Google Pay Express was unaffected. The express order was
registered in the session as the Store API draft order, so the Checkout block hydration on
the pay page re-synced it from the cart (OrderController::update_order_from_cart) and wiped
the contact data seconds before the bank notification arrived. The express flow no longer
hands its order to WooCommerce Blocks, and releases it from the draft session when the
payment starts. Applies to the express button on both the Cart and the Checkout blocks.
31.0.5
1 corrección8 cambios
Corregido
Subscription renewals could still get stuck in an endless SIS0051
Cambios
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.
Changelog publicado por el desarrollador, en su idioma original.
