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 a 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 aturats 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 botiga, de manera que una taula eliminada mai provoqui un error fatal.
- Suport per a agents de compra amb IA (ChatGPT, Claude, Gemini, Perplexity i altres). Els agents d'IA ara poden descobrir els teus productes, muntar carrets, 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 (respatllat 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ó (carrets, 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 preautorizades 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-carret 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 forma 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 usar 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é usat 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 carret 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
Seguretat:
- La clau secreta SHA-256 del comerç ja no es escriu en text pla en els 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 en 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 notificacions, 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 supressió 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 supressió massiva.
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 de "Afegir mètode de pagament", de manera que els snippets personalitzats i les regles condicionals puguin 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 El meu compte ("Afegir mètode de pagament") a botigues multidivisa podia ser rebutjat per Redsys amb un error de moneda. La petició s'enviava amb la moneda de la sessió del client (per exemple ARS, 32) però amb el terminal per defecte, que està configurat per a una altra moneda (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 moneda base de la botiga, coincidint sempre amb la configuració del terminal per defecte.
- Afegir una targeta des de El meu compte (o mitjançant l'enllaç de correu electrònic del 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 posteriors 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 realitzats 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 "Preautorizat", 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 "Preautorizat" quan s'ha executat una preautorizació real. Això també habilita les renovacions de subscripció preautorizades (per exemple béns venuts al pes, on cada renovació s'ajusta abans del càrrec final).
31.0.3
Nou:
- Secció "Apps i Plugins" dins de Redsys Avançat -> Ajustos Avançats de Redsys. Una pàgina d'aterratge de només lectura que mostra l'app nativa de gestió per macOS (amb descàrrega, requisits i plataformes "pròximament") i llista la resta de plugins gratuïts i premium, webs i portals, skills de Claude i perfils de desenvolupador de José Conti, cadascun agrupat per tipus amb un enllaç. Cada llista és 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).
Seguretat:
- Eliminat un bypass de verificació de firma de notificació que podia permetre que una petició anònima marqués una comanda com pagada quan el secret SHA-256 es deixava buit o mal configurat. El listener de IPN de Redsys (endpoint públic wc-api) tenia un fallback heredat que, quan no hi havia secret configurat, acceptava una notificació únicament perquè el Ds_MerchantCode enviat coincidís amb el FUC del comerç, un valor públic i no secret que un atacant pot subministrar. Aquesta acceptació basada només en el codi de comerç s'ha eliminat de totes les passarel·les (Redirecció, Bizum, Bizum InSite, Google Pay checkout i redirecció, Apple Pay, PayGold, Domiciliació Bancària, MasterPass i Transferència Bancària): quan no hi ha secret per verificar el HMAC, la petició ara falla de forma segura (rebuig HTTP) en lloc de ser confiada. A més, la rutina de verificació compartida (WooRedsysAPI::verify_signature_notif) ara retorna false sempre que la clau del comerç o la firma rebuda estiguin buides, de manera que ni check_ipn_request_is_valid() ni successful_request() puguin completar un pagament amb un HMAC de clau buida calculable per l'atacant. InSite ja requerien una firma vàlida (sense fallback per codi de comerç) i Inespay no es veu afectat (relaciona les comandes pel seu propi id de payin). Les botigues reals no es veuen afectades, perquè tenir un secret configurat és obligatori per poder cobrar.
Arreglat:
- Les notificacions de Bizum es rebutjaven amb un error de verificació de firma, deixant la comanda sense pagar encara que el pagament s'hagués autoritzat a Redsys. La clau del comerç i el número de comanda eren correctes (la firma de la petició coincidía perfectament), però la firma de la notificació és un HMAC calculat sobre la cadena Ds_MerchantParameters exactament com es rep, i les notificacions de Bizum arriben amb el farciment (padding) final "=" de base64 eliminat, mentre que Redsys signa sobre el valor amb el farciment canònic, així que l'HMAC calculat localment mai coincidía. La rutina de notificació compartida (create_merchant_signature_notif en WooRedsysAPI) ara torna a farcir el payload a un múltiple de quatre abans de hashear, i la verificació (verify_signature_notif) ara compara ambdues firmes ignorant el farciment final "=" (que no aporta entropia, així que la comparació continua sent en temps constant). Els payloads de targeta ja són canònics i es deixen intactes, de manera que la resta de passarel·les continuen funcionant sense canvis. Aquesta rutina la comparteixen tots els gestors de notificació (Redirecció, Bizum, InSite, PayGold, Google Pay, Apple Pay, Domiciliació Bancària, Transferència Bancària i els clients REST/A2A).
- Les notificacions de targeta i wallet podien rebutjar-se amb un "signature mismatch", de manera que el client que tornava a la pàgina de gràcies (i l'IPN servidor a servidor) no aconseguia marcar la comanda com pagada fins que un reintento posterior d'IPN tenia èxit per casualitat; els reemborsaments i els enllaços de PayGold pagats més tard podien quedar sense confirmar. Hi ha dos problemes de farciment implicats: a més del farciment del payload de Bizum anterior, Redsys entrega la firma de la notificació (Ds_Signature) en base64 URL-safe amb el "=" final eliminat, mentre que la firma calculada localment ho manté, així que una comparació estricta també falla per als pagaments de targeta normals. La comparació tolerant al farciment viu a verify_signature_notif(), però la majoria dels gestors continuaven comparant la firma en línia amb un hash_equals()/!== estricte que reintroduïa la sensibilitat. Ara tots els gestors deleguen a verify_signature_notif(), de manera que l'arreglament arriba a tots: Redirecció de targeta (ambdós validadors d'IPN i les comprovacions de resposta REST-SOAP de captura/reemborsament), Bizum, Bizum InSite, InSite (IPN, successful_request i els dos validadors de resposta REST), PayGold, Google Pay (checkout i redirecció), Apple Pay, Domiciliació Bancària, Transferència Bancària, MasterPass i el client REST d'InSite. Regressió introduïda quan es van unificar les comprovacions de firma per passarel·la a verify_signature_notif() amb una comparació estricta i sensible al farciment.
- Les notificacions de Bizum a botigues multidivisa / de doble terminal (les que enrouten cada comanda a un terminal diferent mitjançant el filtre bizum_modify_data_to_send o una regla condicional) ara resolen la clau de firma real per comanda abans de verificar la firma (la clau dels ajustos ajustada pel client, el transient guardat quan es va generar el formulari de pagament, o el meta de comanda _redsys_secretsha256), i una notificació no verificable es rebutja amb HTTP 400.
- Els pagaments amb targeta d'InSite que requerien un challenge 3DS mostraven una pantalla de verificació en blanc a Safari (iPhone/Mac), de manera que el client no podia introduir el codi SMS/PIN i el pagament fallava (el mateix flux funcionava a Chrome). El challenge en si ja era una navegació de pàgina completa i de nivell superior, però abans d'ell el plugin redirigia el navegador a la URL del 3DS Method de l'emissor (threeDSMethodURL) per agafar la petjada del navegador, i la Prevenció de Rastrejament Intel·ligent (ITP) de Safari bloqueja les galetes de tercers que aquest pas necessita, deixant una pàgina ACS en blanc (símptoma: la URL de l'ACS arriba amb ";jsessionidpa=" perquè les galetes no flueixen). El pas del 3DS Method al navegador és opcional, així que el plugin ja no redirigeix el navegador a threeDSMethodURL: sempre envia threeDSCompInd = 'N' i continua directament a l'autenticació. Aplicat a tots els fluxos d'InSite -targeta nova i targeta guardada (one-click/token), tant en checkout de blocs com clàssic (shortcode)- i als fluxos REST/token de la passarel·la de Redirecció (pay_with_token_c, receipt_page i successful_request), ja que la mateixa pantalla en blanc podia aparèixer al cobrar un token de targeta guardada.
- Quan un pagament amb targeta d'InSite fallava perquè faltava un camp obligatori del checkout o les seves dades no coincidien (per exemple, un cognom buit produïa un "signature mismatch"), el missatge d'error culpava a la targeta ("…torna a introduir les dades de la teva targeta"), així que els clients pensaven que la seva targeta havia estat rebutjada i abandonaven la comanda. El missatge ara és neutre i apunta primer als camps del checkout: demana al client que comprovi que tots els camps del checkout (nom, cognoms, adreça, etc.) i les dades de la targeta estan omplerts correctament abans de tornar-ho a intentar. Aplicat als checkouts clàssic i de blocs (Blocks).
- Els reembossaments i pagaments ajornats de comandes amb IDs de comanda grans (el "bug dels mil milions" ja corregit per al checkout instantani) es registraven contra la comanda equivocada, o no es registraven en absolut. La notificació (IPN) de Redsys recupera l'ID de comanda de WooCommerce a partir del número de comanda mitjançant clean_order_number(), que primer busca un transient guardat quan es va generar el número de comanda i, en el seu defecte, recorria a una heurística substr/ltrim que descarta els dígits d'ordre alt dels IDs amb 10 o més dígits. Aquest transient té un TTL d'1h, així que el fallback s'activava sempre que la notificació arriba més d'una hora després de generar-se el número de comanda: cada reembossament (processat dies o setmanes després) i els enllaços de pagament de PayGold (pagats pel client més tard), entre d'altres. Tres canvis ho fan robust per a tots els mètodes de pagament: (1) la rutina de reembossament compartida (ask_for_refund) ara torna a guardar el mapeig número de comanda -> ID real de comanda en el moment del reembossament amb un TTL de 24h; (2) clean_order_number(), quan el transient ja no existeix, ara busca la comanda de forma inversa pel meta persistit del número de comanda (_payment_order_number_redsys / _redsys_transaction_id2) abans d'utilitzar mai la heurística amb pèrdua; i (3) PayGold ara persisteix el número de comanda en el meta quan es crea l'enllaç, de manera que un enllaç pagat molt després continua resolent-se a la comanda exacta. S'aplica a totes les passarel·les (Redirecció, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold i Domiciliació Bancària). Inespay no es veu afectat (relaciona les comandes pel seu propi id de payin).
- Els pagaments amb targeta d'InSite al checkout de blocs (Blocks) fallaven la PRIMERA vegada amb "msg18" (el client veia "comprova que els camps del checkout/targeta estan omplerts") i només funcionaven en el segon intent. El SDK d'InSite de Redsys requereix que la pàgina enviï un missatge "domain" al iframe de la targeta perquè Redsys pugui validar el comerç; el SDK ho fa mitjançant un onload="setMerchantDomain(0)" en línia a l'iframe. El script de blocs sobrescrivia aquest manejador amb el seu propi iframe.onload (utilitzat per dimensionar l'iframe) just després del primer renderitzat, així que el domini del comerç mai s'enviava i Redsys rebutjava la tokenització amb msg18 ("validació incorrecta per part del comerç"). En el refresc automàtic del formulari la sobrescriptura no s'executava, així que el segon intent funcionava. El plugin ara crida a setMerchantDomain explícitament després de construir el formulari (com fa la pròpia integració del botó de pagament del SDK) i ja no sobrescriu l'onload de l'iframe, de manera que el primer intent funciona.
- InSite checkout de blocs: s'ha fet més robust el maneig del postMessage de Redsys i s'han afegit diagnòstics d'extrem a extrem. El manejador ara accepta missatges de qualsevol subdomini de Redsys (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) en lloc d'exigir una coincidència exacta de host/port (Redsys publica des de més d'un host), elimina qualsevol listener deixat per un renderitzat anterior perquè un únic token no pugui disparar múltiples enviaments, i neteja els camps de token/error després de llegir-los perquè un re-dispar que quedi obsolet no pugui reenviar-los. Quan el registre de depuració d'InSite està activat, tot el pas de tokenització del costat del client (número de comanda, postMessage de Redsys, token/codi d'error, guardat i place-order) es reflecteix en el log "insite" de WooCommerce, de manera que els fallos del primer intent que mai arriben a PHP puguin diagnosticar-se.
- Els pagaments amb targeta d'InSite al checkout de blocs (Blocks) eren rebutjats per Redsys amb SIS0574 ("operació d'autenticació EMV3DS rebutjada, browserUserAgent no indicat"): la petjada 3DS del navegador (user agent, mida de pantalla, idioma, profunditat de color, zona horària) mai arribava a la comanda, perquè el hook que normalment la copia a la comanda (woocommerce_checkout_create_order) no s'executa al checkout de la Store API (Blocks). El formulari d'InSite de Blocks ara recull la petjada i l'envia juntament amb el token d'operació, i s'escriu a la comanda real (juntament amb el token) abans que s'executi process_payment, de manera que l'autenticació EMV3DS té les dades que necessita.
- Els pagaments amb targeta d'InSite al checkout de blocs (Blocks) eren rebutjats amb un "codi d'error sense token" (mostrat al client com "comprova que els camps del checkout/targeta estan omplerts"), de manera que la targeta ni tan sols podia tokenitzar-se després d'uns pocs intents. Com que la comanda encara no existeix al checkout de Blocks (id de comanda 0), el número de comanda de Redsys preparat es generava a partir de l'id 0, cosa que produïa un valor gairebé constant -només ~999 números possibles, tots acabats en nou zeros- i Redsys rebutja un número de comanda reutilitzat ("comanda repetida", SIS0051). Quan l'id de la comanda esborrany encara no està disponible, el formulari d'InSite de Blocks ara utilitza el mateix número de comanda temporal que el checkout shortcode d'InSite (create_checkout_insite_number: sempre comença per 1, globalment únic mitjançant un contador incremental compartit), així que mai col·lisiona; quan l'id de la comanda esborrany està disponible, el número de Redsys es construeix a partir d'ell. El número es torna a vincular a l'id real de la comanda quan la comanda es realitza.
- Els pagaments amb targeta d'InSite al checkout de blocs (Blocks) fallaven: el client veia un missatge enganyós "comprova que els camps del checkout/targeta estan omplerts" i la comanda mai es pagava (la consola del navegador mostrava un 404 en la petició save_order_data). La causa és que el WooCommerce actual ja no crea la comanda fins que el client prem "Realitzar la comanda" -durant la introducció de la targeta el store del checkout de Blocks retorna id de comanda 0- així que el token d'operació d'InSite (idOper) i el número de comanda de Redsys preparat no podien persistir-se: el flux anterior els enviava a una ruta REST (save_order_data) que intentava adjuntar-los a la comanda 0 i tornava "Invalid order" (404), i el número de comanda generat es mapejava a la comanda 0 (de manera que ni tan sols una notificació posterior podia trobar la comanda). Ara, quan la targeta es tokenitza, el token i el número de comanda preparat es guarden a la sessió de WooCommerce mitjançant admin-ajax (la sessió de WC no està disponible en rutes REST personalitzades, raó per la qual l'enfocament REST anterior no podia utilitzar-la), i es traslladen a la comanda real mentre WooCommerce la crea a partir de la petició del checkout (woocommerce_store_api_checkout_update_order_from_request), abans que s'executi process_payment, de manera que process_payment_block() troba _insite_token i _payment_order_number_redsys com al checkout clàssic. El transient del número de comanda també es torna a mapear a l'id real de la comanda perquè la notificació (IPN) resolgui la comanda. Les dades de petjada del navegador (3DS) ja utilitzaven aquesta mateixa ruta de sessió. El checkout clàssic/shortcode no es veu afectat.
Desenvolupament:
- Eliminada la ruidosa sortida de depuració console.log dels scripts de frontend de producció (minificats): Apple Pay, Google Pay, capture-order-id i els modals d'express-checkout. El script d'Apple Pay Express en particular registrava en cada canvi del DOM (vigila tot el document en cerca del seu botó), cosa que inundava la consola del navegador al checkout de Blocks. Els fitxers minificats ara eliminen console.log/console.warn/console.info/console.debug mantenint console.error; les fonts sense minificar queden sense canvis per a desenvolupament.
