--- title: "WooCommerce Redsys Gateway 31.0.0" description: "El desarrollo de esta versión ha costado 2.800 euros. El coste acumulado para este año es de 13.350 euros. El coste acumulado desde la primera versión es de 212.080 euros, pero el coste para ti es..." url: https://plugins.joseconti.com/2026/06/08/woocommerce-redsys-gateway-31-0-0/ date: 2026-06-08 modified: 2026-06-09 author: "jconti" image: https://plugins.joseconti.com/wp-content/uploads/2026/06/woocommerce-redsys-gateway-31-0-0-scaled.jpg categories: ["WooCommerce.com"] type: post lang: es --- # WooCommerce Redsys Gateway 31.0.0 > El desarrollo de esta versión ha costado 2.800 euros. El coste acumulado para este año es de 13.350 euros. El coste acumulado desde la primera versión es de 212.080 euros, pero el coste para ti es (https://plugins.joseconti.com/product/plugin-woocommerce-redsys-gateway/) de 79€. Nueva versión 31.0.0 del plugin Redsys para WooCommerce de (https://plugins.joseconti.com/product/plugin-woocommerce-redsys-gateway/). ## 31.0.0 ### Nuevo: - Nueva superficie del protocolo A2A (Agent2Agent). Opcional y desactivada por defecto. Publica una Agent Card en /.well-known/agent-card.json y un endpoint JSON-RPC 2.0 en /wp-json/wc-redsys-a2a/v1/rpc con siete skills: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card y recurrent_charge. La autenticación reutiliza el servidor de autorización OAuth 2.1 + PKCE de UCP con scopes a2a:payments:* (y un bearer de sandbox opcional para pruebas bajo WP_DEBUG). - Stream de Server-Sent Events reanudable en /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream para actualizaciones de tareas en vivo, con reanudación mediante Last-Event-ID y latidos (heartbeats) cada 15s. - Notificaciones push salientes firmadas a una push_url registrada por el cliente. Cabecera X-A2A-Signature: sha256= sobre ., con reintentos a 1m/5m/30m/2h (máximo 4), entregadas mediante Action Scheduler. - Nueva pestaña de administración “A2A (Agent2Agent)” dentro de Redsys Avanzado -> Agentic Commerce, con Estado / Clientes (crear / revocar / rotar bearers de sandbox) / Límites y modos (max_amount, sensitive_threshold y modos de pago expuestos) / Confirmaciones (aprobar reembolsos o cargos recurrentes detenidos en input-required). - Topes por skill: max_amount es un límite máximo estricto que falla la tarea con limit_exceeded; sensitive_threshold detiene la tarea en input-required hasta que un administrador la confirma. Ambos sin límite por defecto (opcional). - Registro de auditoría de solo anexado (append-only) en wp_redsys_a2a_audit_log. Nunca se almacenan los payloads en bruto: solo un hash SHA-256 más un resumen saneado de una línea que enmascara PAN, tokens, secretos y la parte local de los emails. - Almacenamiento auto-reparable. Las cuatro tablas A2A se recrean bajo demanda mediante el ensure_table() de cada store, de modo que una tabla eliminada nunca provoque un error fatal. - Soporte para agentes de compra con IA (ChatGPT, Claude, Gemini, Perplexity y otros). Los agentes de IA ahora pueden descubrir tus productos, montar carritos, completar pagos y recibir actualizaciones de pedidos desde tu tienda. Se soportan tanto el estándar ACP de OpenAI/Stripe como el estándar abierto UCP (respaldado por Google, Shopify y otros), y cada uno puede activarse o desactivarse de forma independiente. - Nueva subsección “Agentic Commerce” dentro de los ajustes de Redsys Avanzado, con interruptores por función (carritos, descuentos, fulfillment, consentimiento del comprador, registro dinámico de clientes, etc.) y botones de un clic para probar los flujos de descubrimiento de agentes, OAuth y webhook. - Firma de webhooks con un botón “Rotar clave de firma”. Las claves rotadas siguen siendo válidas durante 7 días para que las integraciones existentes sigan funcionando durante el cambio. - El modal de campos personalizados de Express (Apple Pay / Google Pay) ahora también recoge los campos registrados mediante la API de Blocks en checkouts clásicos, de modo que NIF/DNI y campos similares siempre aparecen independientemente del checkout que uses. - Acción masiva opcional “Aprobar preautorización” para la lista de pedidos (Redsys Redirección). Desactivada por defecto por seguridad; actívala en los ajustes de la pasarela solo si necesitas confirmar pedidos preautorizados en masa. ### Nota: - Activar este soporte NO significa que los asistentes de IA vayan a empezar a completar compras en tu tienda desde el primer día. El flujo completo de checkout dirigido por agentes todavía se está desplegando, especialmente en Europa, donde los requisitos de SCA/3DS, PSD2 y consentimiento RGPD hacen que la mayoría de agentes hoy se detengan en el descubrimiento de productos o el pre-carrito y devuelvan el pago final al cliente. Tu tienda está lista para el día en que cada agente active el flujo completo en tu mercado. ### Actualizado: - El modal de campos personalizados de Express ahora precarga su configuración al cargar la página e inicia Apple Pay de forma síncrona al hacer clic, corrigiendo los casos en que iOS Safari abortaba la hoja de pago. - Los campos personalizados de Express en la página de producto vuelven a usar el modal por defecto. El formulario en línea introducido en 30.4.1 ahora es opcional mediante un filtro. ### Arreglado: - **** Las renovaciones de suscripciones podían fallar con el error Redsys SIS0502 (“Id Oper no coincide”) en hostings con Redis, Memcached u otras cachés de objetos persistentes. Dos workers de renovación en paralelo podían enviar dos referencias de pedido distintas a Redsys para la misma suscripción, provocando que la renovación fallara y se reintentara muchas veces. El bloqueo de pago duplicado y la referencia de pedido ahora se almacenan de forma fiable independientemente del backend de caché. Afecta a las pasarelas de Redirección e InSite de Redsys. - Las renovaciones de suscripción de InSite no tenían ninguna protección de concurrencia (el bloqueo se eliminaba en los errores pero nunca se creaba). Ahora se aplica a las renovaciones de InSite la misma protección que usa la pasarela de redirección. - El estado interno cacheado usado durante el checkout (datos 3DS, identificador de tarjeta guardada, caché de firma, estado de OAuth, estado temporal de IMAP, etc.) ahora se almacena de forma que funciona correctamente en hostings con cachés de objetos persistentes. Antes, en cachés que se comportaban mal, este estado podía desaparecer silenciosamente a mitad del checkout y provocar errores SIS0502. - Los botones Express de Apple Pay y Google Pay (checkout de bloques y página de producto) fallaban en iOS Safari con “Must create a new ApplePaySession from a user gesture handler” cuando el modal de campos personalizados de Express estaba activado. El modal ya no consume el clic del usuario antes de lanzar Apple Pay. - El IRPF de Autónomos Premium se calculaba mal en el Pago Express (Apple Pay / Google Pay) en la página de producto cuando el cliente elegía el tipo de usuario en el modal de Express, porque el guardado del modal competía con la primera llamada del servidor de Apple Pay. El tipo de usuario ahora se envía junto con cada petición de Express Pay, de modo que los totales son siempre correctos. - En páginas de producto con productos virtuales, la hoja de Apple Pay mostraba brevemente el total correcto (subtotal + impuestos) y luego revertía al precio del producto sin impuestos. El callback de envío ahora mantiene el último total devuelto por el servidor. - Al guardar los ajustes de Agentic Commerce se descartaba silenciosamente el envío “Guardar cambios” de WooCommerce por culpa de formularios HTML anidados. La página de ajustes se ha reestructurado y todos los botones de acción única (probar descubrimiento, probar OAuth, acciones de webhook, etc.) ahora funcionan correctamente junto al botón principal de Guardar. - Los botones Express de Apple Pay y Google Pay en la página de producto asignaban la zona de envío incorrecta cuando la región del cliente estaba restringida por provincia. Apple/Google Pay envían el nombre localizado del estado (p. ej. “Barcelona”) en administrativeArea, pero las zonas de envío de WooCommerce coinciden por código de estado (p. ej. “B”); la zona país-por-estado no coincidía y el carrito caía en una zona más cara (p. ej. “Resto de Europa”). Los nombres de estado ahora se normalizan a códigos de estado de WooCommerce antes de la búsqueda de zona de envío y la creación del pedido. - El checkout de InSite con Bloques podía crear pedidos duplicados cuando Redsys emitía el mismo postMessage de token de pago más de una vez (o cuando el guardado se ejecutaba de forma concurrente). Ahora una protección evita la creación de pedidos duplicados/concurrentes y se reinicia si el formulario de pago se refresca tras un error. - El registro de depuración REST de InSite hacía referencia al objeto equivocado para leer el flag de depuración, por lo que el payload “REST trataPeticion” podía registrarse (o saltarse) independientemente del ajuste de depuración de la pasarela. Ahora usa el propio flag de depuración de la pasarela. ## 31.0.1 ### Actualizado: - La cuenta atrás del modal de Bizum en la página de pago mostraba 7 minutos. Ahora muestra correctamente 5 minutos, y el control de tiempo del lado del servidor que redirige al checkout se ha ajustado en consecuencia (60 iteraciones * 5 segundos = 5 minutos). ### Arreglado: - Bizum en la página de pago (Bizum InSite) no enviaba la descripción a Redsys. El cargo real desde el modal se realiza a través de la API REST (trataPeticionREST), y esa petición no incluía el parámetro DS_MERCHANT_PRODUCTDESCRIPTION, por lo que la “Descripción de Redsys” configurada (por ejemplo “Order ID”) llegaba vacía al panel de Redsys. La descripción ahora se calcula a partir del ajuste seleccionado y se envía en la petición REST.