2026.09.09 – version 32.1.0
* 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.
* FIX: With 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.
* FIX: On 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.
* FIX: On 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.