WooCommerce RedSys Gateway

Versión 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