Get Started
Woocommerce Redsys Gateway featured image

WooCommerce Redsys Gateway v32.2.1 - WordPress Plugin

Developer: WooCategory: WordPress PluginsTrusted with 347 downloadsLite2 favoritesLatest v32.2.1Updated 1w ago

Allow customers to check out and pay via RedSys (the Servired / Sermepa successor) on your WooCommerce store.

Related items

Related Woocommerce Plugins

Woocommerce Subscriptions icon

WooCommerce Subscriptions - WordPress Plugin

by Prospress Inc

WooCommerce Subscriptions Plugin allows you to introduce a variety of subscriptions for physical or virtual products and services.

Woocommerce Smart Coupons icon

WooCommerce Smart Coupons - WordPress Plugin

by StoreApps

Enhance your coupon options - create gift certificates, store credit, coupons based on purchases and more.

Woocommerce Table Rate Shipping icon

WooCommerce Table Rate Shipping - WordPress Plugin

by WooCommerce

Advanced, flexible shipping. Define multiple shipping rates based on location, price, weight, shipping class or item count.

Redsys payment gateway for WooCommerce. Thanks to this extension, you will get Redsys, Iupay, refund, tokenization ( Pay with 1 Click), Sequential invoice numbers, CSV Exporter. Compatible with PHP 5.6.x, 7.0.x, 7.1.x and 7.2.x

Redsys the is the most used gateway in Spain (98%).

This extensión add the ability to use Redsys Gateway and Iupay Gateway. Iupay Gateway is the new Redsys Gateway similar to Paypal. Use a second terminal number is allowed by this extension. It is WPML compatible.

Too the extension add sequential invoice number to every paid order. This is essential in Spain. The spanish law is very strict with this. If you don’t have sequential invoice numbers, you can have a very big problem.

A CSV exported is included, so you can export all orders to a CSV file and import it to an Excel. You can use this file for sent the orders, or use for accounting.

Recent releases

Release history

View all 15 versions
v32.2.1LatestVerified Safe
Oct 20, 20268.0 MB
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.
Oct 15, 20268.0 MB
View changelog
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
Sep 9, 20268.0 MB
View changelog
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

Frequently asked questions

Is Woocommerce Redsys Gateway GPL licensed?
Yes, Woocommerce Redsys Gateway is distributed under the GNU General Public License (GPL). You can legally use, modify, and redistribute it on unlimited websites.
What is the latest version of Woocommerce Redsys Gateway?
The latest version of Woocommerce Redsys Gateway on GPLCoffee is v32.2.1 (released Oct 20, 2026, 8.0 MB download size). Every new release is synced automatically, and subscribers can update directly from their WordPress dashboard with the one-click connector plugin.
How much does Woocommerce Redsys Gateway cost on GPLCoffee?
Woocommerce Redsys Gateway is available for $2.99 for a 1-year license or $7.99 for a lifetime license. Membership plans also include credit-based access so you can download Woocommerce Redsys Gateway along with thousands of other plugins, themes, and PHP scripts for a single subscription.
Which WordPress and PHP versions does Woocommerce Redsys Gateway support?
The current release of Woocommerce Redsys Gateway requires WordPress 5.4 or higher, tested up to WordPress 7.1, PHP 7.4 or higher. Per-release compatibility details are listed in the version history.
Is Woocommerce Redsys Gateway safe to download?
Yes. The latest release of Woocommerce Redsys Gateway (v32.2.1) was scanned with VirusTotal and came back clean. Scan results are visible on each version page, and releases flagged as malicious are blocked from the catalog.

Auto-updates included

Install it once, update automatically.

The GPLC Connector installs this plugin from your wp-admin and rolls out new versions to your connected sites. Included with every membership plan: 10 to 40 connected sites depending on the plan (Lite 10, Pro 20, Geek and Lifetime 40).