Woocommerce Redsys Gateway featured image

WooCommerce Redsys Gateway v32.1.0 - WordPress Plugin

Developer: WooCategory: WordPress PluginsTrusted with 331 downloadsLite2 favoritesLatest v32.1.0Updated 6d 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.1.0LatestVerified Safe
Sep 9, 20268.0 MB
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
Jul 28, 20267.9 MB
View changelog
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
Jul 2, 20267.8 MB
View changelog
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.

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.1.0 (released Sep 9, 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.0, 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.1.0) 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 - up to 25. Included with 12-month and Geek Lifetime plans (plus legacy 6-month).