Lo sviluppo di questa versione è costato 2.800 euro. Il costo accumulato per quest'anno è di 13.350 euro. Il costo accumulato dalla prima versione è di 212.080 euro, ma il costo per te è solo la licenza di 79€.
Nuova versione 31.0.0 del plugin Redsys per WooCommerce di WooCommerce.com.
31.0.0
Nuovo:
- Nuova superficie del protocollo A2A (Agent2Agent). Opzionale e disattivata per impostazione predefinita. Pubblica una Agent Card in /.well-known/agent-card.json e un endpoint JSON-RPC 2.0 in /wp-json/wc-redsys-a2a/v1/rpc con sette competenze: query_payment_status, create_payment, capture_payment, refund_payment, list_payments, tokenize_card e recurrent_charge. L'autenticazione riutilizza il server di autorizzazione OAuth 2.1 + PKCE di UCP con scope a2a:payments:* (e un bearer di sandbox opzionale per test sotto WP_DEBUG).
- Stream di Server-Sent Events riavviabile in /wp-json/wc-redsys-a2a/v1/tasks/{taskId}/stream per aggiornamenti delle attività in tempo reale, con ripresa tramite Last-Event-ID e heartbeat ogni 15s.
- Notifiche push in uscita firmate a una push_url registrata dal cliente. Intestazione X-A2A-Signature: sha256=<hmac> su <timestamp>.<body>, con ripetizioni a 1m/5m/30m/2h (massimo 4), consegnate tramite Action Scheduler.
- Nuova scheda di amministrazione "A2A (Agent2Agent)" all'interno di Redsys Avanzato -> Agentic Commerce, con Stato / Clienti (creare / revocare / ruotare bearers di sandbox) / Limiti e modalità (max_amount, sensitive_threshold e modalità di pagamento esposte) / Conferme (approvare rimborsi o addebiti ricorrenti bloccati in input-required).
- Limiti per competenza: max_amount è un limite massimo rigoroso che fa fallire l'attività con limit_exceeded; sensitive_threshold ferma l'attività in input-required fino a quando un amministratore la conferma. Entrambi senza limite per impostazione predefinita (opzionale).
- Registro di audit solo allegato (append-only) in wp_redsys_a2a_audit_log. I payload non vengono mai memorizzati in chiaro: solo un hash SHA-256 più un riepilogo sanificato di una riga che maschera PAN, token, segreti e la parte locale delle email.
- Memoria auto-riparabile. Le quattro tabelle A2A vengono ricreate su richiesta tramite l'ensure_table() di ogni store, in modo che una tabella eliminata non provochi mai un errore fatale.
- Supporto per agenti di acquisto con IA (ChatGPT, Claude, Gemini, Perplexity e altri). Gli agenti IA ora possono scoprire i tuoi prodotti, creare carrelli, completare pagamenti e ricevere aggiornamenti sugli ordini dal tuo negozio. Sono supportati sia lo standard ACP di OpenAI/Stripe che lo standard aperto UCP (supportato da Google, Shopify e altri), e ciascuno può essere attivato o disattivato in modo indipendente.
- Nuova sottosezione "Agentic Commerce" all'interno delle impostazioni di Redsys Avanzato, con interruttori per funzione (carrelli, sconti, fulfillment, consenso dell'acquirente, registrazione dinamica dei clienti, ecc.) e pulsanti con un clic per testare i flussi di scoperta degli agenti, OAuth e webhook.
- Firma dei webhook con un pulsante "Ruota chiave di firma". Le chiavi ruotate rimangono valide per 7 giorni affinché le integrazioni esistenti continuino a funzionare durante il cambiamento.
- Il modulo dei campi personalizzati di Express (Apple Pay / Google Pay) ora raccoglie anche i campi registrati tramite l'API di Blocks nei checkout classici, in modo che NIF/DNI e campi simili appaiano sempre indipendentemente dal checkout che usi.
- Azione massiva opzionale "Approva preautorizzazione" per l'elenco degli ordini (Redsys Redirezione). Disattivata per impostazione predefinita per sicurezza; attivala nelle impostazioni della gateway solo se hai bisogno di confermare ordini preautorizzati in massa.
Nota:
- Attivare questo supporto NON significa che gli assistenti IA inizieranno a completare acquisti nel tuo negozio dal primo giorno. L'intero flusso di checkout guidato da agenti è ancora in fase di distribuzione, specialmente in Europa, dove i requisiti di SCA/3DS, PSD2 e consenso RGPD fanno sì che la maggior parte degli agenti oggi si fermi alla scoperta dei prodotti o al pre-carrello e restituisca il pagamento finale al cliente. Il tuo negozio è pronto per il giorno in cui ogni agente attiverà il flusso completo nel tuo mercato.
Aggiornato:
- Il modulo dei campi personalizzati di Express ora pre-carica la sua configurazione al caricamento della pagina e avvia Apple Pay in modo sincrono al clic, correggendo i casi in cui iOS Safari abortiva il foglio di pagamento.
- I campi personalizzati di Express nella pagina del prodotto tornano a utilizzare il modulo predefinito. Il modulo online introdotto in 30.4.1 ora è opzionale tramite un filtro.
Corretto:
- [Critico] Le rinnovazioni degli abbonamenti potevano fallire con l'errore Redsys SIS0502 ("Id Oper non corrisponde") in hosting con Redis, Memcached o altre cache di oggetti persistenti. Due worker di rinnovo in parallelo potevano inviare due riferimenti di ordine distinti a Redsys per lo stesso abbonamento, causando il fallimento della rinnovazione e il tentativo di ripetizione molte volte. Il blocco del pagamento duplicato e il riferimento dell'ordine ora vengono memorizzati in modo affidabile indipendentemente dal backend di cache. Colpisce le gateway di Redirezione e InSite di Redsys.
- Le rinnovazioni di abbonamento di InSite non avevano alcuna protezione di concorrenza (il blocco veniva rimosso in caso di errori ma non veniva mai creato). Ora si applica alle rinnovazioni di InSite la stessa protezione utilizzata dalla gateway di redirezione.
- Lo stato interno memorizzato nella cache utilizzato durante il checkout (dati 3DS, identificatore della carta salvata, cache della firma, stato di OAuth, stato temporaneo di IMAP, ecc.) ora viene memorizzato in modo che funzioni correttamente in hosting con cache di oggetti persistenti. Prima, in cache che si comportavano male, questo stato poteva scomparire silenziosamente a metà checkout e causare errori SIS0502.
- I pulsanti Express di Apple Pay e Google Pay (checkout di blocchi e pagina di prodotto) fallivano in iOS Safari con "Devi creare una nuova ApplePaySession da un gestore di gesti utente" quando il modulo dei campi personalizzati di Express era attivato. Il modulo non consuma più il clic dell'utente prima di lanciare Apple Pay.
- L'IRPEF di Autonomi Premium veniva calcolato male nel Pagamento Express (Apple Pay / Google Pay) nella pagina del prodotto quando il cliente sceglieva il tipo di utente nel modulo di Express, perché il salvataggio del modulo competiva con la prima chiamata del server di Apple Pay. Il tipo di utente ora viene inviato insieme a ogni richiesta di Express Pay, in modo che i totali siano sempre corretti.
- Nelle pagine di prodotto con prodotti virtuali, il foglio di Apple Pay mostrava brevemente il totale corretto (subtotale + tasse) e poi tornava al prezzo del prodotto senza tasse. Il callback di invio ora mantiene l'ultimo totale restituito dal server.
- Salvando le impostazioni di Agentic Commerce veniva silenziosamente scartato l'invio "Salva modifiche" di WooCommerce a causa di moduli HTML annidati. La pagina delle impostazioni è stata ristrutturata e tutti i pulsanti di azione unica (testare la scoperta, testare OAuth, azioni webhook, ecc.) ora funzionano correttamente insieme al pulsante principale di Salva.
- I pulsanti Express di Apple Pay e Google Pay nella pagina del prodotto assegnavano la zona di spedizione errata quando la regione del cliente era limitata per provincia. Apple/Google Pay inviano il nome localizzato dello stato (ad es. "Barcellona") in administrativeArea, ma le zone di spedizione di WooCommerce corrispondono per codice di stato (ad es. "B"); la zona paese-per-stato non corrispondeva e il carrello cadeva in una zona più costosa (ad es. "Resto d'Europa"). I nomi degli stati ora vengono normalizzati a codici di stato di WooCommerce prima della ricerca della zona di spedizione e della creazione dell'ordine.
- Il checkout di InSite con Blocchi poteva creare ordini duplicati quando Redsys emetteva lo stesso postMessage di token di pagamento più di una volta (o quando il salvataggio veniva eseguito in modo concorrente). Ora una protezione evita la creazione di ordini duplicati/concurrenti e si riavvia se il modulo di pagamento viene aggiornato dopo un errore.
- Il registratore di debug REST di InSite faceva riferimento all'oggetto sbagliato per leggere il flag di debug, quindi il payload "REST trattaPeticion" poteva essere registrato (o saltato) indipendentemente dall'impostazione di debug della gateway. Ora utilizza il proprio flag di debug della gateway.
31.0.1
Aggiornato:
- Il conto alla rovescia del modulo di Bizum nella pagina di pagamento mostrava 7 minuti. Ora mostra correttamente 5 minuti, e il controllo del tempo lato server che reindirizza al checkout è stato regolato di conseguenza (60 iterazioni * 5 secondi = 5 minuti).
Corretto:
- Bizum nella pagina di pagamento (Bizum InSite) non inviava la descrizione a Redsys. L'addebito reale dal modulo viene effettuato tramite l'API REST (trataPeticionREST), e quella richiesta non includeva il parametro DS_MERCHANT_PRODUCTDESCRIPTION, quindi la "Descrizione di Redsys" configurata (ad esempio "ID Ordine") arrivava vuota al pannello di Redsys. La descrizione ora viene calcolata in base all'impostazione selezionata e inviata nella richiesta REST.
31.0.2
Aggiornato:
- Il filtro redsys_modify_data_to_send ora riceve 'context' => 'add_payment_method' e 'user_id' nell'array di dati per il flusso di "Aggiungi metodo di pagamento", in modo che gli snippet personalizzati e le regole condizionali possano instradare la tokenizzazione al terminale corretto (terminale + SHA256) senza dipendere da un ordine che non esiste in questo flusso.
- Aggiornate tutte le traduzioni.
Corretto:
- Aggiungere una carta da Il mio account ("Aggiungi metodo di pagamento") in negozi multi-valuta poteva essere rifiutato da Redsys con un errore di valuta. La richiesta veniva inviata con la valuta della sessione del cliente (ad esempio ARS, 32) ma con il terminale predefinito, che è configurato per un'altra valuta (ad esempio EUR, 978). La tokenizzazione della carta è un'operazione di importo zero senza un ordine dietro, quindi se nessun filtro o regola condizionale instrada la richiesta a un altro terminale, ora viene inviata la valuta base del negozio, che corrisponde sempre alla configurazione del terminale predefinito.
- Aggiungere una carta da Il mio account (o tramite il link dell'email di profilo) registrava sempre la carta in Redsys come one-click (DS_MERCHANT_COF_TYPE 'C'), anche quando il cliente selezionava l'opzione di abbonamenti. Il tipo di token veniva letto dalla chiave interna sbagliata, quindi non veniva mai inviato 'R'. Il token veniva memorizzato correttamente come R in WooCommerce, ma l'accordo COF veniva creato come C in Redsys, il che poteva causare il rifiuto successivo delle rinnovazioni di abbonamento (MIT) effettuate con quei token da parte di alcuni emittenti. Le carte aggiunte con l'opzione di abbonamenti ora inviano correttamente DS_MERCHANT_COF_TYPE 'R'. I token creati mentre l'errore era presente non possono essere riclassificati; se una rinnovazione viene rifiutata, chiedi al cliente di aggiungere nuovamente la carta.
- I pagamenti effettuati con una carta salvata (token R) e le rinnovazioni di abbonamento non rispettavano le impostazioni di preautorizzazione. Con "Preautorizza tutti gli ordini" attivato (o un prodotto contrassegnato per preautorizzazione), l'addebito veniva eseguito come una vendita normale (tipo 0) ma l'ordine veniva comunque contrassegnato come "Preautorizzato", in modo che la conferma della preautorizzazione in seguito fallisse in Redsys con SIS0059 ("Nessuna operazione su cui effettuare la conferma"). Entrambi i flussi ora inviano una preautorizzazione reale di tipo 1 che può essere confermata in seguito, e un ordine viene contrassegnato come "Preautorizzato" solo quando è stata eseguita una preautorizzazione reale. Questo abilita anche le rinnovazioni di abbonamento preautorizzate (ad esempio, prodotti venduti al peso, dove ogni rinnovazione viene regolata prima dell'addebito finale).
Sicurezza:
- La chiave segreta SHA-256 del commercio non viene più scritta in chiaro nei registri di debug di WooCommerce. Tutti gli ingressi di debug ora mascherano la chiave, mostrando solo i suoi ultimi 4 caratteri, tramite il nuovo helper WCRed()->mask_secret(). Applicato in tutte le gateway (Redirezione, InSite, Bizum, Google Pay, Apple Pay, PayGold, Domiciliazione bancaria e le classi di supporto di Blocks).
- Le firme delle notifiche (IPN) di Redsys ora vengono verificate con hash_equals() (confronto a tempo costante) in tutti i gestori di notifica, unificandoli con la verifica già utilizzata da InSite e dal client REST. Indurimento contro attacchi di temporizzazione (timing attacks).
- Il gestore AJAX di cancellazione di un singolo token nella schermata di gestione dei token ora richiede la capacità manage_woocommerce oltre al nonce, allineandolo al gestore di cancellazione massiva.
