WooCommerce Redsys Gateway 32.1.x

Lo sviluppo di questa versione è costato 2.300 euro. Il costo accumulato per quest’anno è di 37.430 euro. Il costo accumulato dalla prima versione è di 236.160 euro, ma il costo per te è solo la licenza di 79€.

Nuovo ramo 32.1.x del plugin Redsys per WooCommerce di WooCommerce.com.

Versioni del ramo

• 32.1.0

32.1.0

Nuovo:

• Il rapporto di stato di WooCommerce (WooCommerce – Stato) elenca ora anche ciò che è attivato nella scheda “Impostazioni avanzate” di Redsys: notifiche push, fatture sequenziali, codici QR, carte salvate, sovrascrittura degli stati degli ordini, regole condizionali, abbonamenti, riconciliazione via email, i protocolli di commercio agentico e l’API dell’app di gestione. Le credenziali non vengono mai stampate: di ciascuna si indica solo se è configurata o meno. Viene incluso quando si copia il rapporto per inviarlo al supporto, che è proprio l’obiettivo: una richiesta di supporto arriva già con la configurazione all’interno.
• Ora puoi decidere se ai tuoi clienti viene offerta l’opzione “Aggiungi una carta di credito per Abbonamenti” nel Mio account – Metodi di pagamento. Fino ad ora questa opzione appariva da sola non appena c’era un plugin di abbonamenti attivo, senza modo di rimuoverla, e questo non è ciò che vuole ogni negozio: in un negozio dove la carta dell’abbonamento viene sempre catturata durante l’acquisto, l’unica cosa che faceva era invitare il cliente a salvare una carta che non sarebbe mai stata addebitata. Il nuovo interruttore si trova in Redsys – Impostazioni avanzate – Carte salvate, è attivato affinché nulla cambi nei negozi che già lo offrivano, e disattivandolo rimane sola la carta di 1-click. Viene anche segnalato nel rapporto di stato di WooCommerce.

Sicurezza:

• Il plugin scriveva nel proprio file di registro l’indirizzo della pagina di “ordine ricevuto” di ogni acquisto, in tutti i pagamenti, e quell’indirizzo contiene la chiave dell’ordine: il testimone privato che WooCommerce inserisce nel link di pagamento dell’acquirente e che questo plugin richiede prima di mostrare un ordine. Chiunque avesse accesso in lettura al file di registro poteva, quindi, aprire quegli ordini e vedere il nome, l’email, il telefono e gli indirizzi che contenevano. Questo accadeva sia che il registro di debug fosse attivato o meno nel negozio, perché quel punto specifico scriveva nel log senza controllare quell’impostazione. Ora rispetta l’impostazione di debug come il resto dei registri che scrive il plugin, e la chiave viene sostituita con “[redacted]” prima di scrivere nulla, in modo che non venga registrata nemmeno con il log attivato. Questa sostituzione è stata applicata successivamente a tutte le righe di registro del plugin, e non solo a quella segnalata: circa novanta righe in più sparse per i gateway stampavano quegli stessi indirizzi ogni volta che il registro di debug fosse attivo, comprese quelle che riversano il messaggio completo inviato alla banca. I file di registro già scritti continuano a contenere quegli indirizzi: se li hai, eliminali.
• La pagina che reindirizza l’acquirente a Redsys (e a Bizum) accettava qualsiasi numero d’ordine scritto nel suo indirizzo, senza controllare che chi lo richiedeva fosse chi aveva effettuato quell’ordine. Poiché i numeri d’ordine sono correlativi, qualcuno poteva scorrerli e leggere i dati che il plugin invia alla banca degli ordini di altri clienti: nome, email, telefono e gli indirizzi di fatturazione e spedizione, insieme all’importo e alla descrizione di ciò che è stato acquistato. In nessun momento è stato esposto un numero di carta, un codice di sicurezza o una chiave di firma, e tramite questa via non si poteva pagare né modificare nulla. Ora quella pagina richiede la chiave dell’ordine che WooCommerce include nel link di pagamento dell’acquirente stesso, in modo che una richiesta che non corrisponde all’ordine venga risposta con una pagina “Forbidden” invece di essere elaborata. La stessa verifica è stata aggiunta alla finestra pop-up di pagamento della pagina di completamento dell’acquisto. Segnalato dal team di sicurezza di Tivify (TVUP Streaming Media), che ha descritto il problema con chiarezza e ci ha dato tempo per correggerlo prima di renderlo pubblico. Grazie.
• I tre pulsanti di preautorizzazione della schermata d’ordine (autorizza, annulla e addebita una parte) e la ricerca clienti di PayGold accettavano le loro richieste senza un testimone di sicurezza. La verifica dei permessi era già al suo posto, quindi solo un gestore di negozio o un amministratore poteva usarli e nessun altro avrebbe potuto eseguirli, ma un amministratore con la sessione già aperta poteva essere ingannato per attivarli da un altro sito senza che se ne accorgesse. Ora tutti e quattro portano e verificano un testimone di sicurezza di WordPress, chiudendo così quella via.
• Il Protocollo di Commercio Agéntico poteva finire attivato senza che nessuno lo avesse scelto, in negozi che si aggiornano automaticamente. Pubblica indirizzi con cui possono parlare macchine, quindi è pensato per essere disattivato a meno che tu non lo attivi, e ora lo è. Se lo avevi attivato, per te non cambia nulla.
• È stata aggiornata la libreria di Google inclusa nel plugin, correggendo due errori nella parte che effettua richieste di rete.

Aggiornato:

• Quando fallisce il rinnovo di un abbonamento, la nota che viene aggiunta all’ordine ora dice esattamente quale passaggio è fallito e con quale codice di commercio e terminale è stato effettuato il tentativo. Fino ad ora i sei possibili fallimenti scrivevano la stessa nota, poco informativa, rendendo quasi impossibile diagnosticare un rinnovo fallito senza accesso al negozio, specialmente in negozi dove non si sta scrivendo il log di debug.
• Quando Apple Pay non riesce a convalidare il negozio con Apple, il registro ora raccoglie la spiegazione di Apple stessa e se i file del certificato possono essere letti. Apple risponde con un generico “Expectation Failed” e mette il motivo reale nel corpo della sua risposta, che non veniva mai registrato, quindi quegli errori erano un vicolo cieco.
• Il plugin distribuito non contiene più gli script di sviluppo e compilazione del progetto, la configurazione del suo ambiente di test locale, le sue directory di editor e di hook di git, il suo README per sviluppatori né un documento interno di revisione della sicurezza. Nulla di tutto ciò veniva caricato quando il plugin veniva eseguito, ma non ha nemmeno alcun impatto sul server di un negozio. Ciò che contiene il pacchetto viene ora controllato automaticamente, prima di ogni pubblicazione, contro un elenco di ciò che il plugin distribuisce realmente, in modo che qualcosa che venga aggiunto al progetto in futuro non possa viaggiare all’interno dello zip senza che nessuno se ne accorga.
• Il compito di riconciliazione via email esiste ora solo mentre quella funzione è attivata, e solo una volta. Prima veniva creato in tutti i negozi e si attivava ogni cinque minuti senza fare nulla.
• Tutte le traduzioni sono di nuovo complete. Sessantanove testi aggiunti da versioni recenti continuavano a comparire in inglese: etichette di impostazioni, il rapporto di stato e alcuni messaggi che un acquirente può vedere. Spagnolo, catalano, basco, galiziano, francese e portoghese sono di nuovo al cento per cento.
• Il testimone che protegge il link di “aggiungi una carta” viene ora confrontato in tempo costante, come il resto dei segreti che confronta questo plugin. Cronometrare quel confronto attraverso internet non è un attacco praticabile, quindi non c’era nulla di sfruttabile; il difetto era l’incoerenza, perché questo era l’unico confronto che è rimasto indietro quando sono stati migrati gli altri durante il lavoro delle firme.

Corretto:

• Con InSite, pagare con una carta che l’acquirente aveva salvato poteva addebitare il denaro e comunque mostrare l’ordine come fallito. Quando la banca approva un pagamento del genere senza chiedere all’acquirente di confermare con l’app della propria banca, che è ciò che accade con una carta salvata, il plugin cercava il risultato nel sito sbagliato, non trovava nulla e trattava quel “nulla” come un rifiuto. L’addebito era già stato effettuato, quindi gli acquirenti a cui veniva detto che il pagamento era fallito pagavano una seconda volta e venivano addebitati due volte. Il risultato ora viene letto dalla risposta firmata della banca stessa, la stessa che già usa il resto del pagamento. Colpiva sia il checkout classico che quello a blocchi, e anche i rinnovi degli abbonamenti. Segnalato da due negozi a pochi giorni di distanza, uno dei quali tracciandolo fino alla linea esatta. Grazie.
• Nella passerella di carta, un pagamento effettuato con una carta salvata veniva dato per completato con solo il numero di autorizzazione, senza controllare la risposta reale della banca che va al suo fianco. Un pagamento rifiutato che comunque avesse qualcosa in quel campo marcava quindi l’ordine come pagato, e il negozio inviava la merce senza aver addebitato. Ora si richiede che entrambi coincidano prima di completare un ordine. Se la risposta della banca manca completamente, il pagamento non viene completato, perché non rimane nulla che dica che è stato approvato; un negozio il cui banco ometta realmente quel campo può ripristinare intenzionalmente il comportamento precedente con il filtro redsys_allow_payment_without_ds_response, che è documentato e che non può essere usato per accettare un pagamento che la banca ha rifiutato.
• In negozi che usano certi plugin di completamento dell’acquisto, Fluid Checkout tra essi, tutti i pagamenti venivano rifiutati da Redsys con l’errore SIS0574. La banca richiede una breve descrizione del browser dell’acquirente con ogni pagamento (la sua lingua, la dimensione dello schermo e simili), che il plugin raccoglie tramite campi nascosti che aggiunge al checkout. Quei campi venivano aggiunti nel momento in cui veniva costruita la passerella di carta, il che in quei negozi avviene dopo che un altro plugin ha già chiesto a WooCommerce l’elenco definitivo dei campi del checkout, e WooCommerce costruisce quell’elenco una sola volta e mai più. I campi, quindi, non venivano creati, non venivano compilati e non venivano inviati, e la banca rifiutava il pagamento. Ora vengono aggiunti non appena il plugin si carica, prima che chiunque possa chiedere l’elenco, il che influisce su tutte le passerelle che li necessitano, quella di carta, Bizum e i portafogli, e non solo su InSite. In InSite la descrizione del browser viaggia inoltre ora con il resto dei dati del pagamento invece di dipendere solo dall’ordine, in modo che sopravviva a un checkout che si ricostruisce da solo. Segnalato da un integratore che già portava la diagnosi dimostrata. Grazie.
• Se un pagamento veniva annullato o rifiutato, l’acquirente tornava al negozio ma l’ordine rimaneva in sospeso e il carrello non veniva ripristinato. L’indirizzo che il plugin dava alla banca per riportare l’acquirente era scritto nella forma utilizzata per i link all’interno di una pagina web, non in quella utilizzata per un indirizzo reale, quindi il negozio riceveva il ritorno senza il riferimento dell’ordine, senza il suo numero e senza il suo testimone di sicurezza, e non aveva nulla da annullare. Colpiva Bizum, Google Pay, Apple Pay, addebito diretto, bonifico, InSite e la passerella di carta ogni volta che l’impostazione di “ritorna a” era impostata su annullare l’ordine. In MasterPass, quello stesso indirizzo veniva inviato direttamente vuoto, per un errore di scrittura di un solo carattere ripetuto in tre righe. Tutto passa ora attraverso un’unica parte di codice condivisa, in modo che una passerella che verrà aggiunta in futuro non possa tornare a sbagliare.
• In modalità di pagamento in finestra pop-up (modale), annullare un pagamento non faceva nulla e l’acquirente rimaneva nel carrello con l’ordine in sospeso. L’indirizzo a cui il plugin inviava il browser era scritto nella pagina in un modo che il browser interpreta come un link all’interno di un documento e non come un indirizzo web, quindi tutto ciò che andava dopo il primo parametro veniva scartato: il riferimento dell’ordine, il suo numero e il suo testimone di sicurezza scomparivano, e WooCommerce non aveva nulla da annullare. Lo stesso difetto colpiva l’indirizzo a cui si riporta l’acquirente dopo aver pagato, dove perdeva silenziosamente un parametro di tracciamento. Entrambi sono stati corretti, nella passerella di carta e in quella di InSite, e il comportamento corretto è stato verificato in un browser reale.
• Il checkout poteva morire con un errore critico, invece di inviare l’acquirente alla banca, con un cliente registrato la cui scheda cliente non era mai stata modificata da quando era stata creata. Il plugin costruisce un insieme di dati di sicurezza per la banca in ogni pagamento, e uno dei campi è la data in cui è stata modificata per l’ultima volta l’account del cliente, che WooCommerce lascia vuota in un account che non è mai stato toccato, normalmente creato tramite un’importazione, una migrazione o automaticamente da un altro plugin. Il plugin leggeva quella data vuota come se fosse una data reale e la pagina di pagamento si fermava lì. Ora ricorre alla data di creazione dell’account, che è ciò che significa “mai modificata”, e la stessa protezione è stata aggiunta al codice equivalente utilizzato dagli abbonamenti, dove quella stessa data vuota veniva segnalata silenziosamente alla banca come “modificata oggi”, che è un’informazione errata per i suoi controlli di frode.
• Redsys e le altre passerelle potevano scomparire dal checkout per tutti, compresi gli acquirenti normali, in negozi dove l’elenco di “mostra solo a questi utenti” della modalità di test non era mai stato compilato. Il plugin leggeva quell’impostazione vuota come “mostralo a un utente il cui id è nulla”, che non corrisponde a nessuno, quindi il metodo di pagamento rimaneva nascosto per tutti i visitatori. Colpiva solo i

• Negozio i cui settaggi erano stati scritti da qualcosa di diverso dalla schermata delle impostazioni, un’importazione, una migrazione o la stessa API di gestione del plugin, perché salvare quella schermata manualmente memorizza un valore vuoto diverso che non lo provocava. Corretto nelle nove gateway che condividevano lo stesso codice.
• Gli abbonamenti pagati con Apple Pay o Google Pay da un cliente senza account non ottenevano mai dalla banca il permesso di pagamento ricorrente, quindi il primo rinnovo falliva con una nota che diceva che non c’era carta. Questo accadeva nei negozi dove l’opzione generale di “permettere ai clienti di creare un account durante il pagamento” è disattivata, qualcosa di comune nei negozi che accettano acquisti come ospiti: i percorsi di pagamento dei wallet non vedevano la sovrascrittura che fa di quell’opzione la stessa WooCommerce Subscriptions, quindi non veniva creato alcun account e, senza account, il permesso della banca non poteva essere memorizzato. Corretto nei quattro siti che lo gestiscono (Apple Pay e Google Pay, sia nel checkout classico che in quello a blocchi).
• Lo script di pagamento del checkout a blocchi era compilato contro una versione di React che lo stesso WordPress non accetta. Una dipendenza solo di sviluppo trascinava un React più nuovo nella compilazione, e WordPress rifiuta gli elementi prodotti da esso, quindi il metodo di pagamento potrebbe non apparire nel checkout a blocchi. La compilazione fissa ora la versione che usa WordPress e lo script è stato rigenerato.
• Il carrello e il checkout potevano diventare notevolmente lenti, anche per visitatori non identificati, in negozi con carte memorizzate o abbonamenti. L’assistente interno WCRed() del plugin costruiva una nuova copia del suo oggetto globale ogni volta che veniva chiamato, e quell’oggetto registra tre hook di WordPress al momento della costruzione. WordPress non sostituisce quegli hook, li aggiunge, quindi in un negozio dove l’assistente viene chiamato una volta per ogni carta memorizzata o abbonamento, le stesse tre verifiche finivano per essere registrate centinaia di volte e venivano rieseguite, tutte, ogni volta che WooCommerce montava l’elenco delle gateway di pagamento disponibili. In un negozio che ha segnalato il problema, questo arrivava a circa 438 registrazioni duplicate per caricamento di pagina e a circa 1,7 secondi di lavoro PHP nella pagina del carrello, di cui solo 56 millisecondi erano query al database. L’assistente ora costruisce quell’oggetto una sola volta e lo riutilizza, in modo che gli hook vengano registrati esattamente una volta per richiesta. Il comportamento del plugin non cambia in nulla: l’oggetto non memorizza dati propri di ogni richiesta. Lo stesso trattamento di un oggetto per richiesta è stato applicato all’assistente WCPSD2(), che aveva la forma identica.
• In una piccola parte dei negozi, la chiave di firma dei messaggi di Commercio Agéntico (UCP) veniva memorizzata in una forma che non poteva mai essere utilizzata, quindi ogni verifica di firma contro di essa falliva e il documento della chiave pubblicato non seguiva lo standard. Quando il plugin creava quella chiave, una delle sue due coordinate tornava di tanto in tanto da OpenSSL un byte più corta di quanto richiesto dallo standard, circa 1 negozio ogni 135, e il plugin la memorizzava così com’era invece di compilarla. Da quel momento il negozio non poteva verificare le proprie firme, né poteva farlo alcun agente esterno, fino a quando la chiave non veniva ruotata. La chiave ora viene memorizzata compilata fino alla lunghezza richiesta, e una chiave già memorizzata nella forma corta viene riparata automaticamente la prima volta che viene letta, quindi nessun commerciante deve ruotare nulla.
• Nei negozi con PHP 8.0 o precedente, attivare la riconciliazione via email rompeva la pagina con un errore del server invece di semplicemente non funzionare. Il plugin ora lo verifica prima e lascia una nota chiara nel suo registro. La funzione stessa continua a richiedere PHP 8.1.
• Le attività in background si accumulavano in decine di copie di se stesse nell’elenco delle azioni programmate di WooCommerce. Corretto in tutti i siti dove il plugin programma qualcosa, e le copie che erano già lì vengono pulite automaticamente.
• Una notifica all’app mobile poteva perdersi senza dare alcun errore se inviata nel momento sbagliato.
• Comparivano avvisi di PHP nel registro del server ad ogni visita alla pagina di “paga ordine”, provenienti dalle gateway di Apple Pay e Google Pay. Per gli acquirenti non c’era nulla di rotto, ma il log di debug di quelle gateway non registrava nulla di quel passaggio, quindi chi cercava di diagnosticare un problema lì stava guardando un errore e non un silenzio. Segnalato da un commerciante, e trovato in tre gateway invece di in quella segnalata. Grazie.
• Attivare il log di debug per indagare su un problema di pagamento con carta produceva avvisi invece delle informazioni per cui era stato attivato.
• Il pulsante “Connetti con Google” delle impostazioni di riconciliazione via email non veniva mai mostrato. Concedere l’accesso era già possibile compilando i dati di Google e premendo “Salva modifiche”, quindi questo ripristina una scorciatoia, non sblocca la funzione.
• Il plugin inviava al negozio un’email dicendo “Redsys non sta inviando campi di tokenizzazione” dopo pagamenti in cui Redsys aveva inviato tutti e ciascuno di essi. La verifica dietro quell’avviso controllava una variabile che non esiste da nessuna parte nel plugin, e una verifica su qualcosa che non esiste è sempre vera, quindi l’avviso appariva ad ogni pagamento che memorizzava una carta. I commercianti lo portavano alla loro banca, che rispondeva giustamente che il terminale era a posto. L’avviso ora informa solo di assenze reali, e indica nel registro quale campo mancava, la data di scadenza, il marchio della carta o il numero, invece di dire unicamente che mancava qualcosa. Ha anche dovuto smettere di leggere il marchio dopo che il plugin lo ha convertito in un nome da visualizzare, perché quella conversione risponde “Unknown” quando non c’è marchio, il che avrebbe reso l’avviso uno che non potrebbe mai apparire. Quello stesso blocco scriveva “unknown” come numero di carta nel log di debug ad ogni pagamento, a causa di un nome di variabile con una lettera in più; ora scrive il numero mascherato reale.
• Cercare nella schermata dei token di Redsys (WooCommerce – Redsys tokens) per email o per nome utente non trovava alcuna carta memorizzata a partire dal venticinquesimo. La schermata chiedeva al database una pagina di token e cercava poi all’interno di quella pagina, e poiché li chiedeva senza alcun ordine specifico, quella pagina era sempre i venticinque token più vecchi del negozio, quindi le carte memorizzate di recente, che sono le uniche che qualcuno cerca, risultavano inaccessibili. La ricerca ora viene effettuata nel database, su tutti i token, e l’elenco arriva dal più nuovo al più vecchio. Il contatore sopra la tabella e l’elenco sottostante non possono più discrepare, ordinare per nome utente o per email ora ordina tutta la tabella invece della pagina visibile, e la schermata non carica più in memoria tutti i token del negozio solo per contarli, cosa che in negozi con migliaia di carte memorizzate faceva ad ogni caricamento di pagina.