O desenvolvemento desta versión custou 2.800 euros. O custo acumulado para este ano é de 13.350 euros. O custo acumulado desde a primeira versión é de 212.080 euros, pero o custo para ti é só a licencia de 79€.
Nova versión 31.0.0 do plugin Redsys para WooCommerce de WooCommerce.com.
31.0.0
Novo:
- Nova superficie do protocolo A2A (Agent2Agent). Opcional e desactivada por defecto. Publica unha Agent Card en /.well-known/agent-card.json e un endpoint JSON-RPC 2.0 en /wp-json/wc-redsys-a2a/v1/rpc con sete skills: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card e recurrent_charge. A autenticación reutiliza o servidor de autorización OAuth 2.1 + PKCE de UCP con scopes a2a:payments:* (e un bearer de sandbox opcional para probas baixo WP_DEBUG).
- Stream de Server-Sent Events reanudable en /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream para actualizacións de tarefas en vivo, con reanudación mediante Last-Event-ID e latidos (heartbeats) cada 15s.
- Notificacións push saíntes asinadas a unha push_url rexistrada polo cliente. Cabecera X-A2A-Signature: sha256=<hmac> sobre <timestamp>.<body>, con reintentos a 1m/5m/30m/2h (máximo 4), entregadas mediante Action Scheduler.
- Nova pestana de administración "A2A (Agent2Agent)" dentro de Redsys Avanzado -> Agentic Commerce, con Estado / Clientes (crear / revogar / rotar bearers de sandbox) / Límites e modos (max_amount, sensitive_threshold e modos de pago expostos) / Confirmacións (aprobar reembolsos ou cargos recorrentes detidos en input-required).
- Topes por skill: max_amount é un límite máximo estricto que falla a tarefa con limit_exceeded; sensitive_threshold detén a tarefa en input-required ata que un administrador a confirma. Ambos sen límite por defecto (opcional).
- Rexistro de auditoría de só anexado (append-only) en wp_redsys_a2a_audit_log. Nunca se almacenan os payloads en bruto: só un hash SHA-256 máis un resumo saneado de unha liña que enmascara PAN, tokens, segredos e a parte local dos emails.
- Almacenamento auto-reparábel. As catro táboas A2A recréanse baixo demanda mediante o ensure_table() de cada store, de modo que unha táboa eliminada nunca provoque un erro fatal.
- Soporte para axentes de compra con IA (ChatGPT, Claude, Gemini, Perplexity e outros). Os axentes de IA agora poden descubrir os teus produtos, montar carritos, completar pagamentos e recibir actualizacións de pedidos desde a túa tenda. Soportanse tanto o estándar ACP de OpenAI/Stripe como o estándar aberto UCP (respaldado por Google, Shopify e outros), e cada un pode activarse ou desactivarse de forma independente.
- Nova subsección "Agentic Commerce" dentro dos axustes de Redsys Avanzado, con interruptores por función (carritos, descontos, fulfillment, consentimento do comprador, rexistro dinámico de clientes, etc.) e botóns de un clic para probar os fluxos de descubrimento de axentes, OAuth e webhook.
- Sinatura de webhooks cun botón "Rotar clave de sinatura". As claves rotadas seguen sendo válidas durante 7 días para que as integracións existentes sigan funcionando durante o cambio.
- O modal de campos personalizados de Express (Apple Pay / Google Pay) agora tamén recolle os campos rexistrados mediante a API de Blocks en checkouts clásicos, de modo que NIF/DNI e campos similares sempre aparecen independentemente do checkout que uses.
- Acción masiva opcional "Aprobar preautorización" para a lista de pedidos (Redsys Redirección). Desactivada por defecto por seguridade; actívala nos axustes da pasarela só se precisas confirmar pedidos preautorizados en masa.
Nota:
- Activar este soporte NON significa que os asistentes de IA vaian a empezar a completar compras na túa tenda desde o primeiro día. O fluxo completo de checkout dirixido por axentes aínda se está desplegando, especialmente en Europa, onde os requisitos de SCA/3DS, PSD2 e consentimento RGPD fan que a maioría de axentes hoxe se detean no descubrimento de produtos ou no pre-carrito e devolvan o pagamento final ao cliente. A túa tenda está lista para o día en que cada axente active o fluxo completo no teu mercado.
Actualizado:
- O modal de campos personalizados de Express agora precarga a súa configuración ao cargar a páxina e inicia Apple Pay de forma síncrona ao facer clic, correndo os casos nos que iOS Safari abortaba a folla de pago.
- Os campos personalizados de Express na páxina de produto volven a usar o modal por defecto. O formulario en liña introducido en 30.4.1 agora é opcional mediante un filtro.
Arreglado:
- [Crítico] As renovacións de subscricións podían fallar co erro Redsys SIS0502 ("Id Oper non coincide") en hostings con Redis, Memcached ou outras cachés de obxectos persistentes. Dois workers de renovación en paralelo podían enviar dúas referencias de pedido distintas a Redsys para a mesma subscrición, provocando que a renovación fallase e se reintentase moitas veces. O bloqueo de pagamento duplicado e a referencia de pedido agora se almacenan de forma fiable independentemente do backend de caché. Afecta ás pasarelas de Redirección e InSite de Redsys.
- As renovacións de subscrición de InSite non tiñan ningunha protección de concorrencia (o bloqueo eliminábase nos erros pero nunca se creaba). Agora aplícase ás renovacións de InSite a mesma protección que usa a pasarela de redirección.
- O estado interno cacheado usado durante o checkout (datos 3DS, identificador de tarxeta gardada, caché de sinatura, estado de OAuth, estado temporal de IMAP, etc.) agora se almacena de forma que funciona correctamente en hostings con cachés de obxectos persistentes. Antes, en cachés que se comportaban mal, este estado podía desaparecer silenciosamente a metade do checkout e provocar erros SIS0502.
- Os botóns Express de Apple Pay e Google Pay (checkout de bloques e páxina de produto) fallaban en iOS Safari con "Must create a new ApplePaySession from a user gesture handler" cando o modal de campos personalizados de Express estaba activado. O modal xa non consume o clic do usuario antes de lanzar Apple Pay.
- O IRPF de Autónomos Premium calculábase mal no Pago Express (Apple Pay / Google Pay) na páxina de produto cando o cliente elixía o tipo de usuario no modal de Express, porque o gardado do modal competía coa primeira chamada do servidor de Apple Pay. O tipo de usuario agora envíase xunto con cada petición de Express Pay, de modo que os totais son sempre correctos.
- En páxinas de produto con produtos virtuais, a folla de Apple Pay mostraba brevemente o total correcto (subtotal + impostos) e logo revertía ao prezo do produto sen impostos. O callback de envío agora mantén o último total devolto polo servidor.
- Ao gardar os axustes de Agentic Commerce descartábase silenciosamente o envío "Gardar cambios" de WooCommerce por culpa de formularios HTML aninhados. A páxina de axustes reestrutúrase e todos os botóns de acción única (probar descubrimento, probar OAuth, accións de webhook, etc.) agora funcionan correctamente xunto co botón principal de Gardar.
- Os botóns Express de Apple Pay e Google Pay na páxina de produto asignaban a zona de envío incorrecta cando a rexión do cliente estaba restrinxida por provincia. Apple/Google Pay envían o nome localizado do estado (p. ex. "Barcelona") en administrativeArea, pero as zonas de envío de WooCommerce coinciden por código de estado (p. ex. "B"); a zona país-por-estado non coincidía e o carrito caía nunha zona máis cara (p. ex. "Resto de Europa"). Os nomes de estado agora normalízanse a códigos de estado de WooCommerce antes da busca de zona de envío e a creación do pedido.
- O checkout de InSite con Bloques podía crear pedidos duplicados cando Redsys emitía o mesmo postMessage de token de pagamento máis dunha vez (ou cando o gardado se executaba de forma concurrente). Agora unha protección evita a creación de pedidos duplicados/concurrentes e reiníciase se o formulario de pagamento se refresca tras un erro.
- O rexistro de depuración REST de InSite facía referencia ao obxecto equivocado para ler o flag de depuración, polo que o payload "REST trataPeticion" podía rexistrarse (ou saltarse) independentemente do axuste de depuración da pasarela. Agora usa o propio flag de depuración da pasarela.
31.0.1
Actualizado:
- A conta atrás do modal de Bizum na páxina de pagamento mostraba 7 minutos. Agora mostra correctamente 5 minutos, e o control de tempo do lado do servidor que redirixe ao checkout axustouse en consecuencia (60 iteracións * 5 segundos = 5 minutos).
Arreglado:
- Bizum na páxina de pagamento (Bizum InSite) non enviaba a descrición a Redsys. O cargo real desde o modal realízase a través da API REST (trataPeticionREST), e esa petición non incluía o parámetro DS_MERCHANT_PRODUCTDESCRIPTION, polo que a "Descrición de Redsys" configurada (por exemplo "Order ID") chegaba vacía ao panel de Redsys. A descrición agora calcúlase a partir do axuste seleccionado e envíase na petición REST.
31.0.2
Actualizado:
- O filtro redsys_modify_data_to_send agora recibe 'context' => 'add_payment_method' e 'user_id' no array de datos para o fluxo de "Engadir método de pagamento", de modo que os snippets personalizados e as regras condicionais poden enrutar a tokenización ao terminal correcto (terminal + SHA256) sen depender dun pedido que non existe neste fluxo.
- Actualizadas todas as traduccións.
Arreglado:
- Engadir unha tarxeta desde Mi conta ("Engadir método de pagamento") en tendas multidivisa podía ser rexeitado por Redsys cun erro de divisa. A petición enviábase coa divisa da sesión do cliente (por exemplo ARS, 32) pero co terminal por defecto, que está configurado para outra divisa (por exemplo EUR, 978). A tokenización de tarxeta é unha operación de importe cero sen un pedido detrás, así que se ningún filtro ou regra condicional enruta a petición a outro terminal, agora envíase a divisa base da tenda, que sempre coincide coa configuración do terminal por defecto.
- Engadir unha tarxeta desde Mi conta (ou mediante o enlace do email de perfil) rexistraba sempre a tarxeta en Redsys como one-click (DS_MERCHANT_COF_TYPE 'C'), incluso cando o cliente seleccionaba a opción de subscricións. O tipo de token lémbrao da clave interna equivocada, polo que nunca se enviaba 'R'. O token gardábase correctamente como R en WooCommerce, pero o acordo COF creábase como C en Redsys, o que podía provocar que algúns emisores rexeitasesen posteriormente as renovacións de subscrición (MIT) feitas con eses tokens. As tarxetas engadidas coa opción de subscricións agora envían correctamente DS_MERCHANT_COF_TYPE 'R'. Os tokens creados mentres o erro estaba presente non se poden reclasificar; se unha renovación é rexeitada, pide ao cliente que volva engadir a tarxeta.
- Os pagamentos feitos cunha tarxeta gardada (token R) e as renovacións de subscrición non respectaban os axustes de preautorización. Con "Preautorizar todos os pedidos" activado (ou un produto marcado para preautorización), o cargo executábase como unha venda normal (tipo 0) pero o pedido marcábase igualmente como "Preautorizado", de modo que confirmar a preautorización máis tarde fallaba en Redsys con SIS0059 ("Non existe operación sobre a que realizar a confirmación"). Ambos fluxos agora envían unha preautorización real de tipo 1 que se pode confirmar despois, e un pedido só se marca como "Preautorizado" cando se executou unha preautorización real. Isto tamén habilita as renovacións de subscrición preautorizadas (por exemplo, produtos vendidos ao peso, onde cada renovación se axusta antes do cargo final).
Seguridade:
- A clave secreta SHA-256 do comercio xa non se escribe en texto plano nos rexistros de depuración de WooCommerce. Todas as entradas de depuración agora enmascaran a clave, mostrando só os seus últimos 4 caracteres, mediante o novo helper WCRed()->mask_secret(). Aplicado en todas as pasarelas (Redirección, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliación bancaria e as clases de soporte de Blocks).
- As sinaturas das notificacións (IPN) de Redsys agora verifícanse con hash_equals() (comparación en tempo constante) en todos os manexadores de notificación, unificándoos coa verificación que xa usaban InSite e o cliente REST. Endurecemento fronte a ataques de temporización (timing attacks).
- O manexador AJAX de borrado dun único token na pantalla de xestión de tokens agora require a capacidade manage_woocommerce ademais do nonce, igualándoo ao manexador de borrado masivo.
