El desarrollo de esta versión ha costado 2.950 euros. El coste acumulado para este año es de 40.380 euros. El coste acumulado desde la primera versión es de 239.110 euros, pero el coste para ti es solo la licencia de 79€.

Nueva rama 32.2.x del plugin Redsys para WooCommerce de WooCommerce.com.

Es una versión de mantenimiento: refuerzo de la seguridad y corrección de los fallos encontrados al probar todos los flujos de pago contra el entorno de pruebas de Redsys. No trae ninguna gran funcionalidad nueva.

Tabla de contenido

Versiones de la rama

32.2.0

32.2.0

Nuevo:

Nuevo filtro redsys_insite_form_language, para elegir desde código el idioma del formulario de tarjeta de InSite (por ejemplo, uno por cada idioma del sitio).
Nuevo filtro redsys_customer_tokens_limit, para cambiar cuántas tarjetas guardadas de un cliente lee el plugin (500 por defecto).
La licencia del plugin se gestiona ahora en WooCommerce – Ajustes – Ajustes avanzados de Redsys – General, en la parte superior de la página, y ya no tiene su propia entrada en el menú de WooCommerce. La clave de licencia, la forma de activarla y el lugar donde se guarda no cambian, y la dirección antigua sigue funcionando: te lleva al sitio nuevo. El aviso que pide una licencia también apunta allí.

Seguridad:

UCP MCP (desactivado por defecto): un agente podía pedir a lookup_catalog cualquier número de productos y recibir una respuesta de cualquier tamaño. Una consulta admite ahora como máximo 50 productos y ninguna herramienta devuelve más de 1 MB (ambos límites se pueden ajustar con filtros).
UCP MCP (desactivado por defecto) no guardaba ningún registro de lo que hacían los agentes. Cada llamada a una herramienta se escribe ahora en un registro de auditoría (qué cliente agente, qué herramienta, el resultado y su duración; los argumentos solo como una huella y un resumen enmascarado), que se conserva 90 días.
UCP MCP (desactivado por defecto) no tenía límite de peticiones. Cada dirección tiene además un presupuesto que se comprueba antes de la autenticación (300 llamadas por minuto por defecto), y una petición por lotes lleva como máximo 20 llamadas.
UCP MCP (desactivado por defecto) no tenía límite de peticiones. Cada cliente agente tiene ahora un presupuesto de 60 llamadas a herramientas por minuto, 600 por hora y 5000 al día (el mismo que A2A, ajustable con el filtro redsys_ucp_mcp_rate_limits); superado ese presupuesto, las llamadas reciben un error 429.
Cambio de comportamiento. UCP MCP (desactivado por defecto): los argumentos de las herramientas se comprueban ahora contra el esquema de entrada publicado de cada herramienta antes de ejecutarla; las llamadas que no lo cumplen (por ejemplo, sin meta.ucp-agent.profile) reciben un error JSON-RPC -32602 que enumera lo que está mal.
Cambio de comportamiento. UCP (desactivado por defecto): el registro dinámico de clientes (Dynamic Client Registration), es decir, que cualquier agente de IA cree su propio cliente OAuth en la tienda, viene ahora desactivado por defecto, y al actualizar se desactiva una sola vez allí donde solo estaba activado por el valor por defecto antiguo. Si tus agentes se registran solos, vuelve a activar “Permitir el registro dinámico de clientes” en los ajustes de UCP.
ACP (desactivado por defecto): su comprobación de “HTTPS obligatorio” se creía una cabecera X-Forwarded-Proto o X-Forwarded-SSL viniera de quien viniera. Estas cabeceras cuentan ahora solo si proceden de los proxies indicados en el ajuste “Trusted proxies” (A2A – Status). AVISO: si estás detrás de un proxy o de una CDN que termina el HTTPS, indica ahí sus direcciones después de actualizar.
UCP OAuth (desactivado por defecto): los códigos de autorización se guardaban en la base de datos en texto plano, mientras que de los tokens se guardaba su hash. Ahora los códigos también se guardan como hash.
Cambio de comportamiento. UCP OAuth (desactivado por defecto) acepta ahora únicamente el método PKCE S256, como exige el perfil UCP; “plain” se rechaza. Un desarrollador que lo necesite puede devolver true desde el filtro redsys_ucp_allow_pkce_plain.
Cambio de comportamiento. UCP OAuth (desactivado por defecto): el endpoint de introspección de tokens respondía a cualquiera. Ahora exige las credenciales del cliente que llama (client_id y client_secret) y solo informa sobre los tokens de ese mismo cliente, como exige el RFC 7662.
A2A (desactivado por defecto): después del paso de autenticación de la tarjeta, se podía enviar al comprador a cualquier dirección que hubiera indicado el agente, incluidas direcciones http sin cifrar o direcciones internas. Ahora solo se usan direcciones https en hosts públicos; en caso contrario, el comprador llega a la página del pedido. El filtro redsys_a2a_sca_return_url permite restringirlo aún más.
UCP MCP (desactivado por defecto): cuando una herramienta fallaba dentro de la tienda, el agente recibía el texto interno del error (que puede incluir rutas del servidor). Ahora recibe un identificador de correlación; el detalle se escribe en el registro del plugin.
Cambio de comportamiento. UCP y A2A (desactivados por defecto) ya no aceptan el token de acceso en la URL (?access_token=), donde acaba en los registros del servidor; envíalo en la cabecera Authorization. Un desarrollador que necesite el comportamiento anterior puede devolver true desde el filtro redsys_allow_bearer_in_query_string.
UCP OAuth (desactivado por defecto): dos peticiones de token enviadas a la vez con el mismo código de autorización podían tener éxito las dos. El código se canjea ahora de forma atómica; solo una petición obtiene tokens.
Inespay: después de comprobar la firma de la notificación, el plugin seguía dejando que campos sin firmar de la petición rellenaran valores que los datos firmados no traían (como el identificador del pago). Ahora solo se usan los datos firmados.
Apple Pay y Google Pay marcaban el pedido como pagado sin comprobar que el importe cobrado por Redsys coincidiera con el total del pedido, como ya hacen los pagos con tarjeta y con Bizum. Un importe distinto deja ahora el pedido en espera con una nota, para que lo revises.
A2A (desactivado por defecto): cuando una operación fallaba dentro de la tienda, el agente recibía el texto interno del error (que puede incluir rutas del servidor). Ahora recibe un mensaje genérico con un identificador de correlación; el detalle se escribe en el registro del plugin.
App Redsys Manager: un empleado cuyo rol de WordPress se rebajaba a cliente o suscriptor conservaba su perfil de la app y, con él, el acceso a los pedidos y a los datos de clientes. Su perfil de la app se elimina ahora cuando cambia el rol.
Los documentos públicos de descubrimiento para agentes de IA (UCP /.well-known/ucp y el documento well-known de ACP) publicaban la dirección de correo electrónico del administrador de WordPress. Ahora publican la dirección indicada en el nuevo ajuste “Support e-mail for AI agents”, o ninguna.
A2A (desactivado por defecto): el importe de reembolso a partir del cual un administrador de la tienda debe confirmar (“umbral sensible”) se comprobaba reembolso a reembolso, así que dividir un reembolso lo esquivaba. Ahora se suma lo que el mismo cliente ha reembolsado en el mismo pedido en las últimas 24 horas. AVISO: una serie de reembolsos pequeños sobre un mismo pedido puede quedar ahora a la espera de tu confirmación.
A2A (desactivado por defecto): la lista de IP permitidas de un cliente se podía superar enviando una cabecera X-Forwarded-For con una dirección permitida. El plugin comprueba ahora la dirección de la propia conexión y solo se cree X-Forwarded-For si procede de los proxies indicados en el nuevo ajuste “Trusted proxies” (A2A – Status). AVISO: si tu sitio está detrás de una CDN o de un balanceador de carga y un cliente A2A tiene una lista de IP permitidas, añade las direcciones de la CDN a ese ajuste después de actualizar, o el cliente será rechazado.
A2A (desactivado por defecto): los flujos de tareas (task streams) ignoraban el límite de peticiones del cliente, de modo que un solo cliente podía abrir los suficientes como para ocupar los procesos PHP de la tienda. Cada flujo cuenta ahora para el límite y un cliente puede mantener como máximo cinco a la vez.
Desactivar A2A en los ajustes no detenía a los clientes que ya estaban configurados. Con A2A desactivado, su endpoint JSON-RPC y sus flujos de tareas responden ahora 503 y no se envía ninguna notificación push.
Las acciones en lote de Redsys de la lista de pedidos (cargo inmediato, reembolso en lote, aprobar preautorización) necesitan ahora el mismo permiso que sus versiones para un solo pedido (gestionar WooCommerce) y solo se ejecutan mientras su ajuste está activado.
A2A (desactivado por defecto): la dirección push que un agente indica para las notificaciones de tareas podía hacer que la tienda llamara a su propio servidor o a su red interna, incluso por http sin cifrar. Ahora debe ser https en el puerto 443 de un host público, y las notificaciones usan el transporte HTTP seguro de WordPress.
Webhooks de ACP (desactivados por defecto): un proveedor podía registrar un webhook que apuntara al propio servidor de la tienda o a su red interna. La URL de un webhook debe estar ahora en el puerto 443 de un host público (un filtro permite otra cosa para desarrollo), los webhooks registrados antes que incumplen la regla ya no se llaman, y las entregas usan el transporte HTTP seguro de WordPress.
UCP (desactivado por defecto): la dirección del perfil de plataforma que un agente envía en su cabecera UCP-Agent podía hacer que la tienda llamara a su propio servidor o a su red interna. Ahora solo se consultan direcciones https en el puerto 443 de hosts públicos, mediante el transporte HTTP seguro de WordPress.
Webhooks de UCP (desactivados por defecto): un cliente podía registrar un webhook que apuntara al propio servidor de la tienda o a su red interna, y bastaba con un token de solo lectura. La URL de un webhook debe ser ahora https en el puerto 443 hacia un host público, registrar o borrar uno necesita el permiso (scope) de escritura de checkout, los webhooks registrados antes que incumplen la regla ya no se llaman, y las entregas usan el transporte HTTP seguro de WordPress.
UCP, MCP y A2A (desactivados por defecto) aceptaban un token de refresco de OAuth como si fuera un token de acceso. Ahora solo los tokens de acceso abren esas rutas.
Checkouts agénticos (UCP y ACP, desactivados por defecto): un agente de IA podía poner en un pedido productos que la tienda no vende: borradores, productos privados o sin existencias, productos padre variables o agrupados. El pedido se rechaza ahora (422) e indica cuáles son los productos.
La ventana “Ver detalles” del plugin leía la respuesta del servidor de actualizaciones con una función que puede construir objetos PHP. Ahora lee esa respuesta únicamente como datos planos.
La petición de datos del navegador para 3-D Secure del checkout podía escribir esos datos en cualquier número de pedido. Ahora solo los escribe en el pedido del propio visitante y, en caso contrario, los guarda en su sesión.
Checkout agéntico (ACP, desactivado por defecto): un pedido creado por un agente de IA se asociaba a cualquier cliente registrado cuyo correo electrónico enviara el agente. Ahora se queda como pedido de invitado; las tiendas que quieran el comportamiento anterior pueden devolver true desde el filtro redsys_acp_link_order_to_customer_by_email.
La compra con 1 clic tomaba del navegador el coste y el nombre del envío, de modo que un cliente con la sesión iniciada podía pagar menos por el envío (o nada). El envío lo recalcula ahora la tienda y debe ser una de las opciones que la tienda ofrece; un producto que necesita envío no se puede comprar sin él.
Los catálogos agénticos (el catálogo de UCP y el feed de productos de ACP, ambos desactivados por defecto) listaban borradores y “Productos privados”, y la consulta de un solo producto de UCP devolvía productos sin publicar. Los agentes solo ven ahora productos publicados que no sean privados. Una variación de un producto privado también es privada.
Las acciones en lote “Request Redsys card” y PayGold de la pantalla de Usuarios no comprobaban que la petición viniera de esa pantalla, de modo que una página de otro sitio podía hacer que un administrador con la sesión iniciada enviara correos de solicitud de tarjeta (u operaciones de PayGold) a usuarios arbitrarios. Ahora exigen el testigo de seguridad de la pantalla de Usuarios y permisos de gestor de tienda. Además, el manejador de PayGold deja de interferir con las acciones en lote de otros plugins en esa pantalla.
Checkout agéntico (ACP): revocar un token de acceso no borraba su aprobación en caché, así que un token revocado seguía funcionando hasta cinco minutos. La revocación tiene ahora efecto inmediato.
Checkout agéntico (ACP, desactivado por defecto): los tokens de acceso generados como “Solo lectura” se aceptaban para crear, modificar y cancelar pedidos y para gestionar webhooks. Ahora son de solo lectura.
Checkout agéntico (ACP, desactivado por defecto): una sesión de checkout podía ser leída, modificada, completada o cancelada por cualquier cliente que conociera su identificador. Las sesiones responden ahora solo al proveedor de IA que las creó.
Checkout agéntico (ACP, desactivado por defecto): un cliente que usara una clave de la API REST de WooCommerce podía hacerse pasar por otro proveedor de IA y leer, borrar o añadir webhooks de ese proveedor. El proveedor se toma ahora únicamente de la credencial; los bearer tokens registrados en los ajustes agénticos de WooCommerce se resuelven ahora a su proveedor (de modo que los webhooks de ACP funcionan como estaba previsto), y una sesión sin proveedor ya no envía sus eventos a los webhooks de todos los proveedores.
Checkout agéntico (UCP, desactivado por defecto): una sesión de checkout podía ser leída, modificada, completada o cancelada por cualquier cliente que conociera su identificador, y los endpoints de pedidos se saltaban la comprobación de propietario para un token sin usuario. Las sesiones responden ahora solo al cliente y al comprador que las crearon, y un token sin usuario se rechaza.
Checkout agéntico (ACP, desactivado por defecto): un agente podía cambiar la dirección y el total de un pedido que ya estaba pagado, cancelarlo sin reembolso o enviarlo de nuevo a la página de pago. Esas peticiones se rechazan ahora (409) una vez que el pedido ya no está abierto; un pedido preautorizado se anula desde la administración de la tienda, no por un agente.
Checkout agéntico (UCP, desactivado por defecto): un agente podía seguir cambiando los artículos y el total de una sesión de checkout después de que su pedido estuviera pagado, o cancelar el pedido pagado sin reembolso. Una sesión cuyo pedido está pagado, cancelado o fallido ya no se puede modificar ni cancelar.
InSite en el checkout de bloques podía asociar a un pedido nuevo el número de pago de Redsys en curso de otro comprador, de modo que la confirmación de pago de ese comprador podía acabar en el pedido equivocado. Un número que ya pertenece a otro pedido ya no se asocia.
El enlace de redirección de “añadir método de pago” respondía a cualquiera y, cuando se le daba un número de pedido, reescribía los ajustes de terminal y de clave de ese pedido con los valores por defecto (lo que rompía los reembolsos posteriores en tiendas con varios terminales). Ahora solo responde al cliente con la sesión iniciada que empezó a añadir la tarjeta, y nunca escribe datos del pedido.
La notificación de pago con tarjeta ponía su marca de “ya en proceso” antes de comprobar la firma, de modo que una petición falsificada podía hacer que la tienda ignorara durante un minuto la notificación auténtica de Redsys y dejara pendiente un pedido pagado. La marca se pone ahora solo después de comprobar que la firma es válida.
App de gestión (desactivada por defecto): un perfil de personal con permiso para editar clientes podía editar también la cuenta de un administrador, incluido el correo electrónico, lo que basta para apropiarse de ella con un restablecimiento de contraseña. Las pantallas de clientes de la app solo cargan y editan ahora cuentas de clientes, nunca de personal.
La activación de la licencia y las comprobaciones de actualización hablaban con plugins.joseconti.com sin verificar su certificado TLS, y se fiaban de lo que dijera la respuesta sobre qué plugin actualizar y de dónde descargarlo. Ahora el TLS se verifica siempre, la actualización ofrecida es siempre para este plugin, y la descarga debe llegar por https desde el propio servidor de licencias.
Conciliación de pagos por correo electrónico (IMAP/Gmail, desactivada por defecto): un correo cuyo remitente simplemente contuviera la dirección de Redsys podía marcar como pagado un pedido pendiente, y también podía hacerlo un correo real de Redsys sobre un pago denegado. Ahora el remitente debe ser exactamente la dirección indicada en los ajustes, y el correo debe mostrar un pago aprobado por el importe del pedido y con su código de comercio; en caso contrario, el pedido se deja como estaba y recibe una nota. Si en esos ajustes escribiste solo una parte de la dirección de Redsys (o solo el dominio), escribe la dirección completa.
Se ha eliminado una dirección REST de InSite que no se usaba (woocommerce-redsys/v1/save_order_data) y que permitía que una petición que solo llevara una cabecera Referer coincidente cambiara el número de pedido de Redsys guardado en cualquier pedido, del que dependen los reembolsos. El checkout de bloques no la usa desde la 31.0.4.
Checkout agéntico (UCP, desactivado por defecto): un pedido creado por un agente de IA se asociaba al cliente registrado que fuera dueño del correo electrónico que enviaba el agente, lo que además dejaba al alcance las tarjetas guardadas de ese cliente. El pedido pertenece ahora al cliente que autorizó al agente, y nunca a alguien por una dirección de correo.
Apple Pay exprés guardaba una marca temporal bajo un nombre tomado del navegador, y ese nombre podía coincidir con las marcas que el plugin lee para confirmar pagos. Las marcas de las wallets (Apple Pay y Google Pay) se guardan ahora bajo sus propios nombres con hash.
Completa, para la página de pago por redirección, el arreglo de las tarjetas guardadas de esta misma versión. La tarjeta elegida en el checkout también se trasladaba al formulario de pago firmado de Redsys sin comprobar de quién era. El formulario usa ahora una tarjeta guardada solo si pertenece al cliente que paga; en caso contrario, pide una tarjeta nueva (una tarjeta de suscripción nueva cuando el pedido tiene una suscripción).
Cada pedido conserva la clave de Redsys con la que se pagó, para que los reembolsos y las renovaciones sigan funcionando cuando se usan varios terminales. La API REST de WooCommerce devolvía esa clave a cualquier integración con una clave de API de solo lectura. Ya no se incluye en las respuestas REST de pedidos ni de suscripciones; se sigue guardando y usando exactamente igual que antes.
Con “Show the Redsys page inside the store” (modo iframe), y en todos los pedidos de Bizum Checkout, los enlaces de retorno mostraban las direcciones de cancelación y de pedido recibido de un pedido, con su clave privada, a cualquiera que las pidiera, durante todo el tiempo que la tienda conservara una marca que no caducaba nunca. Ahora solo responden al comprador dueño del pedido (los enlaces de retorno enviados a Redsys llevan la clave del pedido para ello), y la marca caduca al cabo de un día.
Un enlace del endpoint de notificaciones, usado por el paso ya retirado del método de 3-D Secure, enviaba a cualquier visitante a la página de pago del número de pedido indicado en el enlace, incluida su clave privada de pedido. Ahora solo envía allí al comprador dueño del pedido (tarjeta e InSite).
Los campos adicionales que piden los botones exprés de Apple Pay y Google Pay (NIF/DNI y similares) guardaban cualquier nombre de campo que llevara la petición, en el pedido y en la cuenta del cliente. Ahora guardan solo los campos que define tu tienda, y nunca los datos internos del plugin. Las tiendas que muestran botones exprés deberían actualizar.
Una tarjeta guardada podía ser cobrada por alguien a quien no pertenecía. La tarjeta se identifica en la petición del checkout con un número de fila, y el plugin no comprobaba de quién era la tarjeta, de modo que una petición manipulada podía cobrar la tarjeta guardada de otro cliente sin que el banco pidiera a ese cliente confirmar nada. Cada cobro con una tarjeta guardada comprueba ahora que la tarjeta pertenece al cliente que está pagando, y en caso contrario rechaza el pago; un identificador de tarjeta que no existe ya no provoca un error fatal. Las tiendas que ofrecen tarjetas guardadas deberían actualizar. Reportado en privado, con la causa ya localizada, por una tienda que eligió avisarnos primero y no publicar nada. Gracias.

Arreglado:

Actualizar con UCP activado terminaba en un “error crítico” (Call to a member function using_index_permalinks() on null) en la primera carga de página después de la actualización. El archivo público de descubrimiento de UCP se reescribe ahora cuando WordPress ha terminado de cargar.
Tarjetas guardadas caducadas: las tareas programadas que avisan al cliente y eliminan las tarjetas caducadas fallaban con un error de base de datos (“You have an error in your SQL syntax”) y nunca hacían nada. Ahora funcionan, eliminan también las tarjetas que caducaron en un año anterior y solo tocan las tarjetas guardadas por este plugin.
InSite: el ajuste “Idioma de la pasarela” se ignoraba, así que los campos de la tarjeta (los textos de ejemplo y el botón) se mostraban siempre en español. El idioma elegido se envía ahora a Redsys en el checkout clásico y en el checkout de bloques.
Clientes con más de 10 tarjetas guardadas: las renovaciones de suscripciones y el “Cargo inmediato en Redsys” podían usar una tarjeta más antigua en lugar de la más reciente, una tarjeta ya guardada podía guardarse otra vez, y el checkout clásico no listaba las tarjetas más recientes. El plugin lee ahora todas las tarjetas de Redsys del cliente para sus propias decisiones.
Licencia: cuando el servidor de licencias rechazaba la activación, la página de ajustes solo decía “Tus ajustes se han guardado.”. Ahora se muestra el error devuelto por el servidor, y una clave rechazada ya no aparece como “La licencia está activa”.
Licencia: guardar los Ajustes avanzados de Redsys con la licencia ya activa la enviaba a activar de nuevo en cada guardado. Una licencia activa ya no se vuelve a enviar.
“Cargo inmediato en Redsys” (y cualquier cobro con una tarjeta guardada): cuando Redsys rechazaba el cobro en su primer paso, el pedido se quedaba pendiente sin ninguna explicación. El motivo y el código de error de Redsys se escriben ahora en una nota del pedido.
InSite en el checkout de bloques: una tarjeta guardada para el “Pago con 1 clic” después de un desafío 3DS se almacenaba como tarjeta de suscripción. Ahora se almacena con el tipo con el que se solicitó.
InSite en el checkout de bloques: el botón de pago decía siempre “Pagar”. Ahora muestra la etiqueta “Pay” traducida al idioma del sitio.
InSite en el checkout de bloques: en un servidor sin la extensión SOAP de PHP el pago terminaba en un “error crítico”. El cliente recibe ahora un mensaje que le pide elegir otro método de pago, y la causa se escribe en el log de InSite.
Checkout clásico: con Bizum y Bizum Checkout ambos en modo de pruebas, el aviso de modo de pruebas se mostraba dos veces.
Compra con 1 clic desde la página de producto: las opciones de envío mostraban “€” en lugar del símbolo de la moneda.
Confirmar una preautorización escribía dos veces la nota de estado del pedido, y pasaba el pedido a Completado aunque hubiera otro estado configurado para las preautorizaciones confirmadas.
Checkout de bloques: cuando Bizum Checkout era denegado, se devolvía al cliente al checkout sin ningún mensaje. Ahora se muestra el error, como ya ocurría en el checkout clásico.
Checkout de bloques: un pedido pagado con Bizum (u otra pasarela de este plugin que use una página de pago) por un cliente con una tarjeta guardada quedaba registrado como pagado con tarjeta. El pedido conserva el método de pago con el que se hizo.
Bizum, Bizum Checkout, Google Pay, Apple Pay, Domiciliación bancaria y PayGold en modo de pruebas: con la clave de pruebas configurada y el campo de la clave real vacío, Redsys autorizaba el pago pero el pedido se quedaba pendiente, porque la notificación se rechazaba. En modo de pruebas la notificación se verifica ahora con la clave de pruebas.
Checkout de bloques: pagar con una tarjeta guardada (Pago con 1 clic) era rechazado por Redsys con el error SIS0574 (browserUserAgent no indicado). Los datos del navegador para 3DS se adjuntan ahora al pedido también en el checkout de bloques.
Apple Pay: el log de depuración muestra ahora los parámetros realmente enviados a Redsys, leídos de la propia petición firmada. Antes sus líneas se escribían por separado y podían diferir de la petición: los parámetros de suscripción se enviaban pero no se registraban, y la línea del MerchantID de Apple se registraba incluso cuando no se enviaba.
Mi cuenta – Métodos de pago: la columna “Tipo” imprimía avisos de PHP (Undefined array key “delete”, Undefined variable $token_type_name) en tarjetas o cuentas guardadas por otras pasarelas, por ejemplo PayPal. Ahora describe solo las tarjetas guardadas por este plugin y muestra “–” para cualquier otro método guardado.
Bizum Checkout: la página de espera que se muestra mientras se confirma el pago cargaba jQuery desde ajax.googleapis.com. Ahora usa la copia que incluye WordPress, de modo que la página no hace ninguna petición a terceros.
readme.txt declaraba una línea de licencia mal formada y “Tested up to: 7.0”, mientras que la cabecera del plugin decía 7.1. Ambos archivos dicen ahora GPL-3.0-or-later y 7.1.
ACP (desactivado por defecto): con ACP activado, WordPress podía registrar “Translation loading for the woocommerce domain was triggered too early” cuando se programaba por primera vez la limpieza horaria de ACP. Ahora se programa en init.
Las acciones programadas duplicadas que dejaron versiones anteriores se eliminan ahora solas: los workers emparejados redsys_acp_process_webhooks / redsys_ucp_process_webhooks, un redsys_check_emails_cron sin grupo y las limpiezas diarias repetidas. Desde la 32.1.0 no se creaban nuevas, pero las que ya existían seguían ahí.
El text domain del plugin es ahora su slug, woocommerce-gateway-redsys (antes era woocommerce-redsys), en todas las cadenas, en los archivos de traducción incluidos y en los scripts del checkout de bloques. Los archivos de traducción personalizados guardados con el nombre antiguo en wp-content/languages/plugins o por Loco Translate siguen funcionando. Las traducciones guardadas en la base de datos por un plugin multilingüe (WPML String Translation, Polylang) y el código personalizado que filtre gettext por el dominio antiguo necesitan el nombre nuevo.
Tres cadenas usaban el text domain de WooCommerce y cuatro contadores de estados de pedido no tenían ninguno; una de ellas (el correo en texto plano de pedido cancelado) no se podía traducir nunca. Ahora usan el del plugin.
Las renovaciones de suscripciones no enviaban ninguna descripción a Redsys, así que la operación aparecía con la descripción vacía en el TPV (los primeros pagos estaban bien). Las renovaciones y los cobros de facturas de la pasarela por redirección, y las renovaciones de InSite, envían ahora la descripción elegida en los ajustes de la pasarela, como hacían antes de que las renovaciones pasaran a la API REST.
Pagar en el checkout con una tarjeta guardada (pasarela por redirección) enviaba siempre “Order N” como descripción, dijera lo que dijera el ajuste de la pasarela. Ahora sigue el ajuste.
ACP (desactivado por defecto): el documento público de ACP anunciaba un límite de 60 peticiones por minuto que nunca se aplicaba. El anuncio se ha eliminado.
UCP OAuth (desactivado por defecto): dos refrescos enviados a la vez con el mismo token de refresco podían obtener cada uno un nuevo par de tokens. El token de refresco se gasta ahora de forma atómica; la segunda petición recibe invalid_grant.
A2A (desactivado por defecto): el importe máximo fijado para create_payment y tokenize_card no se aplicaba. Los importes superiores se rechazan ahora antes de crear ningún pedido.
Una notificación de pago fallida o tardía (por ejemplo, el resultado “denegado” de un intento anterior que llega después de que el pedido se haya pagado) podía cancelar un pedido que ya estaba pagado, en Bizum y en los demás métodos de pago de Redsys. Un pedido pagado ya no lo cancela nunca una notificación; una nota registra lo que envió Redsys.
“Productos privados” (desactivado por defecto) no funcionaba: los productos marcados como privados solo se quitaban del listado de la tienda y cualquiera podía seguir viéndolos y comprándolos, y la lista de usuarios permitidos se guardaba vacía. Un producto privado queda ahora oculto (página de producto, Blocks/Store API) y no lo puede comprar nadie que no esté en su lista; los gestores de tienda lo ven siempre. IMPORTANTE si usas esta opción: abre cada producto privado y vuelve a seleccionar sus usuarios permitidos, porque las versiones anteriores perdieron esas listas. Un aviso en las pantallas de producto te lo recuerda.
En modo de pruebas, “Mostrar a estos usuarios” limita una pasarela a los usuarios que elijas. El checkout de bloques lo ignoraba y mostraba la pasarela a todos los visitantes, invitados incluidos; después el pedido se rechazaba, así que el cliente veía un método de pago que fallaba al pulsarlo. Todas las pasarelas aplican ahora la lista en el checkout de bloques igual que en el clásico. Un filtro para desarrolladores, redsys_gateway_shown_to_user, permite ajustar la decisión. Reportado con la causa ya localizada. Gracias.
Apple Pay y Google Pay (checkout) tenían el campo “Mostrar a estos usuarios” pero no lo aplicaban nunca, en ningún checkout. Ahora lo aplican.
Con Inespay, un usuario de la lista “Mostrar a estos usuarios” podía seguir sin verlo, porque la lista guardada se comparaba de forma incorrecta. Los usuarios de la lista lo ven ahora.
Con el “Pago con 1 clic” desde la página de producto activo, el plugin añadía dos encabezados, “Términos y condiciones” y “Selecciona el método de envío”, a todas las páginas de producto, aunque nadie hubiera abierto esas ventanas, lo que ensuciaba la estructura de la página que leen los buscadores y las herramientas de accesibilidad. Esas ventanas se construyen ahora solo cuando se abren de verdad, y su título ya no es un encabezado: en su lugar da nombre a la ventana para los lectores de pantalla, cosa que las ventanas de términos y de envío no hacían antes. No cambia nada en lo que ve el cliente. Reportado por una tienda que lo encontró en su auditoría de encabezados. Gracias.
El script y los estilos del “Pago con 1 clic” desde la página de producto se cargaban en todas las páginas de producto, incluso donde el botón no aparece nunca porque la opción está desactivada o el visitante no ha iniciado sesión. Ahora se cargan solo donde aparece el botón.

Desarrollo:

El paquete publicado en WooCommerce.com ya no incluye el cliente de licencias y actualizaciones que usan las copias compradas en plugins.joseconti.com (allí no se cargaba nunca). El plugin lo carga solo cuando el archivo está presente.
Se ha añadido phpstan.neon (con las librerías de terceros incluidas en el plugin excluidas y una línea base de los hallazgos existentes) para que el análisis estático informe solo de problemas nuevos.