New

• Manage your store from a native app. This release turns on the management app API that until now shipped hidden inside the plugin. Your store can be connected to PackDesk, the native macOS management app, to work with orders, refunds, products and customers without opening the WordPress dashboard. The API is served under the redsys-manager/v1 namespace and is strictly opt-in: it is OFF by default, it requires HTTPS and an active license, and no app can reach the store until a merchant enables it. It provides an order picking queue and order updates, product and customer routes, a "change…
• A new "Behaviors towards the APP" section in the Redsys advanced settings (WooCommerce – Settings – Redsys – Advanced Settings) to control how the store behaves towards the app: enable or disable the API, allow or restrict refunds for the Customer service profile (refunds are limited to the Administrator profile by default), require a minimum app version, and set the requests-per-minute limit per employee (default 300, set 0 to disable it).
• A per-user "App profile" on the WordPress user edit screen, so each employee who connects from the app operates under a profile – for example Administrator or Customer service – that decides what the app lets them see and do, including whether they may issue refunds.
• A new "Apps and Plugins" section in the Redsys advanced settings: a read-only overview of the native app and the rest of the plugins, websites and skills, all reachable from one place.
• PackDesk is now published on the Mac App Store, and the official "Download on the Mac App Store" button is shown at the top of the "Behaviors towards the APP" section and in the featured-app area of "Apps and Plugins", so the app can be installed straight from the store settings. The button uses Apple's own artwork in the language of the administrator viewing it – English, Spanish, Catalan, French or Portuguese, with English used for Basque and Galician because Apple does not publish a badge for them – and it opens the App Store of each visitor's own country. The app entry now shows the…

Improved

• Compatibility declared with WooCommerce 11. The plugin's "WC tested up to" header now reads 11.0, so WooCommerce no longer warns that the gateway has not been tested with the version you are running. The minimum supported WooCommerce is unchanged (7.4).

Fixed

• The product QR code did not appear on stores whose media library is offloaded to an external service such as Cloudflare Images. The QR image was registered in the media library correctly, but the plugin saved and displayed a URL it had built by hand from the local uploads folder instead of asking WordPress for the attachment's real URL, so on an offloaded store that address pointed at a file that is no longer served locally and the image was broken. The QR URL is now resolved through the media library (wp_get_attachment_url), the attachment id is stored alongside it, and the address is r…
• A Bizum payment could be charged at the bank yet leave the order pending, with the log showing "Signature verification failed in successful_request". The order-completion step in one of the two Bizum gateways verified the bank notification with the gateway's plain configured signature key, while the operation had been signed with the per-order key actually used for it – as happens on stores with a per-user or dual/test terminal, or the bizum_modify_data_to_send filter. The notification passed the first validation and was then rejected by this second check, so the money was taken but the…

Improved

• Apple Pay and Google Pay now always use the SECURE terminal, and the "Terminal type" selector has been removed from both wallets' settings. For a wallet the terminal type only affected the first payment (subscription renewals are charged through the card/redirection gateway, which keeps its own terminal setting), and the secure terminal already does everything that first payment needs: it charges and, for subscriptions, it requests the recurring token. The mixed terminal paid through a path that had no payment page, which is where Apple Pay as a normal payment method lost the customer…

Fixed

• Subscription products from Advanced Subscriptions for WooCommerce were never detected as subscriptions. The check guarded on function_exists( 'aswc_check_product_is_subscriptionn' ) – one letter n too many – while the body called the correctly spelled function, so check_subscription_aswc_checkout() always returned false regardless of the product. The misspelling appeared exactly once in the whole plugin and dated from the rename of the sjcfwc_ prefix to aswc_. As a result the card used for those products could be tokenised as a one-off payment instead of as a recurring one, which is what…
• Any anonymous visitor could trigger a fatal error through admin-ajax.php. The plugin registered the AJAX action check_token_insite_from_action, for both logged-in and logged-out visitors, pointing at a method of WC_Gateway_InSite_Redsys that does not exist – the implementation is called check_token_insite_from_action_checkout, which is also the action name the JavaScript actually posts and which was registered correctly on the next two lines. Requesting admin-ajax.php?action=check_token_insite_from_action produced a "call to undefined method" fatal. The two obsolete registrations have be…
• The Redsys Tokens admin page registered a form handler that was never written. admin_post_redsys_tokens_search pointed at a process_search_tokens() method that does not exist, so visiting admin-post.php?action=redsys_tokens_search produced a fatal for any logged-in user. Searching on that page has always worked through the page itself, not through that handler, so the obsolete registration has been removed and nothing changes for the user.
• Twelve user-facing texts said "Redys" instead of "Redsys" – nine email titles shown in WooCommerce, Settings, Emails, and three in the Bank Transfer gateway description. The corresponding translations in Catalan, Basque, Galician, Spanish, French and Portuguese have been updated in the same release, so no translated text is lost.
• A malformed or tampered bank notification could fill the log with "Trying to access array offset on null" warnings. When the notification could not be decoded, the routine that reads the order number from it accessed the decoded data anyway, and its fallback read an undefined index whenever neither spelling of the order key was present. It now returns an empty order number, which the callers already treat as an unresolvable notification.
• With the order number format set to "Number created by WooCommerce only with zeros" (simpleorder), adding a payment method could be rejected by Redsys as a repeated order number (SIS0051). Real orders and card-additions were numbered from the same 12-digit zero-padded space: an order with id 42 was sent as 000000000042, and so was the 42nd card-addition, because the add-card counter started at 1 and walked straight through the range of existing order ids. The same collision had a second and more damaging consequence that could reach a paid order: the plugin decides whether a bank notific…
• The InSite tokenization number could collide with the default order number format. The number InSite uses to request the card token before the order exists begins with 1, while the default format ("3 random numbers followed by zeros") builds an order number from a random 1-999 prefix: whenever that random prefix came out as exactly 100 and the InSite counter matched the order id, both produced the same value (for example 100000000042 for order 42). Unlike the previous item this one did not need any particular setting – it affected the default configuration. The InSite number keeps the 10…
• Two card-additions started at the same instant could be issued the same number and save the card onto the wrong account. Both internal counters were read and written back as two separate operations, so two simultaneous requests read the same value, incremented it to the same number, and the second request overwrote the first request's stored user id – the number is the only key those operations have, so the card ended up attached to whichever user wrote last. The counters now claim each value atomically, using the same mechanism already used for subscription renewal locks, and a claim th…