Abbonamenti Avanzati per WooCommerce 2.0.x

Lo sviluppo di questa versione è costato 4.360 euro. Il costo della prima versione è stato di 38.000 euro. Il costo accumulato dalla prima versione è di 42.360 euro, ma il costo per te è solo la licenza a partire da 80€.

Nuovo ramo 2.0.x del plugin Abbonamenti Avanzati per WooCommerce. È una versione principale: il plugin smette di dipendere dall'estensione WooCommerce Subscriptions e introduce addebiti ricorrenti automatici nativi con Stripe, PayPal Payments e WooPayments, oltre a Redsys, che continua a viaggiare all'interno del plugin stesso.

Versioni del ramo

• 2.0.0

2.0.0

Importante:

• Questa è una versione principale. Leggi le note di aggiornamento prima di aggiornare, specialmente se attualmente addebiti tramite PayPal Standard.
• Questa versione richiede WordPress 6.5 o superiore e WooCommerce 8.0 o superiore. Il requisito precedente (WordPress 5.1, WooCommerce 5.1) non era mai stato testato realmente, e testandolo per questa versione si è verificato che il plugin non poteva funzionare lì. Le nuove cifre sono quelle su cui è stata verificata questa versione.
• PayPal Standard non è più supportato. WooCommerce stesso lo sconsiglia dalla sua versione 5.5 e lo blocca in nuove installazioni. Se attualmente addebiti gli abbonamenti con PayPal Standard, installa WooCommerce PayPal Payments e migra i metodi di pagamento dei tuoi clienti prima di aggiornare alla 2.0.0.

Nuovo:

• Addebiti ricorrenti automatici con Stripe. I rinnovi vengono ora addebitati off-session sulla carta salvata del cliente utilizzando il plugin WooCommerce Stripe Payment Gateway (è richiesta la versione 9.8.0 o superiore). Non è necessaria alcuna estensione di pagamento Subscriptions.
• Addebiti ricorrenti automatici con PayPal Payments. I rinnovi vengono addebitati tramite il token della vault (vault) di PayPal utilizzando il plugin WooCommerce PayPal Payments (è richiesta la versione 3.0 o superiore). Non è necessaria alcuna estensione di pagamento Subscriptions.
• Addebiti ricorrenti automatici con WooPayments. I rinnovi vengono addebitati off-session sul metodo di pagamento salvato del cliente utilizzando il plugin WooPayments (è richiesta la versione 7.0 o superiore). Non è necessaria alcuna estensione di pagamento Subscriptions.
• Salvataggio affidabile del metodo di pagamento al checkout. Quando un cliente acquista un abbonamento con Stripe, PayPal Payments o WooPayments, il plugin si assicura che il metodo di pagamento venga salvato per i rinnovi, anche se queste passerelle normalmente lo fanno solo quando WooCommerce Subscriptions è attivo.
• Gestione di 3D Secure (SCA) nei rinnovi. Quando la banca richiede un'autenticazione aggiuntiva per un addebito ricorrente, il rinnovo viene contrassegnato come fallito con un motivo chiaro e si può avvisare il cliente affinché autorizzi il tentativo successivo.
• Riprova automatica dei rinnovi falliti. Quando un pagamento fallisce (carta rifiutata, saldo insufficiente, autenticazione richiesta, ecc.), il programmatore di ripetizioni riprogramma automaticamente il tentativo successivo.
• Rilevamento di accordi PayPal annullati. Se un cliente annulla la propria autorizzazione PayPal al di fuori del tuo negozio, il successivo rinnovo lo rileva, l'abbonamento passa a "in attesa" e il metodo di pagamento salvato viene contrassegnato come non valido affinché il cliente possa ri-autorizzarlo.
• Controllo di sicurezza della valuta nei rinnovi. Il plugin si rifiuta di addebitare un rinnovo in una valuta diversa da quella del pagamento originale, evitando addebiti doppi accidentali nella valuta sbagliata dopo un cambio di valuta del negozio.
• Cambio di metodo di pagamento tra passerelle. I clienti possono cambiare tra Stripe, PayPal Payments e WooPayments da Il mio account, e il successivo rinnovo utilizza automaticamente il nuovo metodo.
• Nuova impostazione di amministrazione "Annulla abbonamento in caso di rimborso totale di un ordine di rinnovo", in WooCommerce > Impostazioni > Abbonamenti Avanzati > Impostazioni Avanzate. Disattivato per impostazione predefinita. Quando è disattivato, un rimborso totale lascia solo una nota nell'abbonamento; quando è attivato, l'abbonamento viene annullato. I rimborsi parziali non annullano mai.
• I rimborsi dell'ordine del primo pagamento (l'ordine padre) annullano sempre l'abbonamento. È ciò che ci si aspetta naturalmente quando si rimborsa l'acquisto originale, ed è indipendente dalla nuova impostazione di amministrazione.
• Note automatiche nell'abbonamento ogni volta che viene rimborsato un rinnovo (totale o parziale), affinché la cronologia dell'abbonamento rimanga chiara.
• Pannello di compatibilità delle passerelle di pagamento nella schermata delle impostazioni del plugin (WooCommerce > Impostazioni > Abbonamenti Avanzati > Impostazioni Generali). Mostra a colpo d'occhio se i plugin di passerella supportati sono installati e attivi, e offre collegamenti di installazione o attivazione con un clic quando non lo sono.
• Rilevamento di dispute e chargeback in Stripe e PayPal. Quando un cliente apre una disputa, l'ordine correlato passa a "in attesa" affinché tu possa reagire prima del successivo rinnovo.
• Rilevamento della rimozione del metodo di pagamento in Stripe. Se il token della carta salvata viene eliminato, tutti gli abbonamenti che lo utilizzano vengono contrassegnati e passano a "in attesa" affinché il cliente possa salvare un nuovo metodo.
• Redsys appare nel pannello di compatibilità delle passerelle come passerella inclusa: viaggia all'interno di questo plugin e non necessita mai di un'installazione separata.

Corretto:

• Disattivare WooCommerce non fa più cadere l'intero sito. Fino ad ora, se WooCommerce smetteva di essere attivo per qualsiasi motivo (lo disattivavi per controllare qualcosa, un aggiornamento falliva o si verificava un errore), questo plugin continuava a tentare di usarlo e faceva cadere tutte le pagine del sito, inclusa l'amministrazione di WordPress, senza alcun modo di tornare indietro se non tramite FTP. Ora il plugin rileva che WooCommerce non è presente, non fa nulla in silenzio e mostra un avviso esplicativo nell'amministrazione. Riattivando WooCommerce tutto viene ripristinato senza alcuna azione aggiuntiva.
• I rinnovi potevano essere programmati nel momento sbagliato, o non programmati, in negozi la cui zona oraria è configurata come offset UTC invece che come città. La correzione influisce su come viene letta la zona oraria del sito nel calcolare quando scade un pagamento programmato.
• Un ordine annullato non lascia più dietro di sé un abbonamento fantasma. Se un pagamento falliva e il tentativo del cliente generava un NUOVO ordine invece di riprendere il primo (cosa che accade quando si perde la sessione o si cambia il carrello), l'abbonamento non pagato dell'ordine abbandonato rimaneva per sempre nell'account del cliente. Non veniva mai addebitato e non poteva essere attivato, ma il cliente vedeva un abbonamento che non aveva mai pagato. Annullare quell'ordine ora lo elimina. Gli abbonamenti già attivi non vengono mai toccati: annullare un ordine di rinnovo lascia l'abbonamento attivo, come deve essere.
• Cancellare il plugin ora pulisce ciò che è suo. Fino ad ora, eliminare il plugin lasciava tutto dietro: le sue impostazioni, i suoi blocchi di pagamento e —quello che aveva conseguenze visibili— i suoi compiti programmati, che WordPress continuava a tentare di eseguire anche se non c'era nulla installato che li gestisse, fallendo e riprovandoli indefinitamente. Ora, disinstallando si eliminano le impostazioni proprie del plugin e si annullano i suoi compiti programmati. Deliberatamente NON vengono cancellati i tuoi abbonamenti, i tuoi ordini o alcun dato dei clienti: sono registri aziendali, rimangono nel database, e reinstallando il plugin tornano esattamente come erano.
• Cancellare il plugin in un sito che non ha mai avuto WooCommerce non riempie più il log degli errori. La pulizia cercava compiti programmati in una tabella che WooCommerce non aveva mai creato, producendo un errore di database per ogni gruppo di compiti del plugin. Non è mai stato fatale (la pulizia terminava comunque e i messaggi apparivano solo con il debug attivato), ma in una rete multisitio si ripeteva in ogni sito. La pulizia continua a funzionare esattamente allo stesso modo; vengono solo silenziati i messaggi inutili, e solo in un sito dove quella tabella manca davvero.
• Prodotti variabili con una miscela di variazioni di abbonamento e di non abbonamento: acquistare una variazione che NON è un abbonamento non salva più la carta del cliente né crea un abbonamento. Il plugin decideva se una variazione fosse di abbonamento guardando l'impostazione del prodotto padre e ignorava completamente la casella "Abbonamento" della variazione stessa, quindi in un prodotto variabile dove solo alcune variazioni sono abbonamenti, tutte si comportavano come tali. Una variazione senza impostazione propria continua a ereditare quella del padre, in modo che un prodotto che hai appena contrassegnato come abbonamento continui a funzionare fino a quando non configuri le sue variazioni.
• Un abbonamento impostato per rinnovarsi manualmente non viene più addebitato automaticamente. Tra il rinnovo programmato e il gateway di pagamento non c'era nulla che verificasse se il cliente avesse richiesto di pagare manualmente, e all'ordine di rinnovo —che per i rinnovi manuali viene creato deliberatamente senza metodo di pagamento— veniva assegnato uno a partire dall'ordine originale poco prima dell'addebito. I rinnovi manuali ora si fermano in entrambi i punti e viene pulito qualsiasi tentativo automatico in sospeso su di essi.
• Impostare la data di inizio di un abbonamento dalla schermata di amministrazione non provoca più un errore fatale. La schermata chiamava un metodo di scrittura delle date che non esisteva nell'oggetto dell'abbonamento, quindi in qualsiasi negozio senza l'estensione WooCommerce Subscriptions il salvataggio falliva con "Chiamata a metodo non definito". Il flusso degli ordini con data di inizio falliva allo stesso modo a causa di un secondo metodo inesistente. Entrambi sono ora implementati sullo storage delle date del plugin; un abbonamento a cui non è mai stata scritta una data di inizio continua a riportare la data di creazione del suo ordine, esattamente come prima.
• Prodotti variabili: le impostazioni di abbonamento per variazione non apparivano mai selezionando una variazione come abbonamento. La schermata di modifica del prodotto richiedeva lo script caricatore non minificato indipendentemente dall'impostazione SCRIPT_DEBUG, quindi nelle installazioni che includono solo la risorsa minificata restituiva un 404 e il pannello dei campi —che rimane nascosto fino a quando quel script non viene eseguito— non appariva.
• Le email di notifica dell'abbonamento inviate direttamente tramite l'API Scheduler del plugin ora vengono inviate. L'API accettava un tipo di notifica e lo passava avanti, ma la funzione che c'era dietro non dichiarava quel parametro, quindi PHP lo scartava e il tipo arrivava vuoto: non veniva inviata alcuna email e l'evento di notifica non indicava alcun tipo. Le notifiche lanciate dal programmatore nei propri hook non erano interessate.
• Una data di primo pagamento impostata dalla schermata di amministrazione dell'abbonamento ora viene addebitata. L'azione programmata veniva creata con il nome dell'hook di WooCommerce Subscriptions, che questo plugin non ascolta, quindi il pagamento semplicemente non veniva mai eseguito nei negozi senza quell'estensione. L'azione ora viene programmata nell'hook di rinnovo del plugin e nello stesso gruppo delle altre azioni di pagamento, quindi annullare, mettere in pausa o eliminare l'abbonamento lo rimuove come ci si aspetterebbe. Il nome dell'hook precedente continua a essere programmato in parallelo per i negozi che dipendevano da esso, e può essere disattivato con il filtro aswc_start_date_schedule_legacy_payment_hook.
• Cambiare una data di primo pagamento già programmata ora sposta quel pagamento invece di aggiungere un secondo.
• L'integrazione con i blocchi Carrello e Pagamento non scompare più nei siti che funzionano con SCRIPT_DEBUG attivato. Veniva distribuito solo lo script minificato, quindi il percorso non minificato che WordPress richiede in quella modalità restituiva un 404 e tutta l'integrazione smetteva di caricarsi silenziosamente, portandosi via il controllo "Visualizza Prodotti Allegati" delle caselle di abbonamento e gli annunci vocali del totale ricorrente. Ora entrambe le versioni vengono generate a partire dallo stesso codice sorgente.
• Le tabelle degli sconti delle pagine prodotto ora caricano il loro foglio di stile e il loro script nei temi classici. Le risorse venivano risolte a partire dal prodotto che si stava renderizzando nel ciclo, che non era ancora disponibile quando un tema classico accoda gli script, quindi in quei temi la tabella appariva completamente senza stili e il refresh degli sconti dei prodotti variabili non veniva eseguito. I temi a blocchi non erano interessati.
• Gateway Redsys incluso: gli ordini di abbonamento vengono ora rilevati correttamente al checkout, quindi viene richiesto a Redsys il token della carta ricorrente (COF) e i rinnovi possono essere addebitati automaticamente.
• Gateway Redsys incluso: la carta di abbonamento salvata appare ora in Il mio account > Metodi di pagamento (etichettata come "Abbonamento"). Il filtro dei metodi di pagamento salvati la nascondeva quando veniva eseguito al di fuori del contesto di checkout.
• Gateway Redsys incluso: salvare il token dell'abbonamento non interrompe più la notifica di pagamento quando la banca non restituisce il numero della carta mascherato (Ds_Card_Number); viene memorizzato un marcatore sicuro degli ultimi quattro cifre affinché la tokenizzazione e i rinnovi automatici continuino a funzionare.
• Gateway PayPal: il contenitore dei servizi del plugin ufficiale viene ora ottenuto tramite l'azione reale di avvio di PPCP (con un'alternativa diretta), quindi gli addebiti di rinnovo funzionano. La ricerca precedente dipendeva da un filtro che non esiste in WooCommerce PayPal Payments.
• Gateway PayPal: i payload dei webhook non vengono più elaborati quando la verifica della firma di PayPal ha rifiutato la richiesta, chiudendo un vettore di manipolazione non autenticata dello stato degli ordini e degli abbonamenti.
• Gateway PayPal: gli addebiti di rinnovo seguono esattamente il gestore ufficiale dei rinnovi (solo vault_id, senza il campo non valido stored_credentials) e il risultato dell'addebito viene letto dalla cattura reale, non solo dallo stato dell'ordine di PayPal. Le configurazioni con intenzione di autorizzazione vengono segnalate chiaramente invece di essere contrassegnate come pagate senza catturare i fondi.
• Gateway PayPal: gli ordini di rinnovo ora memorizzano i metadati ufficiali di PayPal e l'identificatore della transazione, quindi i rimborsi dalla gestione di WooCommerce e le richieste di dispute funzionano sugli abbonamenti addebitati dal gateway.
• Gateway PayPal: la disponibilità del vault viene letta dal sistema delle impostazioni attuale (con alternativa ereditata), i token di Venmo e Apple Pay vengono inviati con la loro payment source corretta, e il marchio di vault viene iniettato nel checkout solo quando salvare i metodi di pagamento è realmente idoneo.
• Gateway PayPal: i gateway di PayPal vengono nascosti al checkout per i carrelli di abbonamento con prova gratuita (totale zero), che PayPal non può salvare nel vault senza un addebito reale in questa configurazione.
• Gateway Stripe: le eccezioni dell'API di Stripe durante i rinnovi vengono catturate e registrate come fallimenti di pagamento, e ogni addebito di rinnovo invia una chiave di idempotenza deterministica, evitando addebiti duplicati quando una richiesta scade e viene ripetuta.
• Gateway Stripe: i rinnovi corretti ora memorizzano l'identificatore di addebito di Stripe come identificatore di transazione dell'ordine, quindi i rimborsi e le dispute avviate dal pannello di Stripe vengono associate all'ordine corretto.
• Gateway Stripe: i rinnovi pagati con token di Stripe Link vengono addebitati con il tipo di metodo di pagamento corretto, e il controllo della valuta originale legge la valuta memorizzata localmente invece di chiamare l'API di Stripe ad ogni rinnovo.
• Gateway Stripe: il supporto per SEPA è stato rimosso. L'identificatore del gateway SEPA ereditato non esiste più in Stripe 10.x e i suoi rinnovi non potevano mai essere addebitati; carta e Link continuano a essere completamente supportati.
• WooPayments e Stripe: il metodo di pagamento viene ora salvato in modo affidabile nel checkout a blocchi (Store API). La rilevazione precedente non corrispondeva mai a causa del modo in cui WooCommerce espone il contesto di pagamento, e gli abbonamenti rimanevano senza token per i rinnovi.
• Il salvataggio del metodo di pagamento non duplica più la carta quando il cliente paga con un metodo di pagamento già salvato.
• Cambiare il metodo di pagamento di un abbonamento con WooPayments o Stripe ora tokenizza la nuova carta senza addebitare al cliente. Prima si poteva addebitare l'importo totale del rinnovo al momento del cambiamento.
• Il checkout attiva e nasconde automaticamente la casella "salva metodo di pagamento" nei gateway di carta quando il carrello contiene un abbonamento, quindi gli acquisti con 3D Secure terminano anche con un token salvato.
• Gli hook di pagamento dei rinnovi controllano ora che l'ordine necessiti ancora di pagamento prima di addebitare (programmatore, gateway e l'azione "retry payment" della gestione), evitando addebiti duplicati su ordini già pagati o autorizzati.
• Quando un metodo di pagamento salvato smette di essere valido o viene eliminato, l'abbonamento interessato passa ora a "in attesa" con una nota esplicativa, invece di fallire silenziosamente nel successivo rinnovo.
• Le letture dei metadati nei negozi senza HPOS potevano restituire l'abbonamento sbagliato o corrompere i contatori di ripetizione a causa di un argomento errato passato a get_post_meta(); tutte le chiamate sono state corrette.
• Gateway Redsys incluso: viene verificata la firma della risposta REST di rinnovo, i confronti di firma utilizzano hash_equals(), le notifiche vengono rifiutate quando non è configurata una chiave SHA-256, e è stato corretto un difetto nella gestione della chiave in modalità di prova. Nota: i rinnovi addebitano intenzionalmente il token ricorrente (R) più recente del cliente; quando un cliente aggiorna la propria carta, il nuovo token sostituisce il precedente per tutti i suoi addebiti ricorrenti.

Sicurezza:

• La casella di abbonamento multiprodotto ora decide il proprio prezzo sul server. La richiesta di "aggiungere all'abbonamento" portava il totale della casella, e quella cifra veniva memorizzata come prezzo di linea del carrello, quindi una richiesta manipolata poteva acquistare una casella per qualsiasi importo. Il prezzo deriva ora dai prezzi dei prodotti del negozio stesso (o dal prezzo fisso impostato nella casella) e la cifra della richiesta viene ignorata.
• La casella di iscrizione multiprodotto accetta ora solo i prodotti che offre realmente. Sia la richiesta di aggiunta che quella di modifica accettavano qualsiasi ID prodotto e restituivano il suo nome, prezzo e immagine senza controllare né la configurazione della casella né se il prodotto è visibile pubblicamente, rivelando così i prezzi di prodotti in bozza, privati e protetti da password a visitatori non identificati. Le selezioni vengono ora validate rispetto all'elenco dei prodotti o categorie della casella stessa e rispetto alla visibilità del prodotto.
• Salvare una variazione di prodotto richiede ora la capacità «edit products» da sola, oltre al suo nonce. Non era sfruttabile prima, perché WooCommerce raggiunge quel gestore solo dopo il proprio controllo delle capacità; è una difesa in profondità nella funzione che scrive.

Aggiornato:

• Quando non è possibile leggere il fuso orario del sito, il plugin lo segnala ora nel proprio log. Ha sempre continuato invece di fallire, ricorrendo al fuso orario UTC del sito e, in mancanza, al proprio UTC. Farlo in silenzio significava che un rinnovo addebitato a un orario inaspettato non aveva nulla che lo spiegasse. Il comportamento alternativo non cambia; ora viene registrato, e solo quando accade realmente.
• Pulizia interna: il plugin non mescola più i propri dati con quelli dell'estensione WooCommerce Subscriptions, evitando conflitti quando entrambi i plugin coesistono nello stesso sito.
• Documentazione per sviluppatori aggiornata. Il riferimento agli hook copre ora tutte le nuove azioni e filtri introdotti dai gateway di pagamento (vedi docs/hooks-reference.md).
• Gateway Redsys incluso: il registro migra dall'API obsoleta WC_Logger::add() al logger moderno, e l'identificatore del modulo nei log riflette ora questo plugin (Advanced_Subscriptions_Redsys) invece del gateway indipendente Redsys Light.

Compatibilità:

• Testato fino a WordPress 7.1 e WooCommerce 11.1.0.
• Richiede WooCommerce Stripe Payment Gateway 9.8.0 o superiore per il gateway di Stripe.
• Richiede WooCommerce PayPal Payments 3.0 o superiore per il gateway di PayPal.
• Richiede WooPayments 7.0 o superiore per il gateway di WooPayments.
• Completamente compatibile con l'archiviazione degli ordini ad alte prestazioni di WooCommerce (HPOS).
• Il plugin non dipende più dall'estensione WooCommerce Subscriptions. Funziona in modo autonomo.