The development of this version cost 2,800 euros. The accumulated cost for this year is 13,350 euros. The accumulated cost since the first version is 212,080 euros, but the cost for you is only the license of 79€.
New version 31.0.0 of the Redsys plugin for WooCommerce from WooCommerce.com.
31.0.0
New:
- New A2A (Agent2Agent) protocol surface. Optional and disabled by default. Publishes an Agent Card at /.well-known/agent-card.json and a JSON-RPC 2.0 endpoint at /wp-json/wc-redsys-a2a/v1/rpc with seven skills: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card, and recurrent_charge. Authentication reuses the OAuth 2.1 + PKCE authorization server from UCP with scopes a2a:payments:* (and an optional sandbox bearer for testing under WP_DEBUG).
- Resumable Server-Sent Events stream at /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream for live task updates, with resumption via Last-Event-ID and heartbeats every 15s.
- Outgoing push notifications signed to a push_url registered by the client. Header X-A2A-Signature: sha256=<hmac> over <timestamp>.<body>, with retries at 1m/5m/30m/2h (maximum 4), delivered via Action Scheduler.
- New admin tab "A2A (Agent2Agent)" within Advanced Redsys -> Agentic Commerce, with Status / Clients (create / revoke / rotate sandbox bearers) / Limits and modes (max_amount, sensitive_threshold, and exposed payment modes) / Confirmations (approve refunds or recurring charges held in input-required).
- Limits by skill: max_amount is a strict maximum limit that fails the task with limit_exceeded; sensitive_threshold halts the task in input-required until an administrator confirms it. Both have no default limit (optional).
- Append-only audit log in wp_redsys_a2a_audit_log. Raw payloads are never stored: only a SHA-256 hash plus a sanitized one-line summary that masks PAN, tokens, secrets, and the local part of emails.
- Self-repairing storage. The four A2A tables are recreated on demand via each store's ensure_table(), so that a deleted table never causes a fatal error.
- Support for AI shopping agents (ChatGPT, Claude, Gemini, Perplexity, and others). AI agents can now discover your products, build carts, complete payments, and receive order updates from your store. Both the OpenAI/Stripe ACP standard and the open UCP standard (backed by Google, Shopify, and others) are supported, and each can be enabled or disabled independently.
- New "Agentic Commerce" subsection within Advanced Redsys settings, with function switches (carts, discounts, fulfillment, buyer consent, dynamic customer registration, etc.) and one-click buttons to test agent discovery flows, OAuth, and webhook.
- Webhook signing with a "Rotate signing key" button. Rotated keys remain valid for 7 days so that existing integrations continue to work during the change.
- The Express custom fields modal (Apple Pay / Google Pay) now also collects fields registered via the Blocks API in classic checkouts, so that NIF/DNI and similar fields always appear regardless of the checkout you use.
- Optional bulk action "Approve preauthorization" for the order list (Redsys Redirection). Disabled by default for security; enable it in the gateway settings only if you need to confirm preauthorized orders in bulk.
Note:
- Enabling this support DOES NOT mean that AI assistants will start completing purchases in your store from day one. The full agent-driven checkout flow is still being rolled out, especially in Europe, where SCA/3DS, PSD2, and GDPR consent requirements cause most agents to stop at product discovery or pre-cart and return the final payment to the customer. Your store is ready for the day when each agent activates the full flow in your market.
Updated:
- The Express custom fields modal now preloads its configuration when the page loads and initiates Apple Pay synchronously on click, fixing cases where iOS Safari aborted the payment sheet.
- The Express custom fields on the product page revert to using the default modal. The inline form introduced in 30.4.1 is now optional via a filter.
Fixed:
- [Critical] Subscription renewals could fail with the Redsys SIS0502 error ("Id Oper does not match") on hosts with Redis, Memcached, or other persistent object caches. Two renewal workers in parallel could send two different order references to Redsys for the same subscription, causing the renewal to fail and retry many times. Duplicate payment locking and order reference are now reliably stored regardless of the cache backend. Affects Redsys Redirection and InSite gateways.
- InSite subscription renewals had no concurrency protection (the lock was removed on errors but never created). The same protection used by the redirection gateway now applies to InSite renewals.
- The cached internal state used during checkout (3DS data, saved card identifier, signature cache, OAuth state, temporary IMAP state, etc.) is now stored in a way that works correctly on hosts with persistent object caches. Previously, on poorly behaving caches, this state could silently disappear mid-checkout and cause SIS0502 errors.
- The Express Apple Pay and Google Pay buttons (block checkout and product page) failed in iOS Safari with "Must create a new ApplePaySession from a user gesture handler" when the Express custom fields modal was enabled. The modal no longer consumes the user click before launching Apple Pay.
- The Premium Self-Employed IRPF was calculated incorrectly in Express Payment (Apple Pay / Google Pay) on the product page when the customer chose the user type in the Express modal, because the modal saving competed with the first call from the Apple Pay server. The user type is now sent with each Express Pay request, so totals are always correct.
- On product pages with virtual products, the Apple Pay sheet briefly showed the correct total (subtotal + taxes) and then reverted to the product price without taxes. The submission callback now retains the last total returned by the server.
- Saving the Agentic Commerce settings silently discarded the "Save changes" submission from WooCommerce due to nested HTML forms. The settings page has been restructured, and all single-action buttons (test discovery, test OAuth, webhook actions, etc.) now work correctly alongside the main Save button.
- The Express Apple Pay and Google Pay buttons on the product page assigned the wrong shipping zone when the customer's region was restricted by province. Apple/Google Pay sends the localized state name (e.g., "Barcelona") in administrativeArea, but WooCommerce shipping zones match by state code (e.g., "B"); the country-by-state zone did not match, and the cart fell into a more expensive zone (e.g., "Rest of Europe"). State names are now normalized to WooCommerce state codes before shipping zone lookup and order creation.
- InSite checkout with Blocks could create duplicate orders when Redsys issued the same payment token postMessage more than once (or when saving was executed concurrently). Now a protection prevents the creation of duplicate/concurrent orders and resets if the payment form refreshes after an error.
- The InSite REST debug log referenced the wrong object to read the debug flag, so the payload "REST trataPeticion" could be logged (or skipped) regardless of the gateway's debug setting. It now uses the gateway's own debug flag.
31.0.1
Updated:
- The countdown in the Bizum modal on the payment page showed 7 minutes. It now correctly shows 5 minutes, and the server-side time control that redirects to checkout has been adjusted accordingly (60 iterations * 5 seconds = 5 minutes).
Fixed:
- Bizum on the payment page (Bizum InSite) did not send the description to Redsys. The actual charge from the modal is done via the REST API (trataPeticionREST), and that request did not include the DS_MERCHANT_PRODUCTDESCRIPTION parameter, so the configured "Redsys Description" (e.g., "Order ID") arrived empty at the Redsys panel. The description is now calculated from the selected setting and sent in the REST request.
31.0.2
Updated:
- The redsys_modify_data_to_send filter now receives 'context' => 'add_payment_method' and 'user_id' in the data array for the "Add payment method" flow, so that custom snippets and conditional rules can route tokenization to the correct terminal (terminal + SHA256) without relying on an order that does not exist in this flow.
- All translations updated.
Fixed:
- Adding a card from My Account ("Add payment method") in multi-currency stores could be rejected by Redsys with a currency error. The request was sent with the client's session currency (e.g., ARS, 32) but with the default terminal, which is configured for another currency (e.g., EUR, 978). Card tokenization is a zero-amount operation without an order behind it, so if no filter or conditional rule routes the request to another terminal, it now sends the store's base currency, which always matches the default terminal's configuration.
- Adding a card from My Account (or via the profile email link) always registered the card in Redsys as one-click (DS_MERCHANT_COF_TYPE 'C'), even when the customer selected the subscription option. The token type was read from the wrong internal key, so 'R' was never sent. The token was correctly saved as R in WooCommerce, but the COF agreement was created as C in Redsys, which could cause some issuers to subsequently reject subscription renewals (MIT) made with those tokens. Cards added with the subscription option now correctly send DS_MERCHANT_COF_TYPE 'R'. Tokens created while the error was present cannot be reclassified; if a renewal is rejected, ask the customer to re-add the card.
- Payments made with a saved card (token R) and subscription renewals did not respect preauthorization settings. With "Preauthorize all orders" enabled (or a product marked for preauthorization), the charge was executed as a normal sale (type 0) but the order was still marked as "Preauthorized", so confirming the preauthorization later failed in Redsys with SIS0059 ("No operation exists to perform the confirmation"). Both flows now send a real type 1 preauthorization that can be confirmed later, and an order is only marked as "Preauthorized" when a real preauthorization has been executed. This also enables preauthorized subscription renewals (e.g., weight-based products, where each renewal is adjusted before the final charge).
Security:
- The SHA-256 secret key of the merchant is no longer written in plain text in WooCommerce debug logs. All debug entries now mask the key, showing only its last 4 characters, using the new helper WCRed()->mask_secret(). Applied across all gateways (Redirection, InSite, Bizum, Google Pay, Apple Pay, PayGold, Direct Debit, and Blocks support classes).
- The signatures of Redsys notifications (IPN) are now verified with hash_equals() (constant time comparison) in all notification handlers, unifying them with the verification already used by InSite and the REST client. Hardened against timing attacks.
- The AJAX handler for deleting a single token on the token management screen now requires the manage_woocommerce capability in addition to the nonce, matching the bulk delete handler.
