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 skill: 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 skill: 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. Non vengono mai memorizzati i payload grezzi: solo un hash SHA-256 più un riepilogo sanificato di una riga che maschera PAN, token, segreti e la parte locale delle email.
- Archiviazione 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 possono ora 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 modal 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 utilizzi.
- 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 GDPR 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 modal 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 modal 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 coincide") in hosting con Redis, Memcached o altre cache di oggetti persistenti. Due worker di rinnovo in parallelo potevano inviare due riferimenti d'ordine distinti a Redsys per lo stesso abbonamento, causando il fallimento della rinnovazione e ripetuti tentativi. Il blocco del pagamento duplicato e il riferimento d'ordine ora vengono memorizzati in modo affidabile indipendentemente dal backend di cache. Colpisce le gateway di Redirezione e InSite di Redsys.
- Le rinnovazioni degli abbonamenti 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à del checkout e causare errori SIS0502.
- I pulsanti Express di Apple Pay e Google Pay (checkout di blocchi e pagina del prodotto) fallivano in iOS Safari con "Devi creare una nuova ApplePaySession da un gestore di gesti utente" quando il modal dei campi personalizzati di Express era attivato. Il modal non consuma più il clic dell'utente prima di avviare 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 modal di Express, perché il salvataggio del modal 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 (testa scoperta, prova 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 finiva in una zona più costosa (ad es. "Resto d'Europa"). I nomi degli stati ora vengono normalizzati ai 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 registro 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 modal 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 modal avviene tramite l'API REST (trattaPeticionREST), 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
Sicurezza:
- La chiave segreta SHA-256 del commercio non viene più scritta in chiaro nei registri di debug di WooCommerce. Tutte le voci di debug ora mascherano la chiave, mostrando solo gli ultimi 4 caratteri, tramite il nuovo helper WCRed()->mask_secret(). Applicato in tutti i gateway (Reindirizzamento, 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 in tempo costante) in tutti i gestori di notifiche, unificandole con la verifica già utilizzata da InSite e dal client REST. Indurimento contro attacchi di temporizzazione (timing attacks).
- Il gestore AJAX per la cancellazione di un singolo token nella schermata di gestione dei token ora richiede la capacità manage_woocommerce oltre al nonce, allineandosi al gestore di cancellazione massiva.
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, corrispondendo sempre alla configurazione del terminale predefinito.
- Aggiungere una carta da Il Mio Account (o tramite il link email del 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 salvato correttamente come R in WooCommerce, ma l'accordo COF veniva creato come C in Redsys, il che poteva provocare che alcuni emittenti rifiutassero successivi rinnovi di abbonamento (MIT) effettuati con quei token. 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 un rinnovo viene rifiutato, chiedi al cliente di riaggiungere la carta.
- I pagamenti effettuati con una carta salvata (token R) e i rinnovi 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 confermare la 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 i rinnovi di abbonamento preautorizzati (ad esempio beni venduti al peso, dove ogni rinnovo viene regolato prima dell'addebito finale).
31.0.3
Nuovo:
- Sezione "App e Plugin" all'interno di Redsys Avanzato -> Impostazioni Avanzate di Redsys. Una pagina di atterraggio di sola lettura che mostra l'app nativa di gestione per macOS (con download, requisiti e piattaforme "prossimamente") e elenca il resto dei plugin gratuiti e premium, siti web e portali, skills di Claude e profili di sviluppatore di José Conti, ognuno raggruppato per tipo con un link. Ogni elenco è filtrabile (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).
Sicurezza:
- Rimosso un bypass di verifica della firma di notifica che poteva consentire a una richiesta anonima di contrassegnare un ordine come pagato quando la chiave SHA-256 veniva lasciata vuota o mal configurata. Il listener IPN di Redsys (endpoint pubblico wc-api) aveva un fallback ereditato che, quando non c'era una chiave configurata, accettava una notifica solo perché il Ds_MerchantCode inviato corrispondeva al FUC del commercio, un valore pubblico e non segreto che un attaccante può fornire. Quella accettazione basata solo sul codice commerciale è stata rimossa da tutti i gateway (Reindirizzamento, Bizum, Bizum InSite, Google Pay checkout e reindirizzamento, Apple Pay, PayGold, Domiciliazione Bancaria, MasterPass e Trasferimento Bancario): quando non c'è una chiave per verificare l'HMAC, la richiesta ora fallisce in modo sicuro (rifiuto HTTP) invece di essere considerata affidabile. Inoltre, la routine di verifica condivisa (WooRedsysAPI::verify_signature_notif) ora restituisce false ogni volta che la chiave del commercio o la firma ricevuta sono vuote, in modo che né check_ipn_request_is_valid() né successful_request() possano completare un pagamento con un HMAC di chiave vuota calcolabile dall'attaccante. InSite richiedeva già una firma valida (senza fallback per codice commerciale) e Inespay non è influenzato (collega gli ordini tramite il proprio id di payin). I negozi reali non sono influenzati, poiché avere una chiave configurata è obbligatorio per poter incassare.
Corretto:
- Le notifiche di Bizum venivano rifiutate con un errore di verifica della firma, lasciando l'ordine non pagato anche se il pagamento era stato autorizzato in Redsys. La chiave del commercio e il numero d'ordine erano corretti (la firma della richiesta corrispondeva perfettamente), ma la firma della notifica è un HMAC calcolato sulla stringa Ds_MerchantParameters esattamente come viene ricevuta, e le notifiche di Bizum arrivano con il padding finale "=" di base64 rimosso, mentre Redsys firma sul valore con il padding canonico, quindi l'HMAC calcolato localmente non corrispondeva mai. La routine di notifica condivisa (create_merchant_signature_notif in WooRedsysAPI) ora ripristina il payload a un multiplo di quattro prima di hasharlo, e la verifica (verify_signature_notif) ora confronta entrambe le firme ignorando il padding finale "=" (che non apporta entropia, quindi il confronto rimane in tempo costante). I payload delle carte sono già canonici e rimangono intatti, quindi il resto dei gateway continua a funzionare senza modifiche. Questa routine è condivisa da tutti i gestori di notifica (Reindirizzamento, Bizum, InSite, PayGold, Google Pay, Apple Pay, Domiciliazione Bancaria, Trasferimento Bancario e i clienti REST/A2A).
- Le notifiche di carta e wallet potevano essere rifiutate con un "signature mismatch", in modo che il cliente che tornava alla pagina di ringraziamento (e l'IPN server a server) non riuscisse a contrassegnare l'ordine come pagato fino a quando un successivo tentativo di IPN non avesse successo per caso; i rimborsi e i link di PayGold pagati in seguito potevano rimanere non confermati. Ci sono due problemi di padding implicati: oltre al padding del payload di Bizum precedente, Redsys fornisce la firma della notifica (Ds_Signature) in base64 URL-safe con il "=" finale rimosso, mentre la firma calcolata localmente lo mantiene, quindi un confronto rigoroso fallisce anche per i pagamenti di carta normali. Il confronto tollerante al padding vive in verify_signature_notif(), ma la maggior parte dei gestori continuava a confrontare la firma in linea con un hash_equals()/!== rigoroso che reintroduceva la sensibilità. Ora tutti i gestori delegano a verify_signature_notif(), quindi la correzione arriva a tutti: Reindirizzamento di carta (entrambi i validatori di IPN e i controlli di risposta REST-SOAP di cattura/rimborso), Bizum, Bizum InSite, InSite (IPN, successful_request e i due validatori di risposta REST), PayGold, Google Pay (checkout e reindirizzamento), Apple Pay, Domiciliazione Bancaria, Trasferimento Bancario, MasterPass e il cliente REST di InSite. Regressione introdotta quando sono state unificate le verifiche di firma per gateway in verify_signature_notif() con un confronto rigoroso e sensibile al padding.
- Le notifiche di Bizum in negozi multi-valuta / a doppio terminale (quelle che instradano ogni ordine a un terminale diverso tramite il filtro bizum_modify_data_to_send o una regola condizionale) ora risolvono la chiave di firma reale per ordine prima di verificare la firma (la chiave delle impostazioni regolata dal cliente, il transient salvato quando è stato generato il modulo di pagamento, o il meta ordine _redsys_secretsha256), e una notifica non verificabile viene rifiutata con HTTP 400.
- I pagamenti con carta di InSite che richiedevano una sfida 3DS mostravano una schermata di verifica bianca su Safari (iPhone/Mac), impedendo al cliente di inserire il codice SMS/PIN e il pagamento falliva (lo stesso flusso funzionava su Chrome). La sfida stessa era già una navigazione a pagina intera e di livello superiore, ma prima di essa il plugin reindirizzava il browser all'URL del 3DS Method dell'emittente (threeDSMethodURL) per acquisire l'impronta del browser, e la Prevenzione del Tracciamento Intelligente (ITP) di Safari blocca i cookie di terze parti di cui quel passaggio ha bisogno, lasciando una pagina ACS bianca (sintomo: l'URL dell'ACS arriva con ";jsessionidpa=" perché i cookie non fluiscono). Il passaggio del 3DS Method nel browser è facoltativo, quindi il plugin non reindirizza più il browser a threeDSMethodURL: invia sempre threeDSCompInd = 'N' e continua direttamente all'autenticazione. Applicato a tutti i flussi di InSite -carta nuova e carta salvata (one-click/token), sia nel checkout a blocchi che classico (shortcode)- e ai flussi REST/token del gateway di Reindirizzamento (pay_with_token_c, receipt_page e successful_request), poiché la stessa schermata bianca poteva apparire durante il pagamento di un token di carta salvata.
- Quando un pagamento con carta di InSite falliva perché mancava un campo obbligatorio del checkout o i suoi dati non corrispondevano (ad esempio, un cognome vuoto produceva un "signature mismatch"), il messaggio di errore incolpava la carta ("…reinserisci i dati della tua carta"), quindi i clienti pensavano che la loro carta fosse stata rifiutata e abbandonavano l'ordine. Il messaggio ora è neutro e punta prima ai campi del checkout: chiede al cliente di controllare che tutti i campi del checkout (nome, cognomi, indirizzo, ecc.) e i dati della carta siano compilati correttamente prima di riprovare. Applicato ai checkout classico e a blocchi (Blocks).
- I rimborsi e i pagamenti differiti di ordini con ID ordine grandi (il "bug dei miliardi" già corretto per il checkout istantaneo) venivano registrati contro l'ordine sbagliato, o non venivano registrati affatto. La notifica (IPN) di Redsys recupera l'ID ordine di WooCommerce dal numero d'ordine tramite clean_order_number(), che prima cerca un transient salvato quando è stato generato il numero d'ordine e, in mancanza, ricorre a un'euristica substr/ltrim che scarta le cifre di ordine alte degli ID con 10 o più cifre. Quel transient ha un TTL di 1h, quindi il fallback si attivava ogni volta che la notifica arrivava più di un'ora dopo la generazione del numero d'ordine: ogni rimborso (elaborato giorni o settimane dopo) e i link di pagamento di PayGold (pagati dal cliente in seguito), tra gli altri. Tre modifiche lo rendono robusto per tutti i metodi di pagamento: (1) la routine di rimborso condivisa (ask_for_refund) ora salva nuovamente il mapping numero d'ordine -> ID reale d'ordine al momento del rimborso con un TTL di 24h; (2) clean_order_number(), quando il transient non esiste più, ora cerca l'ordine in modo inverso per il meta persistito del numero d'ordine (_payment_order_number_redsys / _redsys_transaction_id2) prima di utilizzare mai l'euristica con perdita; e (3) PayGold ora persiste il numero d'ordine nel meta quando crea il link, in modo che un link pagato molto dopo continui a risolversi all'ordine esatto. Si applica a tutti i gateway (Reindirizzamento, InSite, Bizum, Bizum InSite, Google Pay, Apple Pay, PayGold e Domiciliazione Bancaria). Inespay non è influenzato (collega gli ordini tramite il proprio id di payin).
- I pagamenti con carta di InSite nel checkout a blocchi (Blocks) fallivano la PRIMA volta con "msg18" (il cliente vedeva "controlla che i campi del checkout/carta siano compilati") e funzionavano solo al secondo tentativo. L'SDK di InSite di Redsys richiede che la pagina invii un messaggio "domain" all'iframe della carta affinché Redsys possa convalidare il commercio; l'SDK lo fa tramite un onload="setMerchantDomain(0)" in linea nell'iframe. Lo script di blocchi sovrascriveva quel gestore con il proprio iframe.onload (usato per dimensionare l'iframe) subito dopo il primo rendering, quindi il dominio del commercio non veniva mai inviato e Redsys rifiutava la tokenizzazione con msg18 ("validazione errata da parte del commercio"). Nel refresh automatico del modulo la sovrascrittura non veniva eseguita, quindi il secondo tentativo funzionava. Il plugin ora chiama esplicitamente setMerchantDomain dopo aver costruito il modulo (come fa l'integrazione del pulsante di pagamento dell'SDK) e non sovrascrive più l'onload dell'iframe, in modo che il primo tentativo funzioni.
- Checkout a blocchi di InSite: è stato reso più robusto il trattamento del postMessage di Redsys e sono stati aggiunti diagnostici end-to-end. Il gestore ora accetta messaggi da qualsiasi sottodominio di Redsys (sis.redsys.es, sis-t.redsys.es, sis-d.redsys.es) invece di richiedere una corrispondenza esatta di host/porta (Redsys pubblica da più di un host), elimina qualsiasi listener lasciato da un rendering precedente affinché un singolo token non possa attivare più invii, e pulisce i campi di token/errore dopo averli letti affinché un ri-invio obsoleto non possa reinviarli. Quando il registro di debug di InSite è attivato, tutto il passaggio di tokenizzazione dal lato client (numero d'ordine, postMessage di Redsys, token/codice di errore, salvato e place-order) si riflette nel log "insite" di WooCommerce, in modo che i fallimenti del primo tentativo che non arrivano mai a PHP possano essere diagnosticati.
- I pagamenti con carta di InSite nel checkout a blocchi (Blocks) venivano rifiutati da Redsys con SIS0574 ("operazione di autenticazione EMV3DS rifiutata, browserUserAgent non indicato"): l'impronta 3DS del browser (user agent, dimensione dello schermo, lingua, profondità del colore, fuso orario) non arrivava mai all'ordine, perché il hook che normalmente la copia all'ordine (woocommerce_checkout_create_order) non viene eseguito nel checkout della Store API (Blocks). Il modulo di InSite di Blocks ora raccoglie l'impronta e la invia insieme al token di operazione, e viene scritta nell'ordine reale (insieme al token) prima che venga eseguito process_payment, in modo che l'autenticazione EMV3DS abbia i dati di cui ha bisogno.
- I pagamenti con carta di InSite nel checkout a blocchi (Blocks) venivano rifiutati con un "codice di errore senza token" (mostrato al cliente come "controlla che i campi del checkout/carta siano compilati"), quindi la carta non poteva nemmeno essere tokenizzata dopo alcuni tentativi. Poiché l'ordine non esiste ancora nel checkout di Blocks (id ordine 0), il numero d'ordine di Redsys preparato veniva generato a partire dall'id 0, producendo un valore quasi costante -solo ~999 numeri possibili, tutti terminati in nove zeri- e Redsys rifiuta un numero d'ordine riutilizzato ("ordine ripetuto", SIS0051). Quando l'id dell'ordine bozza non è ancora disponibile, il modulo di InSite di Blocks ora utilizza lo stesso numero d'ordine temporaneo del checkout shortcode di InSite (create_checkout_insite_number: inizia sempre per 1, globalmente unico tramite un contatore incrementale condiviso), quindi non collide mai; quando l'id dell'ordine bozza è disponibile, il numero di Redsys viene costruito a partire da esso. Il numero viene nuovamente collegato all'id reale dell'ordine quando l'ordine viene effettuato.
- I pagamenti con carta di InSite nel checkout a blocchi (Blocks) fallivano: il cliente vedeva un messaggio ingannevole "controlla che i campi del checkout/carta siano compilati" e l'ordine non veniva mai pagato (la console del browser mostrava un 404 nella richiesta save_order_data). La causa è che il WooCommerce attuale non crea più l'ordine fino a quando il cliente preme "Effettua l'ordine" -durante l'inserimento della carta il negozio del checkout di Blocks restituisce l'id ordine 0- quindi il token di operazione di InSite (idOper) e il numero d'ordine di Redsys preparato non potevano essere persistiti: il flusso precedente li inviava a un percorso REST (save_order_data) che tentava di allegarli all'ordine 0 e restituiva "Ordine non valido" (404), e il numero d'ordine generato veniva mappato all'ordine 0 (in modo che nemmeno una notifica successiva potesse trovare l'ordine). Ora, quando la carta viene tokenizzata, il token e il numero d'ordine preparato vengono salvati nella sessione di WooCommerce tramite admin-ajax (la sessione di WC non è disponibile in percorsi REST personalizzati, motivo per cui l'approccio REST precedente non poteva usarla), e vengono trasferiti all'ordine reale mentre WooCommerce lo crea dalla richiesta del checkout (woocommerce_store_api_checkout_update_order_from_request), prima che venga eseguito process_payment, in modo che process_payment_block() trovi _insite_token e _payment_order_number_redsys come nel checkout classico. Il transient del numero d'ordine viene anche nuovamente mappato all'id reale dell'ordine affinché la notifica (IPN) risolva l'ordine. I dati dell'impronta del browser (3DS) utilizzavano già questo stesso percorso di sessione. Il checkout classico/shortcode non è influenzato.
Sviluppo:
- Rimossa l'uscita rumorosa di debug console.log dagli script frontend di produzione (minificati): Apple Pay, Google Pay, capture-order-id e i modali di express-checkout. Lo script di Apple Pay Express in particolare registrava ad ogni cambiamento del DOM (monitorando l'intero documento in cerca del suo pulsante), inondando la console del browser nel checkout di Blocks. I file minificati ora rimuovono console.log/console.warn/console.info/console.debug mantenendo console.error; le fonti non minificate rimangono invariate per lo sviluppo.
31.0.4
Corretto:
- Le rinnovazioni dell'abbonamento (con qualsiasi plugin di abbonamenti) ora rispettano il tipo di numero d'ordine di Redsys configurato e non falliscono più nel riprovare con "numero d'ordine ripetuto" (SIS0051). Sono stati corretti due problemi.
- Il primo: il costo di rinnovo generava il numero d'ordine di Redsys ignorando l'impostazione "Tipo di numero d'ordine" (redsysordertype/subfix); ricorreva sempre allo schema casuale predefinito invece del tipo configurato per il gateway, a differenza del pagamento iniziale del checkout. Ora il gateway viene passato affinché le rinnovazioni rispettino lo stesso tipo di numero d'ordine del checkout.
- Il secondo: il numero d'ordine veniva mantenuto per tutta la vita dell'ordine, in modo che quando un costo di rinnovo veniva rifiutato e il plugin di abbonamenti lo riprovava sullo stesso ordine di rinnovo, veniva reinviato esattamente lo stesso DS_MERCHANT_ORDER e Redsys bloccava il tentativo legittimo come duplicato. Ora la distinzione tra "flusso" e "riprovare" è esplicita: un unico flusso di pagamento (il suo par iniziaPeticion/trataPeticion, i processi concorrenti di rinnovo e qualsiasi riesecuzione tramite Action Scheduler di un processo che è morto a metà del costo) mantiene lo stesso numero d'ordine per non incrociare Id Opers (SIS0502) ed essere idempotente rispetto ai costi duplicati; ma una volta che Redsys conferma un rifiuto (una risposta firmata senza codice di autorizzazione, cioè senza movimento di denaro), il numero viene liberato affinché il successivo tentativo generi uno nuovo e unico rispettando il tipo configurato. Il riavvio avviene SOLO in caso di un rifiuto confermato, mai in caso di errori di trasporto o di timeout dove il risultato è sconosciuto, in modo che una riesecuzione per risposta persa non possa mai duplicare il costo.
- Si applica ai gateway di Reindirizzamento e InSite e a tutti i plugin di abbonamenti che li utilizzano (WooCommerce Subscriptions, Subscriptions for WooCommerce, YITH, WebToffee, SUMO, Advanced Subscriptions; Google Pay e Apple Pay delegano al gateway di Reindirizzamento).
- Come rete di sicurezza, quando non è configurato un tipo di numero d'ordine valido (vuoto o un valore ereditato o non riconosciuto), il generatore ricorre SEMPRE allo schema predefinito "3 cifre casuali + zeri + id dell'ordine", l'unico che non collide mai nei riprovi. Nota: il tipo "numero d'ordine semplice" non ha componente casuale, quindi è incompatibile per design con i riprovi di abbonamenti e non dovrebbe essere utilizzato quando ci sono abbonamenti attivi.
