PrestaShop è costruito attorno a un atto unico: un carrello, un ordine, un pagamento. L’abbonamento presuppone il contrario, un impegno che produce pagamenti nel tempo senza che il cliente torni. Questi due modelli non si incontrano naturalmente.
Ecco l’architettura che funziona, e i punti in cui le implementazioni si rompono.
Chi detiene la verità
Prima decisione, e condiziona tutto il resto.
Una piattaforma di pagamento come Stripe dispone di un motore di fatturazione ricorrente completo: abbonamenti, scadenze, ritentativi, gestione delle carte scadute. Ricostruirlo dentro PrestaShop sarebbe un errore.
La ripartizione che regge: Stripe detiene l’abbonamento, cioè il ciclo, le scadenze e l’incasso. PrestaShop detiene il catalogo, il cliente e gli ordini generati a ogni scadenza.
In concreto, ogni addebito riuscito crea un ordine in PrestaShop, che segue poi il vostro normale processo di preparazione e spedizione. È ciò che permette di mantenere coerenti le statistiche, le fatture e la logistica.
I webhook da ascoltare
È il cuore dell’integrazione, e il punto in cui il lavoro sta davvero.
Cinque eventi vanno trattati, ciascuno con un comportamento preciso.
- Il pagamento di scadenza riuscito. Crea l’ordine in PrestaShop, decrementa la giacenza, attiva l’email di conferma.
- Il pagamento fallito. Non crea ordine, mette l’abbonamento in attesa, avvia la sequenza di sollecito.
- L’abbonamento aggiornato. Cambio di piano, di quantità, di data. Deve ripercuotersi lato negozio.
- L’abbonamento annullato. Taglia l’accesso se vendete contenuti, ferma le spedizioni se vendete prodotti fisici.
- Il metodo di pagamento in scadenza. Attiva un sollecito prima del fallimento, evitando l’interruzione.
Tre regole tecniche sui webhook. Verificate la firma di ogni notifica, altrimenti chiunque può creare ordini da voi. Trattateli in modo idempotente: lo stesso evento può essere consegnato più volte, e non dovete creare due ordini. E rispondete rapidamente accusando ricezione, poi elaborate in background, altrimenti la piattaforma considera la chiamata fallita e la ripete.
DataFirefly Subscriptions — Abbonamenti e pagamenti ricorrenti Stripe per PrestaShop 8 e 9Il modulo abbonamenti per PrestaShop 8 e 9: Stripe card-on-file, dunning, area cliente self-service.€169.00
Le carte scadute, prima voce di perdita
Su un abbonamento, la maggior parte delle disdette subite viene da un metodo di pagamento diventato non valido, non da una decisione del cliente.
Tre meccanismi si sommano per limitare i danni. L’aggiornamento automatico delle carte, offerto dai circuiti e trasmesso dalle piattaforme di pagamento, che recupera il nuovo numero senza intervento. Il sollecito prima della scadenza, attivato un mese prima della data di fine validità. E la sequenza di ritentativo dopo un fallimento, distribuita su una o due settimane invece che ripetuta il giorno dopo.
Prevedete un periodo di tolleranza durante il quale il servizio resta attivo malgrado il fallimento. Tagliare subito trasforma un incidente bancario in una disdetta definitiva.
Il funnel: non mescolare
Questione di progettazione spesso risolta troppo tardi. Un carrello che contiene un abbonamento e prodotti in acquisto singolo pone un problema: il primo crea un impegno ricorrente, i secondi no.
Due approcci accettabili. Il funnel dedicato, dove l’abbonamento si sottoscrive da solo, senza possibilità di aggiungere altro. Più semplice, più chiaro per il cliente, ed è la scelta predefinita consigliata.
Oppure il carrello misto, dove l’ordine iniziale contiene entrambi, con un pagamento unico che copre i prodotti e avvia l’abbonamento. Tecnicamente più pesante, e bisogna essere molto chiari su ciò che sarà addebitato in seguito.
Ciò che non bisogna fare: lasciare due abbonamenti diversi nello stesso carrello. I cicli di fatturazione divergono subito e la gestione diventa inestricabile.
L’autenticazione forte
La normativa europea sui pagamenti impone un’autenticazione del titolare per numerose transazioni. Su un abbonamento, il primo pagamento è autenticato dal cliente, i successivi rientrano in un quadro diverso poiché sono avviati dall’esercente.
Due conseguenze pratiche. Il mandato deve essere registrato correttamente al primo pagamento, cosa che le piattaforme gestiscono a condizione che l’intento di pagamento sia creato con i parametri giusti. E alcune scadenze possono comunque esigere un’autenticazione, il che presuppone un percorso previsto per riportare il cliente a una pagina di autenticazione, invece di un fallimento silenzioso.
Il quadro legale
Tre obblighi, controllati e regolarmente mancati.
L’informazione prima della sottoscrizione: durata, importo, periodicità e modalità di disdetta devono essere visibili sulla pagina d’acquisto, non solo nelle condizioni generali.
La disdetta online, semplice quanto la sottoscrizione, accessibile dall’area cliente senza dover scrivere né telefonare.
L’informazione prima del rinnovo per gli abbonamenti a rinnovo tacito, con un preavviso che lasci al cliente il tempo di rifiutare.
Le tre cifre del modello
Il ricavo ricorrente mensile, che dà la base economica. Il tasso di abbandono mensile, distinguendo le disdette volontarie dai fallimenti di pagamento, perché i rimedi differiscono. E la durata di vita media di un abbonato, che discende dal secondo e che determina quanto potete spendere per acquisirne uno.
Il modulo DataFirefly Subscriptions per PrestaShop mette in opera questa architettura su PrestaShop 8 e 9: abbonamenti appoggiati a Stripe, creazione automatica degli ordini a ogni scadenza, trattamento dei webhook con verifica della firma, gestione dei fallimenti di pagamento e area cliente per modificare o disdire.