El desenvolupament d'aquesta versió ha costat 2.800 euros. El cost acumulat per a aquest any és de 13.350 euros. El cost acumulat des de la primera versió és de 212.080 euros, però el cost per a tu és només la llicència de 79€.
Nova versió 31.0.0 del plugin Redsys per WooCommerce de WooCommerce.com.
31.0.0
Nou:
- Nova superfície del protocol A2A (Agent2Agent). Opcional i desactivada per defecte. Publica una Agent Card en /.well-known/agent-card.json i un endpoint JSON-RPC 2.0 en /wp-json/wc-redsys-a2a/v1/rpc amb set habilitats: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card i recurrent_charge. L'autenticació reutilitza el servidor d'autorització OAuth 2.1 + PKCE de UCP amb scopes a2a:payments:* (i un bearer de sandbox opcional per a proves sota WP_DEBUG).
- Stream de Server-Sent Events reanudable en /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream per a actualitzacions de tasques en viu, amb reanudació mitjançant Last-Event-ID i latits (heartbeats) cada 15s.
- Notificacions push sortints signades a una push_url registrada pel client. Capçalera X-A2A-Signature: sha256=<hmac> sobre <timestamp>.<body>, amb reintents a 1m/5m/30m/2h (màxim 4), entregades mitjançant Action Scheduler.
- Nova pestanya d'administració "A2A (Agent2Agent)" dins de Redsys Avançat -> Agentic Commerce, amb Estat / Clients (crear / revocar / rotar bearers de sandbox) / Límits i modes (max_amount, sensitive_threshold i modes de pagament exposats) / Confirmacions (aprovar reemborsaments o càrrecs recurrents detinguts en input-required).
- Topes per habilitat: max_amount és un límit màxim estricte que falla la tasca amb limit_exceeded; sensitive_threshold atura la tasca en input-required fins que un administrador la confirma. Ambdós sense límit per defecte (opcional).
- Registre d'auditoria de només annexat (append-only) en wp_redsys_a2a_audit_log. Mai s'emmagatzemen els payloads en brut: només un hash SHA-256 més un resum sanejat d'una línia que emmascara PAN, tokens, secrets i la part local dels correus electrònics.
- Emmagatzematge auto-reparable. Les quatre taules A2A es recreen sota demanda mitjançant l'ensure_table() de cada store, de manera que una taula eliminada mai provoqui un error fatal.
- Suport per agents de compra amb IA (ChatGPT, Claude, Gemini, Perplexity i altres). Els agents d'IA ara poden descobrir els teus productes, muntar carros, completar pagaments i rebre actualitzacions de comandes des de la teva botiga. Es suporten tant l'estàndard ACP d'OpenAI/Stripe com l'estàndard obert UCP (respaldat per Google, Shopify i altres), i cadascun pot activar-se o desactivar-se de manera independent.
- Nova subsecció "Agentic Commerce" dins dels ajustos de Redsys Avançat, amb interruptors per funció (carros, descomptes, fulfillment, consentiment del comprador, registre dinàmic de clients, etc.) i botons d'un clic per provar els fluxos de descobriment d'agents, OAuth i webhook.
- Signatura de webhooks amb un botó "Rotar clau de signatura". Les claus rotades segueixen sent vàlides durant 7 dies perquè les integracions existents segueixin funcionant durant el canvi.
- El modal de camps personalitzats d'Express (Apple Pay / Google Pay) ara també recull els camps registrats mitjançant l'API de Blocks en checkouts clàssics, de manera que NIF/DNI i camps similars sempre apareixen independentment del checkout que facis servir.
- Acció massiva opcional "Aprovar preautorizació" per a la llista de comandes (Redsys Redirecció). Desactivada per defecte per seguretat; activa-la en els ajustos de la passarel·la només si necessites confirmar comandes preautoritzades en massa.
Nota:
- Activar aquest suport NO significa que els assistents d'IA vagin a començar a completar compres a la teva botiga des del primer dia. El flux complet de checkout dirigit per agents encara s'està desplegant, especialment a Europa, on els requisits de SCA/3DS, PSD2 i consentiment RGPD fan que la majoria d'agents avui s'aturin en el descobriment de productes o el pre-carro i retornin el pagament final al client. La teva botiga està preparada per al dia en què cada agent activi el flux complet al teu mercat.
Actualitzat:
- El modal de camps personalitzats d'Express ara precarga la seva configuració al carregar la pàgina i inicia Apple Pay de manera síncrona al fer clic, corregint els casos en què iOS Safari abortava la fulla de pagament.
- Els camps personalitzats d'Express a la pàgina de producte tornen a utilitzar el modal per defecte. El formulari en línia introduït en 30.4.1 ara és opcional mitjançant un filtre.
Arreglat:
- [Crític] Les renovacions de subscripcions podien fallar amb l'error Redsys SIS0502 ("Id Oper no coincideix") en hostings amb Redis, Memcached o altres cachés d'objectes persistents. Dos workers de renovació en paral·lel podien enviar dues referències de comanda distintes a Redsys per a la mateixa subscripció, provocant que la renovació fallés i es reintentés moltes vegades. El bloqueig de pagament duplicat i la referència de comanda ara s'emmagatzemen de manera fiable independentment del backend de caché. Afecta a les passarel·les de Redirecció i InSite de Redsys.
- Les renovacions de subscripció d'InSite no tenien cap protecció de concurrència (el bloqueig s'eliminava en els errors però mai es creava). Ara s'aplica a les renovacions d'InSite la mateixa protecció que usa la passarel·la de redirecció.
- L'estat intern emmagatzemat en caché utilitzat durant el checkout (dades 3DS, identificador de targeta guardada, caché de signatura, estat d'OAuth, estat temporal d'IMAP, etc.) ara s'emmagatzema de manera que funciona correctament en hostings amb cachés d'objectes persistents. Abans, en cachés que es comportaven malament, aquest estat podia desaparèixer silenciosament a mitja checkout i provocar errors SIS0502.
- Els botons Express d'Apple Pay i Google Pay (checkout de blocs i pàgina de producte) fallaven en iOS Safari amb "Must create a new ApplePaySession from a user gesture handler" quan el modal de camps personalitzats d'Express estava activat. El modal ja no consumeix el clic de l'usuari abans de llançar Apple Pay.
- L'IRPF d'Autònoms Premium es calculava malament en el Pagament Express (Apple Pay / Google Pay) a la pàgina de producte quan el client triava el tipus d'usuari en el modal d'Express, perquè el guardat del modal competia amb la primera crida del servidor d'Apple Pay. El tipus d'usuari ara s'envia juntament amb cada petició d'Express Pay, de manera que els totals són sempre correctes.
- En pàgines de producte amb productes virtuals, la fulla d'Apple Pay mostrava breument el total correcte (subtotal + impostos) i després revertia al preu del producte sense impostos. El callback d'enviament ara manté l'últim total retornat pel servidor.
- En guardar els ajustos d'Agentic Commerce es descartava silenciosament l'enviament "Guardar canvis" de WooCommerce per culpa de formularis HTML anidats. La pàgina d'ajustos s'ha reestructurat i tots els botons d'acció única (provar descobriment, provar OAuth, accions de webhook, etc.) ara funcionen correctament juntament amb el botó principal de Guardar.
- Els botons Express d'Apple Pay i Google Pay a la pàgina de producte assignaven la zona d'enviament incorrecta quan la regió del client estava restringida per província. Apple/Google Pay envien el nom localitzat de l'estat (p. ex. "Barcelona") en administrativeArea, però les zones d'enviament de WooCommerce coincideixen per codi d'estat (p. ex. "B"); la zona país-per-estat no coincidia i el carro caia en una zona més cara (p. ex. "Resta d'Europa"). Els noms d'estat ara es normalitzen a codis d'estat de WooCommerce abans de la cerca de zona d'enviament i la creació de la comanda.
- El checkout d'InSite amb Blocs podia crear comandes duplicades quan Redsys emetia el mateix postMessage de token de pagament més d'una vegada (o quan el guardat s'executava de manera concurrent). Ara una protecció evita la creació de comandes duplicades/concurrentes i es reinicia si el formulari de pagament es refresca després d'un error.
- El registre de depuració REST d'InSite feia referència a l'objecte equivocat per llegir el flag de depuració, per la qual cosa el payload "REST tractaPeticion" podia registrar-se (o saltar-se) independentment de l'ajust de depuració de la passarel·la. Ara usa el propi flag de depuració de la passarel·la.
31.0.1
Actualitzat:
- El compte enrere del modal de Bizum a la pàgina de pagament mostrava 7 minuts. Ara mostra correctament 5 minuts, i el control de temps del costat del servidor que redirigeix al checkout s'ha ajustat en conseqüència (60 iteracions * 5 segons = 5 minuts).
Arreglat:
- Bizum a la pàgina de pagament (Bizum InSite) no enviava la descripció a Redsys. El càrrec real des del modal es realitza a través de l'API REST (trataPeticionREST), i aquesta petició no incloïa el paràmetre DS_MERCHANT_PRODUCTDESCRIPTION, per la qual cosa la "Descripció de Redsys" configurada (per exemple "Order ID") arribava buida al panell de Redsys. La descripció ara es calcula a partir de l'ajust seleccionat i s'envia en la petició REST.
31.0.2
Actualitzat:
- El filtre redsys_modify_data_to_send ara rep 'context' => 'add_payment_method' i 'user_id' en l'array de dades per al flux d'"Afegir mètode de pagament", de manera que els snippets personalitzats i les regles condicionals poden enrutar la tokenització al terminal correcte (terminal + SHA256) sense dependre d'una comanda que no existeix en aquest flux.
- Actualitzades totes les traduccions.
Arreglat:
- Afegir una targeta des de La meva compte ("Afegir mètode de pagament") en botigues multidivisa podia ser rebutjat per Redsys amb un error de divisa. La petició s'enviava amb la divisa de la sessió del client (per exemple ARS, 32) però amb el terminal per defecte, que està configurat per a una altra divisa (per exemple EUR, 978). La tokenització de targeta és una operació d'import zero sense una comanda darrere, així que si cap filtre o regla condicional enruta la petició a un altre terminal, ara s'envia la divisa base de la botiga, que sempre coincideix amb la configuració del terminal per defecte.
- Afegir una targeta des de La meva compte (o mitjançant l'enllaç de l'email de perfil) registrava sempre la targeta a Redsys com one-click (DS_MERCHANT_COF_TYPE 'C'), fins i tot quan el client seleccionava l'opció de subscripcions. El tipus de token es llegia de la clau interna equivocada, per la qual cosa mai s'enviava 'R'. El token es guardava correctament com R a WooCommerce, però l'acord COF es creava com C a Redsys, cosa que podia provocar que alguns emissors rebutgessin posteriorment les renovacions de subscripció (MIT) fetes amb aquests tokens. Les targetes afegides amb l'opció de subscripcions ara envien correctament DS_MERCHANT_COF_TYPE 'R'. Els tokens creats mentre l'error estava present no es poden reclasificar; si una renovació és rebutjada, demana al client que torni a afegir la targeta.
- Els pagaments fets amb una targeta guardada (token R) i les renovacions de subscripció no respectaven els ajustos de preautorizació. Amb "Preautoritzar totes les comandes" activat (o un producte marcat per a preautorizació), el càrrec s'executava com una venda normal (tipus 0) però la comanda es marcava igualment com "Preautoritzada", de manera que confirmar la preautorizació més tard fallava a Redsys amb SIS0059 ("No existeix operació sobre la qual realitzar la confirmació"). Ambdós fluxos ara envien una preautorizació real de tipus 1 que es pot confirmar després, i una comanda només es marca com "Preautoritzada" quan s'ha executat una preautorizació real. Això també habilita les renovacions de subscripció preautoritzades (per exemple, productes venuts al pes, on cada renovació s'ajusta abans del càrrec final).
Seguretat:
- La clau secreta SHA-256 del comerç ja no s'escriu en text pla als registres de depuració de WooCommerce. Totes les entrades de depuració ara emmascaren la clau, mostrant només els seus últims 4 caràcters, mitjançant el nou helper WCRed()->mask_secret(). Aplicat a totes les passarel·les (Redirecció, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliació bancària i les classes de suport de Blocks).
- Les signatures de les notificacions (IPN) de Redsys ara es verifiquen amb hash_equals() (comparació en temps constant) en tots els gestors de notificació, unificant-los amb la verificació que ja feien InSite i el client REST. Enduriment davant d'atacs de temporització (timing attacks).
- El gestor AJAX de borrat d'un únic token a la pantalla de gestió de tokens ara requereix la capacitat manage_woocommerce a més del nonce, igualant-lo al gestor de borrat massiu.
