WooCommerce – Servired/RedSys Spain Gateway

WooCommerce – Servired/RedSys Spain Gateway

- V31.0.3

WooCommerce Servired/RedSys Spain Gateway, is a premium addon wordpress plugin for the external product "WooCommerce".

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 ...
Read The Full Description Here

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.

Documentation: WooCommerce Servired/RedSys Spain Gateway Nulled

Requirements

  • Install and activate the external free product WooCommerce
  • WordPress installation (minimum version 4.6 or above)
  • PHP (minimum version 5.6 or above)

General Installation/Update Instructions

Nulled Status

  • These nulling details are restricted to the customers/members only.

Changelog: WooCommerce Servired/RedSys Spain Gateway Nulled - Version 31.0.3

2026.06.27 - version 31.0.3
* SECURITY: Removed a notification signature-bypass that could let an anonymous request mark an order as paid when the SHA-256 secret was left empty/misconfigured. The Redsys IPN listener (public wc-api endpoint) had a legacy fallback that, when no secret was configured, accepted a notification solely because the posted Ds_MerchantCode matched the merchant FUC - a public, non-secret value an attacker can supply. That merchant-code-only acceptance has been removed from every gateway (Redirection, Bizum, Bizum InSite, Google Pay checkout and redirection, Apple Pay, PayGold, Direct Debit, MasterPass and Bank Transfer): when there is no secret to verify the HMAC, the request now fails closed (HTTP rejection) instead of being trusted. In addition, the shared verification routine (WooRedsysAPI::verify_signature_notif) now returns false whenever the merchant key or the received signature is empty, so neither check_ipn_request_is_valid() nor successful_request() can complete a payment on an attacker-computable empty-key HMAC. InSite already required a valid signature (no merchant-code fallback) and Inespay is unaffected (it matches orders by its own payin id). Real stores are unaffected because a configured secret is mandatory to take payments in the first place.
* NEW: "Apps and Plugins" section under Redsys Advanced -> Redsys Advanced Settings. A read-only landing page that showcases the native macOS management app (with download, requirements and "coming soon" platforms) and lists the rest of the free and premium plugins, websites and portals, Claude skills and developer profiles by José Conti, each grouped by type with a link. Every list is filterable (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
* FIX: Bizum notifications were rejected with a signature verification error, leaving the order unpaid even though the payment had been authorized at Redsys. The merchant key and the order number were correct (the request signature matched perfectly), but the notification signature is an HMAC computed over the Ds_MerchantParameters string exactly as received, and Bizum notifications arrive with the trailing base64 "=" padding stripped while Redsys signs over the canonically padded value, so the locally computed HMAC never matched. The shared notification routine (create_merchant_signature_notif in WooRedsysAPI) now re-pads the payload to a multiple of four before hashing, and the verification (verify_signature_notif) now compares both signatures ignoring the trailing "=" padding (which carries no entropy, so the comparison stays constant-time). Card payloads are already canonical and are left untouched, so every other gateway keeps working unchanged. This routine is shared by all notification handlers (Redirection, Bizum, InSite, PayGold, Google Pay, Apple Pay, Direct Debit, Bank Transfer and the REST/A2A clients).
* FIX: Card and wallet notifications could be rejected with a "signature mismatch", so the customer returning to the thank-you page (and the server-to-server IPN) failed to mark the order as paid until a later IPN retry happened to succeed; refunds and PayGold links paid later could stay unconfirmed. Two padding issues are involved: besides the Bizum payload padding above, Redsys delivers the notification signature (Ds_Signature) in URL-safe base64 with the trailing "=" stripped, while the locally computed signature keeps it - so a strict comparison fails for ordinary card payments too. The padding-tolerant comparison lives in verify_signature_notif(), but most handlers were still comparing the signature inline with a strict hash_equals()/!== that re-introduced the sensitivity. Every handler now delegates to verify_signature_notif(), so the fix reaches all of them: card Redirection (both IPN validators and the capture/refund REST-SOAP response checks), Bizum, Bizum InSite, InSite (IPN, successful_request and the two REST-response validators), PayGold, Google Pay (checkout and redirection), Apple Pay, Direct Debit, Bank Transfer, MasterPass and the InSite REST client. Regression introduced when the per-gateway signature checks were unified onto verify_signature_notif() with a strict, padding-sensitive comparison.
* FIX: Bizum notifications on multi-currency / dual-terminal stores (those routing each order to a different terminal through the bizum_modify_data_to_send filter or a conditional rule) now resolve the real per-order signing key before verifying the signature (the customer-adjusted settings key, the transient saved when the payment form was generated, or the _redsys_secretsha256 order meta), and an unverifiable notification is rejected with HTTP 400.
* FIX: InSite card payments that required a 3DS challenge showed a blank verification screen in Safari (iPhone/Mac), so the customer could not enter the SMS code/PIN and the payment failed (the same flow worked in Chrome). The challenge itself was already a full-page, top-level navigation, but before it the plugin redirected the browser to the issuer's 3DS Method URL (threeDSMethodURL) to fingerprint the browser, and Safari's Intelligent Tracking Prevention blocks the third-party cookies that step needs, leaving a blank ACS page (symptom: the ACS URL arrives with ";jsessionidpa=" because the cookies are not flowing). The 3DS Method browser step is optional, so the plugin no longer redirects the browser to threeDSMethodURL: it always sends threeDSCompInd = 'N' and continues straight to authentication. Applied to every InSite flow - new card and saved card (one-click/token), on both block and classic (shortcode) checkouts - and to the Redirection gateway's REST/token flows (pay_with_token_c, receipt_page and successful_request), since the same blank screen could appear when charging a saved-card token.
* FIX: When an InSite card payment failed because a required checkout field was missing or its data did not match (for example an empty surname produced a "signature mismatch"), the error message blamed the card ("...enter your card details again"), so customers thought their card had been rejected and abandoned the order. The message is now neutral and points to the checkout fields first: it asks the customer to check that all the checkout fields (name, surname, address, etc.) and the card details are filled in correctly before trying again. Applied to both the classic and block (Blocks) checkouts.

More Info at the Developer's website: WooCommerce Servired/RedSys Spain Gateway Nulled

Here is the external link to the developer's website:

https://woocommerce.com/products/redsys-gateway/

Support: WooCommerce Servired/RedSys Spain Gateway Nulled

You need to be a customer to create a support request for this product