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) / Limites 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 pagos 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 necesitas confirmar pedidos preautorizados en masa.
Nota:
- Activar este soporte NON significa que os asistentes de IA vaian comezar 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 detengan no descubrimento de produtos ou o pre-carrito e devolvan o pago 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. Duas 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 fallara e se reintentara moitas veces. O bloqueo de pago 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 totales 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 anidados. 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 carro 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 búsqueda 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 pago máis dunha vez (ou cando o gardado se executaba de forma concorrente). Agora unha protección evita a creación de pedidos duplicados/concurrentes e reiníciase se o formulario de pago 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 pago 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 pago (Bizum InSite) non enviaba a descrición a Redsys. O cargo real dende 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
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, amosando 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 firmas das notificacións (IPN) de Redsys agora verifícanse con hash_equals() (comparación en tempo constante) en todos os manexadores de notificacións, 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.
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 pago", de modo que os snippets personalizados e as regras condicionais poidan 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 dende Mi Conta ("Engadir método de pago") en tendas multidivisa podía ser rexeitado por Redsys cun erro de moeda. A petición enviábase coa moeda da sesión do cliente (por exemplo ARS, 32) pero co terminal por defecto, que está configurado para outra moeda (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 moeda base da tenda, coincidindo sempre coa configuración do terminal por defecto.
- Engadir unha tarxeta dende Mi Conta (ou mediante o enlace de email do 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 rexeitaran posteriores 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 pagos realizados 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 pode confirmarse 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 bens vendidos ao peso, onde cada renovación se axusta antes do cargo final).
31.0.3
Novo:
- Sección "Apps e Plugins" dentro de Redsys Avanzado -> Axustes Avanzados de Redsys. Unha páxina de aterrizaxe de só lectura que amosa a app nativa de xestión para macOS (con descarga, requisitos e plataformas "próximamente") e lista o resto de plugins gratuítos e premium, webs e portais, skills de Claude e perfís de desenvolvedor de José Conti, cada un agrupado por tipo cun enlace. Cada lista é filtrable (redsys_apps_plugins_mac_app, redsys_apps_plugins_free, redsys_apps_plugins_premium, redsys_apps_plugins_webs, redsys_apps_plugins_skills, redsys_apps_plugins_profiles).
Seguridade:
- Eliminado un bypass de verificación de firma de notificación que podía permitir que unha petición anónima marcara un pedido como pagado cando o secreto SHA-256 se deixaba vacío ou mal configurado. O listener de IPN de Redsys (endpoint público wc-api) tiña un fallback herdado que, cando non había secreto configurado, aceptaba unha notificación únicamente porque o Ds_MerchantCode enviado coincidía co FUC do comercio, un valor público e non secreto que un atacante pode subministrar. Esa aceptación baseada só no código de comercio eliminouse de todas as pasarelas (Redirección, Bizum, Bizum InSite, Google Pay checkout e redirección, Apple Pay, PayGold, Domiciliación Bancaria, MasterPass e Transferencia Bancaria): cando non hai secreto para verificar o HMAC, a petición agora falla de forma segura (rexeitamento HTTP) en lugar de ser confiada. Ademais, a rutina de verificación compartida (WooRedsysAPI::verify_signature_notif) agora devolve false sempre que a clave do comercio ou a firma recibida estean vacías, de modo que nin check_ipn_request_is_valid() nin successful_request() poidan completar un pago cun HMAC de clave vacía calculable polo atacante. InSite xa requiría unha firma válida (sen fallback por código de comercio) e Inespay non se ve afectado (relaciona os pedidos polo seu propio id de payin). As tendas reais non se ven afectadas, porque ter un secreto configurado é obrigatorio para poder cobrar.
Arreglado:
- As notificacións de Bizum rexeitábanse cun erro de verificación de firma, deixando o pedido sen pagar aínda que o pago se autorizara en Redsys. A clave do comercio e o número de pedido eran correctos (a firma da petición coincidía perfectamente), pero a firma da notificación é un HMAC calculado sobre a cadea Ds_MerchantParameters exactamente como se recibe, e as notificacións de Bizum chegan co recheo (padding) final "=" de base64 eliminado, mentres que Redsys firma sobre o valor co recheo canónico, así que o HMAC calculado localmente nunca coincidía. A rutina de notificación compartida (create_merchant_signature_notif en WooRedsysAPI) agora volve a rechear o payload a un múltiplo de catro antes de hashear, e a verificación (verify_signature_notif) agora compara ambas firmas ignorando o recheo final "=" (que non aporta entropía, así que a comparación segue sendo en tempo constante). Os payloads de tarxeta xa son canónicos e déixanse intactos, de modo que o resto de pasarelas seguen funcionando sen cambios. Esta rutina compártena todos os manexadores de notificación (Redirección, Bizum, InSite, PayGold, Google Pay, Apple Pay, Domiciliación Bancaria, Transferencia Bancaria e os clientes REST/A2A).
- As notificacións de tarxeta e wallet podían rexeitarse cun "signature mismatch", de modo que o cliente que volvía á páxina de grazas (e o IPN servidor a servidor) non conseguía marcar o pedido como pagado ata que un reintento posterior de IPN tiña éxito por casualidade; os reembolsos e os enlaces de PayGold pagados máis tarde podían quedar sen confirmar. Hai dous problemas de recheo implicados: ademais do recheo do payload de Bizum anterior, Redsys entrega a firma da notificación (Ds_Signature) en base64 URL-safe co "=" final eliminado, mentres que a firma calculada localmente manténaa, así que unha comparación estrita tamén falla para os pagos de tarxeta normais. A comparación tolerante ao recheo vive en verify_signature_notif(), pero a maioría dos manexadores seguían comparando a firma en liña cun hash_equals()/!== estricto que reintroducía a sensibilidade. Agora todos os manexadores delegan en verify_signature_notif(), de modo que o arranxo chega a todos: Redirección de tarxeta (ambos validadores de IPN e as comprobacións de resposta REST-SOAP de captura/reembolso), Bizum, Bizum InSite, InSite (IPN, successful_request e os dous validadores de resposta REST), PayGold, Google Pay (checkout e redirección), Apple Pay, Domiciliación Bancaria, Transferencia Bancaria, MasterPass e o cliente REST de InSite. Regresión introducida cando se unificaron as comprobacións de firma por pasarela en verify_signature_notif() cunha comparación estrita e sensible ao recheo.
- As notificacións de Bizum en tendas multidivisa / de dobre terminal (as que enrutan cada pedido a un terminal distinto mediante o filtro bizum_modify_data_to_send ou unha regra condicional) agora resolven a clave de firma real por pedido antes de verificar a firma (a clave dos axustes axustada polo cliente, o transient gardado cando se xerou o formulario de pago, ou o meta de pedido _redsys_secretsha256), e unha notificación non verificable rexeítase con HTTP 400.
- Os pagamentos con tarxeta de InSite que requirían un challenge 3DS mostraban unha pantalla de verificación en branco en Safari (iPhone/Mac), de modo que o cliente non podía introducir o código SMS/PIN e o pagamento fallaba (o mesmo fluxo funcionaba en Chrome). O challenge en si xa era unha navegación de páxina completa e de nivel superior, pero antes del el plugin redirixía o navegador á URL do 3DS Method do emisor (threeDSMethodURL) para tomar a pegada do navegador, e a Prevención de Rastreo Intelixente (ITP) de Safari bloquea as cookies de terceiros que ese paso necesita, deixando unha páxina ACS en branco (síntoma: a URL do ACS chega con ";jsessionidpa=" porque as cookies non flúen). O paso do 3DS Method no navegador é opcional, así que o plugin xa non redirixe o navegador a threeDSMethodURL: sempre envía threeDSCompInd = 'N' e continúa directamente á autenticación. Aplicado a todos os fluxos de InSite -tarxeta nova e tarxeta gardada (one-click/token), tanto en checkout de bloques como clásico (shortcode)- e aos fluxos REST/token da pasarela de Redirección (pay_with_token_c, receipt_page e successful_request), xa que a mesma pantalla en branco podía aparecer ao cobrar un token de tarxeta gardada.
- Cando un pagamento con tarxeta de InSite fallaba porque faltaba un campo obrigatorio do checkout ou os seus datos non coincidían (por exemplo, un apelido baleiro producía un "signature mismatch"), o mensaxe de erro culpaba á tarxeta ("…volta a introducir os datos da túa tarxeta"), así que os clientes pensaban que a súa tarxeta fora rexeitada e abandonaban o pedido. O mensaxe agora é neutro e apunta primeiro aos campos do checkout: pide ao cliente que comprobe que todos os campos do checkout (nome, apelidos, dirección, etc.) e os datos da tarxeta están cubertos correctamente antes de volver a intentalo. Aplicado aos checkouts clásico e de bloques (Blocks).
- Os reembolsos e pagamentos diferidos de pedidos con IDs de pedido grandes (o "bug dos mil millóns" xa corregido para o checkout instantáneo) rexistrábanse contra o pedido equivocado, ou non se rexistraban en absoluto. A notificación (IPN) de Redsys recupera o ID de pedido de WooCommerce a partir do número de pedido mediante clean_order_number(), que primeiro busca un transient gardado cando se xerou o número de pedido e, no seu defecto, recorría a unha heurística substr/ltrim que descarta os díxitos de orde alto dos IDs con 10 ou máis díxitos. Ese transient ten un TTL de 1h, así que o fallback activábase sempre que a notificación chega máis dunha hora despois de xerarse o número de pedido: cada reembolso (procesado días ou semanas despois) e os enlaces de pagamento de PayGold (pagados polo cliente máis tarde), entre outros. Tres cambios fan que sexa robusto para todos os métodos de pagamento: (1) a rutina de reembolso compartida (ask_for_refund) agora volve a gardar o mapeo número de pedido -> ID real de pedido no momento do reembolso cun TTL de 24h; (2) clean_order_number(), cando o transient xa non existe, agora busca o pedido de forma inversa polo meta persistido do número de pedido (_payment_order_number_redsys / _redsys_transaction_id2) antes de usar nunca a heurística con perda; e (3) PayGold agora persiste o número de pedido no meta cando se crea o enlace, de modo que un enlace pagado moito despois segue resolvéndose ao pedido exacto. Aplícase a todas as pasarelas (Redirección, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold e Domiciliación Bancaria). Inespay non se ve afectado (relaciona os pedidos polo seu propio id de payin).
- Os pagamentos con tarxeta de InSite no checkout de bloques (Blocks) fallaban a PRIMEIRA vez con "msg18" (o cliente vía "comproba que os campos do checkout/tarxeta están cubertos") e só funcionaban no segundo intento. O SDK de InSite de Redsys require que a páxina envíe un mensaxe "domain" ao iframe da tarxeta para que Redsys poida validar o comercio; o SDK faino mediante un onload="setMerchantDomain(0)" en liña no iframe. O script de bloques sobrescribía ese manexador co seu propio iframe.onload (usado para dimensionar o iframe) xusto despois do primeiro renderizado, así que o dominio do comercio nunca se enviaba e Redsys rexeitaba a tokenización con msg18 ("validación incorrecta por parte do comercio"). No refresco automático do formulario a sobrescritura non se executaba, así que o segundo intento funcionaba. O plugin agora chama a setMerchantDomain explícitamente despois de construir o formulario (como fai a propia integración do botón de pagamento do SDK) e xa non sobrescribe o onload do iframe, de modo que o primeiro intento funciona.
- InSite checkout de bloques: mellorouse o manexo do postMessage de Redsys e engadíronse diagnósticos de extremo a extremo. O manexador agora acepta mensaxes de calquera subdominio de Redsys (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) en lugar de esixir unha coincidencia exacta de host/porto (Redsys publica dende máis dun host), elimina calquera listener deixado por un renderizado anterior para que un único token non poida disparar múltiples envíos, e limpa os campos de token/error tras lelos para que un re-disparo obsoleto non poida reenviarlos. Cando o rexistro de depuración de InSite está activado, todo o paso de tokenización do lado do cliente (número de pedido, postMessage de Redsys, token/código de erro, gardado e place-order) reflíctese no log "insite" de WooCommerce, de modo que os fallos do primeiro intento que nunca chegan a PHP poidan diagnosticarse.
- Os pagamentos con tarxeta de InSite no checkout de bloques (Blocks) eran rexeitados por Redsys con SIS0574 ("operación de autenticación EMV3DS rexeitada, browserUserAgent non indicado"): a pegada 3DS do navegador (user agent, tamaño de pantalla, idioma, profundidade de cor, zona horaria) nunca chegaba ao pedido, porque o hook que normalmente a copia ao pedido (woocommerce_checkout_create_order) non se executa no checkout da Store API (Blocks). O formulario de InSite de Blocks agora recolle a pegada e envíaa xunto co token de operación, e escríbese no pedido real (xunto co token) antes de que se execute process_payment, de modo que a autenticación EMV3DS ten os datos que necesita.
- Os pagamentos con tarxeta de InSite no checkout de bloques (Blocks) eran rexeitados cun "código de erro sen token" (mostrado ao cliente como "comproba que os campos do checkout/tarxeta están cubertos"), de modo que a tarxeta nin sequera podía tokenizarse tras uns poucos intentos. Como o pedido aínda non existe no checkout de Blocks (id de pedido 0), o número de pedido de Redsys preparado xerábase a partir do id 0, o que producía un valor case constante -só ~999 números posibles, todos rematados en nove ceros- e Redsys rexeita un número de pedido reutilizado ("pedido repetido", SIS0051). Cando o id do pedido borrador aínda non está dispoñible, o formulario de InSite de Blocks agora usa o mesmo número de pedido temporal que o checkout shortcode de InSite (create_checkout_insite_number: sempre comeza por 1, globalmente único mediante un contador incremental compartido), así que nunca colisiona; cando o id do pedido borrador está dispoñible, o número de Redsys constrúese a partir del. O número volve a vincularse ao id real do pedido cando o pedido se realiza.
- Os pagamentos con tarxeta de InSite no checkout de bloques (Blocks) fallaban: o cliente vía un mensaxe enganoso "comproba que os campos do checkout/tarxeta están cubertos" e o pedido nunca se pagaba (a consola do navegador mostraba un 404 na petición save_order_data). A causa é que o WooCommerce actual xa non crea o pedido ata que o cliente pulsa "Realizar o pedido" -durante a introdución da tarxeta o store do checkout de Blocks devolve id de pedido 0- así que o token de operación de InSite (idOper) e o número de pedido de Redsys preparado non podían persistirse: o fluxo anterior enviáballos a unha ruta REST (save_order_data) que intentaba adxuntalos ao pedido 0 e devolvía "Invalid order" (404), e o número de pedido xerado mapeábase ao pedido 0 (de modo que nin sequera unha notificación posterior podía atopar o pedido). Agora, cando a tarxeta se tokeniza, o token e o número de pedido preparado gárdanse na sesión de WooCommerce mediante admin-ajax (a sesión de WC non está dispoñible en rutas REST personalizadas, razón pola cal o enfoque REST anterior non podía usala), e trasládanse ao pedido real mentres WooCommerce o crea a partir da petición do checkout (woocommerce_store_api_checkout_update_order_from_request), antes de que se execute process_payment, de modo que process_payment_block() atopa _insite_token e _payment_order_number_redsys como no checkout clásico. O transient do número de pedido tamén volve a mapearse ao id real do pedido para que a notificación (IPN) resolva o pedido. Os datos de pegada do navegador (3DS) xa usaban esta mesma ruta de sesión. O checkout clásico/shortcode non se ve afectado.
Desenvolvemento:
- Eliminada a ruidosa saída de depuración console.log dos scripts de frontend de produción (minificados): Apple Pay, Google Pay, capture-order-id e os modais de express-checkout. O script de Apple Pay Express en particular rexistraba en cada cambio do DOM (vigila todo o documento en busca do seu botón), o que inundaba a consola do navegador no checkout de Blocks. Os arquivos minificados agora eliminan console.log/console.warn/console.info/console.debug mantendo console.error; as fontes sen minificar quedan sen cambios para desenvolvemento.
31.0.4
Arreglado:
- As renovacións de subscrición (cun calquera plugin de subscricións) agora respectan o tipo de número de pedido de Redsys configurado e xa non fallan no reintento con "número de pedido repetido" (SIS0051). Corríxense dous problemas.
- O primeiro: o cargo de renovación xeraba o número de pedido de Redsys ignorando o axuste "Tipo de número de pedido" (redsysordertype/subfix); sempre recorría ao esquema aleatorio por defecto en lugar do tipo configurado para a pasarela, a diferenza do pagamento inicial do checkout. Agora pásase a pasarela para que as renovacións respecten o mesmo tipo de número de pedido que o checkout.
- O segundo: o número de pedido conservábase durante toda a vida do pedido, de modo que cando un cargo de renovación era rexeitado e o plugin de subscricións o reintentaba sobre o mesmo pedido de renovación, enviábase exactamente o mesmo DS_MERCHANT_ORDER e Redsys bloqueaba o reintento lexítimo como duplicado. Agora a distinción entre "fluxo" e "reintento" é explícita: un único fluxo de pagamento (o seu par iniciaPeticion/trataPeticion, os procesos concorrentes de renovación e calquera reexecución mediante Action Scheduler dun proceso que morreu a metade do cargo) mantén o mesmo número de pedido para non cruzar Id Opers (SIS0502) e ser idempotente fronte a cargos duplicados; pero unha vez que Redsys confirma un rexeitamento (unha resposta asinada sen código de autorización, é dicir, sen movemento de diñeiro), o número libérase para que o seguinte reintento xere un novo e único respectando o tipo configurado. O reinicio prodúcese SOAMENTE ante un rexeitamento confirmado, nunca ante erros de transporte ou de tempo de espera onde o resultado é descoñecido, de modo que unha reexecución por resposta perdida nunca pode duplicar o cargo.
- Aplícase ás pasarelas de Redirección e InSite e a todos os plugins de subscricións que as utilizan (WooCommerce Subscriptions, Subscriptions for WooCommerce, YITH, WebToffee, SUMO, Advanced Subscriptions; Google Pay e Apple Pay delegan na pasarela de Redirección).
- Como rede de seguridade, cando non hai configurado un tipo de número de pedido válido (vacío ou un valor herdado ou non recoñecido), o xerador recorre SEMPRE ao esquema por defecto "3 díxitos aleatorios + ceros + id do pedido", o único que nunca colisiona nos reintentos. Nota: o tipo "número de pedido simple" non ten compoñente aleatorio, polo que é incompatible por deseño cos reintentos de subscricións e non debería usarse cando hai subscricións activas.
