WooCommerce Redsys Gateway 32.1.x

The development of this version has cost 2,300 euros. The accumulated cost for this year is 37,430 euros. The accumulated cost since the first version is 236,160 euros, but the cost for you is only the license of 79€.

New branch 32.1.x of the Redsys plugin for WooCommerce from WooCommerce.com.

Branch Versions

• 32.1.0

32.1.0

New:

• The WooCommerce status report (WooCommerce – Status) now also lists what is enabled in the “Advanced Settings” tab of Redsys: push notifications, sequential invoices, QR codes, saved cards, order status overrides, conditional rules, subscriptions, email reconciliation, agency commerce protocols, and the management app API. Credentials are never printed: each one only indicates whether it is configured or not. It is included when copying the report to send to support, which is precisely the goal: a support request arrives already with the configuration inside.
• You can now decide whether your customers are offered “Add a credit card for Subscriptions” in My Account – Payment Methods. Until now, this option appeared alone whenever there was an active subscription plugin, with no way to remove it, and that is not what every store wants: in a store where the subscription card is always captured during the purchase, the only thing it did was invite the customer to save a card that would never be charged. The new switch is in Redsys – Advanced Settings – Saved Cards, it is activated so that nothing changes in stores that already offered it, and by deactivating it, only the 1-click card remains. It is also reported in the WooCommerce status report.

Security:

• The plugin was writing the address of the “order received” page of each purchase in its own log file, for all payments, and that address contains the order key: the private token that WooCommerce places in the buyer’s payment link and that this plugin requires before showing an order. Anyone with read access to the log file could, therefore, open those orders and see the name, email, phone number, and addresses they contain. This occurred whether or not debugging logging was enabled in the store, because that specific point wrote to the log without checking that setting. Now it respects the debugging setting like the rest of the logs that the plugin writes, and the key is replaced with “[redacted]” before writing anything, so it is not logged even with logging enabled. This replacement has been applied to all log lines of the plugin, not just the one reported: around ninety more lines spread across gateways printed those same addresses whenever debugging logging was active, including those that dump the complete message sent to the bank. Already written log files still contain those addresses: if you have them, delete them.
• The page that redirects the buyer to Redsys (and Bizum) accepted any order number written in its address, without checking that the requester was the one who made that order. Since order numbers are sequential, someone could traverse them and read the data that the plugin sends to the bank of other customers’ orders: name, email, phone number, and billing and shipping addresses, along with the amount and description of what was purchased. At no time was a card number, security code, or signature key exposed, and through this route, nothing could be paid or modified. That page now requires the order key that WooCommerce includes in the buyer’s payment link, so a request that does not correspond to the order is responded to with a “Forbidden” page instead of being attended to. The same check has been added to the payment popup of the checkout page. Reported by the security team of Tivify (TVUP Streaming Media), who clearly described the problem and gave us time to correct it before making it public. Thank you.
• The three pre-authorization buttons on the order screen (authorize, cancel, and charge a part) and the customer search of PayGold accepted their requests without a security token. The permission check was already in place, so only a store manager or an administrator could use them and no one else could have executed them, but an administrator with the session already open could be tricked into firing them from another website without realizing it. The four now carry and verify a WordPress security token, which closes that route.
• The Agency Commerce Protocol could end up activated without anyone having chosen it, in stores that update automatically. It publishes addresses with which machines can talk, so it is designed to be deactivated unless you activate it, and now it is. If you had it activated, nothing changes for you.
• The included Google library in the plugin has been updated, correcting two bugs in the part that makes network requests.

Updated:

• When the renewal of a subscription fails, the note added to the order now says exactly which step failed and with which commerce code and terminal the attempt was made. Until now, the six possible failures wrote the same note, which was not very informative, making it almost impossible to diagnose a failed renewal without access to the store, especially in stores where debugging logging is not being written.
• When Apple Pay fails to validate the store with Apple, the log now collects the explanation from Apple itself and whether the certificate files can be read. Apple responds with a generic “Expectation Failed” and puts the real reason in the body of its response, which was never being logged, so those failures were a dead end.
• The distributed plugin no longer contains the development and build scripts of the project, the configuration of its local testing environment, its editor and git hooks directories, its README for developers, or an internal security review document. None of that was loaded when the plugin runs, but it also doesn’t matter on a store’s server. What the package contains is now automatically checked before each release against a list of what the plugin actually distributes, so that something added to the project in the future cannot travel inside the zip without anyone noticing.
• The email reconciliation task now only exists while that function is activated, and only once. Previously it was created in all stores and woke up every five minutes without doing anything.
• All translations are back to being complete. Sixty-nine texts added by recent versions were still appearing in English: settings labels, the status report, and some messages that a buyer can see. Spanish, Catalan, Basque, Galician, French, and Portuguese are back to one hundred percent.
• The token that protects the “add a card” link is now compared in constant time, like the rest of the secrets that this plugin compares. Timing that comparison over the internet is not a practical attack, so there was nothing exploitable; the flaw was the inconsistency, because this was the only comparison that fell behind when the others were migrated during the signature work.

Fixed:

• With InSite, paying with a card that the buyer had saved could charge the money and still show the order as failed. When the bank approves such a payment without asking the buyer to confirm with their bank app, which is what happens with a saved card, the plugin looked for the result in the wrong place, found nothing, and treated that “nothing” as a rejection. The charge had already been made, so buyers who were told that the payment had failed paid a second time and were charged twice. The result is now read from the bank’s own signed response, the same one that the rest of the payment uses. It affected both the classic checkout and the block checkout, and also subscription renewals. Reported by two stores with a few days apart, one of them tracing it to the exact line. Thank you.
• In the card gateway, a payment made with a saved card was marked as completed with only the authorization number, without checking the actual response from the bank that goes alongside it. A rejected payment that still had something in that field therefore marked the order as paid, and the store sent the merchandise without having charged. Now it is required that both match before completing an order. If the bank’s response is completely missing, the payment is not completed, because there is nothing to say it was approved; a store whose bank actually omits that field can purposely restore the previous behavior with the filter redsys_allow_payment_without_ds_response, which is documented and cannot be used to accept a payment that the bank has rejected.
• In stores that use certain checkout plugins, Fluid Checkout among them, all payments were rejected by Redsys with the error SIS0574. The bank requires a brief description of the buyer’s browser with each payment (their language, screen size, and similar), which the plugin collects through hidden fields added to the checkout. Those fields were added at the time the card gateway was built, which in those stores happens after another plugin has already requested WooCommerce the final list of checkout fields, and WooCommerce builds that list only once and never again. The fields, therefore, were not created, not filled, and not sent, and the bank rejected the payment. Now they are added as soon as the plugin loads, before anyone can request the list, which affects all gateways that need them, the card, Bizum, and wallets, and not just InSite. In InSite, the browser description also travels now with the rest of the payment data instead of relying only on the order, so it survives a checkout that rebuilds itself. Reported by an integrator who already brought the demonstrated diagnosis. Thank you.
• If a payment was canceled or rejected, the buyer returned to the store but the order remained pending and the cart was not restored. The address that the plugin gave to the bank to return to the buyer was written in the form used for links within a web page, not in the form used for a real address, so the store received the return without the order reference, without its number, and without its security token, and had nothing to cancel. It affected Bizum, Google Pay, Apple Pay, direct debit, transfer, InSite, and the card gateway whenever the “return to” setting is set to cancel the order. In MasterPass, that same address was sent directly empty, due to a single character writing error repeated in three lines. Everything now goes through a single piece of shared code, so that a gateway added in the future cannot make the same mistake again.
• In the modal payment mode, canceling a payment did nothing and the buyer remained in the cart with the pending order. The address to which the plugin sent the browser was written on the page in a way that the browser interprets as a link within a document and not as a web address, so everything that went after the first parameter was discarded: the order reference, its number, and its security token disappeared, and WooCommerce had nothing to cancel. The same defect affected the address to which the buyer is returned after paying, where it silently lost a tracking parameter. Both are fixed, in the card gateway and in InSite, and the corrected behavior has been verified in a real browser.
• The checkout could die with a critical error, instead of sending the buyer to the bank, with a registered customer whose customer record had never been modified since it was created. The plugin builds a set of security data for the bank with each payment, and one of the fields is the date when the customer’s account was last modified, which WooCommerce leaves empty in an account that has never been touched, normally one created by an import, a migration, or automatically by another plugin. The plugin read that empty date as if it were a real date and the payment page stopped there. Now it resorts to the account creation date, which is what “never modified” means, and the same protection has been added to the equivalent code used by subscriptions, where that same empty date was being silently reported to the bank as “modified today,” which is incorrect information for their fraud controls.
• Redsys and other gateways could disappear from the checkout for everyone, including normal buyers, in stores where the “show only to these users” list of the testing mode had never been filled. The plugin read that empty setting as “show it to a user whose id is nothing,” which matches no one, so the payment method was hidden from all visitors. It only affected
  • Stores whose settings had been written by something other than the settings screen, an import, a migration, or the plugin management API itself, because saving that screen manually stores a different empty value that never triggered it. Fixed in the nine gateways that shared the same code.
  • Subscriptions paid with Apple Pay or Google Pay by a customer without an account never obtained the recurring payment permission from the bank, so the first renewal failed with a note saying there was no card. This occurred in stores where the general option to “allow customers to create an account during checkout” is disabled, something common in stores that allow guest checkout: the payment paths of the wallets did not see the override that WooCommerce Subscriptions itself makes of that option, so no account was created and, without an account, the bank’s permission could not be saved. Fixed in the four sites that manage it (Apple Pay and Google Pay, both in classic checkout and block checkout).
  • The payment script of the block checkout was compiled against a version of React that WordPress itself does not accept. A development-only dependency dragged a newer React into the build, and WordPress rejects the elements produced by it, so the payment method might not appear in the block checkout. The build now fixes the version that WordPress uses and the script has been regenerated.
  • The cart and checkout could become noticeably slow, even for unidentified visitors, in stores with saved cards or subscriptions. The internal helper WCRed() of the plugin built a new copy of its global object every time it was called, and that object registers three WordPress hooks at the time of construction. WordPress does not replace those hooks, it adds them, so in a store where the helper is called once for each saved card or subscription, the same three checks ended up being registered hundreds of times and were re-executed, all, every time WooCommerce mounted the list of available payment gateways. In a store that reported the issue, this reached about 438 duplicate records per page load and about 1.7 seconds of PHP work on the cart page, of which only 56 milliseconds were database queries. The helper now builds that object only once and reuses it, so the hooks are registered exactly once per request. The plugin’s behavior does not change at all: the object does not store request-specific data. The same treatment of an object per request has been applied to the helper WCPSD2(), which had the identical form.
  • In a small portion of stores, the message signing key of Commerce Agent (UCP) was stored in a form that could never be used, so every signature check against it failed and the published key document did not follow the standard. When the plugin created that key, one of its two coordinates occasionally returned from OpenSSL one byte shorter than required by the standard, about 1 store out of every 135, and the plugin stored it as is instead of padding it. From that moment on, the store could not verify its own signatures, nor could any external agent, until the key was rotated. The key is now stored padded to the required length, and a key already stored in the short form is automatically repaired the first time it is read, so no merchant has to rotate anything.
  • In stores with PHP 8.0 or earlier, enabling email reconciliation broke the page with a server error instead of simply not working. The plugin now checks this beforehand and leaves a clear note in its log. The function itself still requires PHP 8.1.
  • Background tasks were accumulating in dozens of copies of themselves in the scheduled actions list of WooCommerce. Fixed in all sites where the plugin schedules something, and any copies that were already there are automatically cleaned up.
  • A notification to the mobile app could be lost without giving any error if sent at the wrong time.
  • PHP notices appeared in the server log on every visit to the “checkout” page, coming from the Apple Pay and Google Pay gateways. For buyers, nothing was broken, but the debug log of those gateways was not recording anything from that step, so anyone trying to diagnose a problem there was looking at a failure and not silence. Reported by a merchant, and found in three gateways instead of the one reported. Thank you.
  • Enabling debug logging to investigate a card payment issue produced notices instead of the information for which it was activated.
  • The “Connect with Google” button in the email reconciliation settings never displayed. Granting access was already possible by filling in the Google details and clicking “Save changes”, so this restores a shortcut, it does not unlock the function.
  • The plugin sent an email to the store saying “Redsys is not sending tokenization fields” after payments where Redsys had sent every single one of them. The check behind that notice tested a variable that does not exist anywhere in the plugin, and a test on something that does not exist is always true, so the notice appeared on every payment that saved a card. Merchants took it to their bank, which rightly responded that the terminal was fine. The notice now only reports actual absences, and indicates in the log which field was missing, the expiration date, the card brand, or the number, instead of just saying something was missing. It also had to stop reading the brand after the plugin converted it into a display name, because that conversion responds “Unknown” when there is no brand, which would have turned the notice into one that could never appear. That same block wrote “unknown” as the card number in the debug log on every payment, due to a variable name with one letter too many; it now writes the actual masked number.
  • Searching on the Redsys tokens screen (WooCommerce – Redsys tokens) by email or username did not find any saved cards after the twenty-fifth. The screen requested a page of tokens from the database and then searched within that page, and since it requested them without any specific order, that page was always the twenty-five oldest tokens in the store, so recently saved cards, which are the only ones someone searches for, became unreachable. The search is now done in the database, across all tokens, and the listing comes from newest to oldest. The counter above the table and the list below can no longer disagree, sorting by username or email now sorts the entire table instead of the visible page, and the screen no longer loads all the store’s tokens into memory just to count them, which in stores with thousands of saved cards was done on every page load.