Just updated121 new versions in the last 24 hours
WooCommerce Servired RedSys Spain Gateway plugin banner
Plugin Updated

WooCommerce Servired RedSys Spain Gateway

by WooCommerce woocommerce.com v32.1.0 Unlimited sites

This WooCommerce plugin by José Conti connects your store to RedSys, the payment gateway used by Spanish banks such as CaixaBank, Santander and BBVA. It adds card payments, Bizum, digital wallets and bank transfers to your checkout, along with refunds, preauthorizations and recurring payments.

Version
32.1.0
Released
Sep 9, 2026
Developer
WooCommerce
Type
WordPress plugin
Requires
WooCommerce
Licence
GPL
Included in
Every plan, or $7.99 a year on its own

What’s new in WooCommerce Servired RedSys Spain Gateway 32.1.0

Version 32.1.0 · Sep 9, 2026 Latest
  • SecurityThe 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.
  • FixedWith InSite, paying with a card the shopper had saved could take the money and still show the 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.
  • FixedOn the card gateway, a payment made with a saved card was completed on the strength of an 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.
  • FixedOn stores using certain checkout plugins - Fluid Checkout among them - every payment was 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.
  • SecurityThe 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.
  • FixedIf a payment was cancelled or refused, the shopper came back to the shop but the order was left pending and the basket was not restored. The address the plugin gave the bank to send the shopper back to was written in the form used for links inside a web page, not the form used for a real address, so the shop received the return without the order reference, its number or its security token and had nothing to cancel. It affected Bizum, Google Pay, Apple Pay, direct debit, bank transfer, InSite and the card gateway whenever the "return to" setting is set to cancel the order. On MasterPass the same address was being sent completely empty, because of a typing mistake of a single character repeated on three lines. All of it now goes through a single shared piece of code, so a gateway added in the future cannot get it wrong again.
  • FixedIn the pop-up (modal) payment mode, cancelling a payment did nothing and the shopper was left on the cart with the order still pending. The address the plugin sent the browser to was being written into the page in a way the browser reads as a link inside a document rather than as a web address, so everything after the first parameter was discarded - the order reference, its number and its security token all disappeared, and WooCommerce had nothing to cancel. The same flaw affected the address the shopper is returned to after paying, where it silently dropped a tracking parameter. Both are fixed, in the card gateway and in the InSite gateway, and the corrected behaviour was verified in a real browser.
  • FixedThe checkout could die with a critical error, instead of sending the shopper to the bank, for a logged-in customer whose customer record had never been changed since it was created. The plugin builds a set of security data for the bank on every payment, and one of the fields is the date the customer account was last modified - which WooCommerce leaves empty for an account that has never been touched, typically one created by an import, a migration, or automatically by another plugin. The plugin read that empty date as if it were a real date and the payment page stopped there. It now falls back to the date the account was created, which is what "never modified" means, and the same protection was added to the equivalent code used by subscriptions - where the same empty date was silently being reported to the bank as "modified today", which is wrong information for the bank's fraud checks.

What it does

Shops that sell in Spain usually need a way to take payments through RedSys, since that is the gateway many Spanish banks provide to merchants. This plugin adds RedSys to the WooCommerce checkout and supports a long list of methods: InSite card entry on your own page, Bizum (standard and inside the checkout), Apple Pay, Google Pay, MasterPass, Paygold and direct bank transfers. It follows PSD2 requirements and sends the browser details the bank asks for with each payment.

Beyond taking the first payment, it handles the work that comes after. You can preauthorize amounts and capture them later, issue refunds from the order screen, and process several preauthorizations or refunds at once. Saved cards allow one-click checkout, and recurring payments work with WooCommerce Subscriptions, YITH and SUMO Subscriptions. It also generates sequential invoice numbers for Spanish fiscal rules, runs on WordPress Multisite, works with WPML and can use two terminals from one store.

Best for

  • WooCommerce stores in Spain using a RedSys bank account
  • Shops selling subscriptions that need recurring card payments
  • Agencies running multilingual or multisite WooCommerce networks

Features

Many payment methods

Offer InSite card entry, Bizum, Apple Pay, Google Pay, MasterPass, Paygold and direct bank transfers through RedSys, all within the WooCommerce checkout.

Preauthorizations and refunds

Authorize a payment first and capture the funds later, and process refunds straight from the WooCommerce order screen without logging into the bank panel.

Bulk payment actions

Handle multiple preauthorizations and refunds at the same time from the WooCommerce admin, which helps when you manage many orders each day.

Saved cards and one-click pay

Tokenization lets customers store their card details so returning shoppers can pay with one click without leaving your website.

Subscription support

Recurring payments run through RedSys with WooCommerce Subscriptions, YITH Subscriptions and SUMO Subscriptions, including saved card renewals.

Sequential invoice numbers

The plugin creates sequential invoice numbers automatically, which helps stores meet the invoicing rules that apply to businesses in Spain.

Multisite, WPML and terminals

Works on WordPress Multisite networks, is compatible with WPML for multilingual stores, and lets one store manage two transaction terminals.

Error alerts and developer filters

Admins get an email when a customer hits a payment error, and filters let developers adjust currencies, terminals, logos and the gateway language.

WooCommerce Servired RedSys Spain Gateway older versions

  • 32.0.0Jul 305 new, 1 improvement, 2 fixes
  • 31.0.5Jul 41 fix
  • 31.0.3Jun 301 new, 1 improvement, 10 fixes, 1 security fix
  • 31.0.2Jun 19
  • 31.0.1Jun 12
  • 30.4.1May 8
  • 30.4.0Apr 28
  • 30.3.1Mar 26
  • 30.3.0Mar 11
  • 30.2.1Mar 5

Members and buyers of this product can download older versions.

65 older versions in all. If you need one that is not listed, ask support.

Questions about WooCommerce Servired RedSys Spain Gateway

Which banks and payment methods does it work with?

It connects to RedSys, the gateway used by Spanish banks including CaixaBank, Santander and BBVA. Through it you can offer card payments with InSite, Bizum, Apple Pay, Google Pay, MasterPass, Paygold and direct bank transfers in your WooCommerce checkout.

Can I use it for subscription products?

Yes. It supports recurring payments through RedSys with WooCommerce Subscriptions, YITH Subscriptions and SUMO Subscriptions. Saved card tokenization allows renewals to be charged without the customer entering card details again.

Do I need WooCommerce for this plugin?

Yes, it requires WooCommerce. It adds RedSys payment methods to the WooCommerce checkout and adds refunds, preauthorizations and bulk actions to the WooCommerce order admin.

Will it work on a multilingual or multisite setup?

It supports WordPress Multisite and is compatible with WPML. Filters also let you set the gateway language, currencies, terminals and logos, so it can fit stores that serve customers in several languages.

Is WooCommerce Servired RedSys Spain Gateway free?

The code of WooCommerce Servired RedSys Spain Gateway is licensed under the GPL, so anyone may use, change and share it. GPL Feast is a paid service: a plan or a single purchase gives you the download and automatic updates. The developer's own support, licence key and online services are not included.

Which version of WooCommerce Servired RedSys Spain Gateway is this?

Version 32.1.0, released Sep 9, 2026. New versions appear here when the developer publishes them, and members get them as automatic updates.

How do I update WooCommerce Servired RedSys Spain Gateway?

Install the free GPL Feast Updater on your site and connect it with your API key. It installs new versions of WooCommerce Servired RedSys Spain Gateway automatically and keeps a backup, so you can roll back.

What does WooCommerce Servired RedSys Spain Gateway need?

WooCommerce Servired RedSys Spain Gateway needs WooCommerce installed and active.

More from WooCommerce

WooCommerce Servired RedSys Spain Gateway 32.1.0Request an update or report a problem

Log in to ask for a newer version or report a problem with this product.

Log in