Release v32.1.0
Woocommerce Redsys Gateway v32.1.0
Latest versionWhat's new in v32.1.0
Woocommerce Redsys Gateway v32.1.0 was released on . Allow customers to check out and pay via RedSys (the Servired / Sermepa successor) on your WooCommerce store. See the full changelog below and compare with the complete version history.
Release details
Released
8.0 MB
File available
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
Compatibility
- Requires WordPress
- 5.4
- Tested up to
- 7.0
- Requires PHP
- 7.4
Verified safe
Woocommerce Redsys Gateway v32.1.0 scanned clean with no security threats detected.
View full scan report