Il one page checkout entra in PrestaShop 9.2: il modulo a pagamento serve ancora?

Il one page checkout su PrestaShop c’era già: nella 1.6 bastava scegliere, nelle preferenze degli ordini, il processo in una pagina al posto di quello a cinque passaggi (il controller era OrderOpcController). La 1.7 l’ha tolto e da lì il checkout in una pagina è diventato un modulo di terze parti. Con la 9.2 torna nel pacchetto, gratis, come modulo nativo che si accende dal back office.

Il modulo a pagamento serve ancora? Dipende dal tema: su Hummingbird il nativo basta per un checkout da ospite pulito, sul Classic si attiva e rompe il checkout. E la 9.2 oggi è ancora una release candidate.

Non mi sono fidato dei comunicati: il 26 settembre ho installato la 9.2.0-rc.1 in locale e ho fatto ordini veri, da ospite e con account, con Hummingbird e con il tema Classic.

In breve, prima dei dettagli:

✅ Cosa porta PrestaShop 9.2 nel checkout

Il checkout nativo è il modulo ps_onepagecheckout, alla versione 0.6.7 nella rc.1: incluso nel pacchetto ma separato dal core, così si aggiorna senza aspettare una release di PrestaShop. Dopo l’installazione è spento e resta il checkout a quattro passaggi.

Si accende da Design > Processo di acquisto (nei comunicati in inglese è Design > Checkout): due opzioni, “Checkout rapido” e “Four-page checkout”. Si torna indietro dalla stessa schermata, senza disinstallare niente. In multistore la scelta vale per singolo negozio.

La schermata che sceglie il tipo di checkout nella 9.2.0-rc.1 installata in locale. Il menu è in italiano, le descrizioni delle due opzioni ancora in inglese.

Quello che fa, secondo l’annuncio ufficiale e secondo quello che ho visto:

• ospite dalla sola email: il cliente scrive l’indirizzo email e il resto viene chiesto per gradi, sulla stessa pagina;
• contatto, indirizzo, corriere e pagamento in un’unica pagina, con le sezioni che si aggiornano via AJAX: cambi indirizzo e si ricalcolano i corrieri, cambi corriere e si ricalcolano i pagamenti;
• carrelli di soli prodotti virtuali senza indirizzo di spedizione né corriere;
• login e registrazione fuori dal flusso: chi ha un account esce dal checkout per accedere e poi ci rientra;
• recupero dei carrelli abbandonati preservato, perché il minimo indispensabile viene registrato in background appena c’è l’email.

PrestaShop dichiara che il checkout in una pagina riduce l’attrito. Dati di conversione pubblicati non ce ne sono, e non li invento io.

⚠️ Le condizioni che nei comunicati si leggono poco

Ognuna di queste condizioni, da sola, basta a cambiare la risposta per il tuo shop.

Esiste solo dalla 9.2. Su una 8.x o una 9.1 non c’è, e non arriva con un aggiornamento del modulo.

La 9.2 oggi è una release candidate. La rc.1 è uscita il 21 settembre 2026, la stable non ha una data: la roadmap la collocava nel “Q2-Q3 2026” e il 26 settembre la milestone 9.2.0 contava ancora 510 issue aperte. E dalla RC alla versione finale non si aggiorna con l’Update Assistant: serve un’installazione pulita.

Il modulo stesso si dichiara non pronto. Il README del repository dice che è “under heavy development” e “not production-ready”, da non usare in ambienti live.

Il tema conta più di tutto. Sui temi costruiti da Hummingbird funziona subito; il Classic e i suoi derivati “non sono supportati di default” e richiedono override dei template. Derivati dal Classic sono quasi tutti i temi che vedo sugli shop nati sulla 1.7 e sulla 8.

Nativo e modulo di terze parti non convivono. Almeno un produttore dichiara che il suo modulo e quello nativo usano lo stesso punto di aggancio della 9.2: solo uno dei due può servire il checkout.

I moduli di pagamento vanno verificati uno per uno. Con le sezioni che si ricaricano via AJAX, un modulo che inietta contenuto deve saperlo ridisegnare dopo ogni aggiornamento, e il registro delle decisioni del modulo documenta fix recenti proprio lì. È il fronte caldo, lo stesso tipo di problema che racconto nel caso del metodo di pagamento che sparisce senza errore.

🛠️ L’ho installata in locale: cosa ho visto

PHP 8.4, MariaDB 11.4 dedicato, pacchetto ufficiale della rc.1: installazione da riga di comando in 127 secondi, 319 tabelle, 725 MB su disco. Un avvertimento: back office e database dicono “9.2.0”, non “rc.1”. A colpo d’occhio, uno shop installato con la release candidate sembra la stable.

Checkout da ospite su Hummingbird

Ordine da ospite pagato con bonifico, strumenti di sviluppo aperti: ordine confermato, zero ricaricamenti di pagina, 5 chiamate AJAX, zero errori JavaScript.

Il checkout da ospite su Hummingbird, dall’email al bottone di conferma su una pagina sola (tolta la fascia dell’header fisso). Restano stringhe in inglese, come “Continue as guest”.

Il carrello abbandonato: con la sola email inserita, il back office crea un cliente ospite “Guest Guest” legato al carrello, visibile in Clienti > Carrelli. Il recupero ha qualcosa su cui lavorare anche se il cliente si ferma al primo campo.

Checkout con account

Il login è davvero fuori dal flusso: dal checkout si esce su /login?back=/ordine, si accede e si rientra. Funziona, ma se vendi soprattutto a clienti abituali guardalo con i loro occhi. Dentro, il cambio fra indirizzi salvati avviene senza ricaricare e l’ordine in contrassegno è andato a buon fine.

Una cosa la segnalo come da verificare, non come bug: dopo il cambio di indirizzo, la richiesta che ricalcola i corrieri portava ancora paese, CAP e città dell’indirizzo precedente. L’esito mostrato era corretto, quindi può essere innocuo; su uno shop con tariffe per zona è la prima cosa che controllerei.

Con il tema Classic: si attiva e rompe il checkout

Il Classic è nel pacchetto (versione 3.1.2): l’ho attivato e ho acceso il checkout nativo. Il pannello avvisa che serve un tema compatibile con Bootstrap 5 e che con il Classic il layout “will break your storefront”. Poi ti lascia salvare lo stesso.

L’avviso che compare attivando il checkout in una pagina. Il bottone “Change checkout appearance” resta cliccabile anche con il Classic attivo.

Senza override, la pagina del checkout sul Classic mostra una riga sola: “Hello world! This is HTML5 Boilerplate.” Nessun campo, nessun modo di ordinare.

Il checkout del Classic con il modulo nativo acceso e nessun template sovrascritto.

Ho seguito la strada della documentazione per chi sviluppa temi, col minimo indispensabile: due override. Il checkout.tpl del modulo copiato nel tema, con il blocco content_columns rinominato in content (quello che il Classic sa riempire), e modal-terms.tpl copiato da Hummingbird, senza il quale il checkout va in errore 500 di Smarty.

Con quei due file l’ordine va a buon fine. Il layout no: la griglia non viene applicata, i corrieri escono senza stile, la scritta “Loading payment methods” resta a schermo anche a pagamenti caricati, gli asterischi dei campi obbligatori spariscono.

Lo stesso checkout con i due override: funziona, ma senza il CSS pensato per Hummingbird non è presentabile a un cliente.

Sul Classic non è un interruttore: è sviluppo su un modulo 0.x.
Due override per far passare l’ordine, e il layout resta tutto da scrivere.

I moduli di pagamento

Il verdetto vale per questi moduli, su questa versione:

Su PayPal, Stripe, Satispay, Scalapay e gli altri non dico niente: non li ho provati. Con un indirizzo francese non compariva nessun pagamento, ma per le restrizioni per paese dei moduli (Italia e Stati Uniti): se in staging i pagamenti spariscono, controlla quelle prima di accusare il checkout.

✅ Modulo nativo o modulo a pagamento: il confronto

Ho letto le pagine pubbliche di due dei moduli one page checkout a pagamento più diffusi. Quello che segue, per la colonna dei moduli, è dichiarato dai produttori, non verificato da me: sono moduli chiusi e non ne ho ispezionato il codice, quindi non ne consiglio nessuno.

130 EUR non sono il problema di nessuno shop che fattura. La domanda giusta è chi ti risponde quando un aggiornamento del modulo di pagamento rompe il checkout.

✅ Quando il modulo a pagamento conviene ancora

Conviene ancora, e parecchio, in questi casi:

• sei su una 8.x e quest’anno non migri: il nativo per te non esiste;
• usi il Classic o un tema derivato, cioè la maggioranza degli shop nati sulla 1.7 o sulla 8: finché non cambi tema, un modulo di terze parti è l’unica strada già pronta;
• ti servono campi extra in checkout, social login o un layout diverso da quello unico del nativo;
• hai già un one page checkout che funziona: non toglierlo per il nativo prima di averlo provato in staging, sulla stable, con i tuoi moduli di pagamento.

Non conviene se stai rifacendo lo shop sulla 9.x con Hummingbird: lì il nativo, una volta stabile, con buona probabilità basta per un checkout standard, e un modulo in più è solo codice in più da tenere compatibile.

🛠️ Non solo checkout: cosa cambia in SERP con la 9.2

La parte della 9.2 di cui si parla meno è la SEO tecnica. I dati strutturati adesso li costruisce il core come JSON-LD, che il tema stampa e i moduli possono estendere. Ho confrontato la scheda prodotto della rc.1 con Hummingbird con la stessa scheda sulla demo pubblica della 8.2 (ps8.2.demopresta.it) e su uno shop 8.2 reale che seguo.

Cosa guadagna la 9.2: un nodo WebSite con SearchAction (il box di ricerca interna), un nodo Organization con email e indirizzo del negozio, le caratteristiche del prodotto come additionalProperty e più immagini. Cosa perde: il campo mpn, presente nelle 8.2 di riferimento e assente nella rc.1. La condizione del prodotto (itemCondition) non c’è né in una né nell’altra, anche se la 9.2 aggiunge nuovi stati come open_box e damaged.

L’altro cambiamento che ho misurato è l’hreflang sulle categorie paginate. Sulla rc.1, con italiano e inglese attivi, la pagina ?page=2 di una categoria ha canonical e alternate che mantengono ?page=2, su entrambi i temi. Nella 8.2.8 e nella 9.1.5 gli alternate puntano alla pagina 1: questo lo ricavo dal codice modificato dalla PR, non da una misura, perché gli shop 8.x di riferimento erano monolingua.

Le PR del changelog che contano per la SEO:

Un dettaglio da staging, non da changelog: un URL di categoria con lo slug sbagliato fa un 302 verso quello giusto, ma perde ?page=2 per strada.

⚠️ Ask AI ed Extra Properties: utili, ma non sono il motivo per aggiornare oggi

Ask AI è l’assistente nel back office basato sul server MCP di PrestaShop: risponde sui dati dello shop ed esegue azioni in linguaggio naturale, chiedendo approvazione prima di agire. Nella rc.1 (ps_ask_ai 2.0.0) i provider sono Gemini, Anthropic, OpenAI e Mistral. Prima va verificato il negozio con PrestaShop Account, poi ci metti la tua chiave API: l’assistente è nel pacchetto, il consumo del provider lo paghi tu.

La configurazione di Ask AI: prima la verifica del negozio, poi provider e chiave API.

Extra Properties sono campi personalizzati nativi su prodotto, combinazione, cliente, ordine e carrello, da Parametri avanzati > Proprietà aggiuntive: otto tipi di campo, comuni, per lingua o per negozio, senza override. Utilissimi per chi integra un gestionale, ma il codice è marcato come sperimentale: da tenere d’occhio, non da usarci sopra un’integrazione oggi.

⚠️ Cosa non farei ancora in produzione

Perché oggi la risposta è “non ancora”:

• la rc.1 non si aggiorna alla stable con l’Update Assistant: uno shop vero installato adesso va reinstallato dopo;
• il modulo è alla 0.6.7 e si dichiara non pronto per la produzione;
• nel checkout e nel back office in italiano restano stringhe in inglese (“Delivery method”, “Continue as guest”), che un cliente vede;
• all’installazione il log ha registrato 15 errori di un modulo di spedizione incluso;
• c’è il comportamento sulla richiesta dei corrieri dopo il cambio indirizzo, da verificare.

Niente di grave per una release candidate: una RC serve proprio a questo. Diventa grave se finisce su uno shop che vende.

✅ Quando conviene aggiornare, versione per versione

• Sei su 1.6 o 1.7: la 9.2 non è il tuo problema adesso. Il passo è una versione supportata, e come lo affronto l’ho scritto nella guida su come aggiornare PrestaShop dalla 1.7 alla 8.
• Sei su 8.x: resta dove sei. Se il checkout ti fa perdere ordini adesso, un modulo di terze parti risolve oggi, sul tema che hai; la 9.2 si pianifica dopo la stable, insieme alla decisione sul tema.
• Sei su 9.1: la 9.1.5 è l’ultima release pianificata della linea. Prova la rc in staging con i tuoi moduli di pagamento e spedizione, aggiorna solo alla stable.
• Stai rifacendo lo shop sulla 9 con Hummingbird: parti con il checkout nativo in staging e decidi dopo la stable se ti basta.

Prima di aggiornare guardo anche i moduli che non incassano: spedizione, collegamento al gestionale, recensioni. Il controllo che faccio, modulo per modulo:

• una copia dello shop in staging, con gli stessi moduli e la stessa configurazione;
• il changelog del modulo, cercando una menzione esplicita della 9.2 e del one page checkout;
• la versione di PrestaShop dichiarata sulla scheda Addons o sul sito del produttore, sapendo che una dichiarazione non è una prova;
• gli hook che usa: se inietta contenuto nelle sezioni di indirizzo, corriere o pagamento, va riprovato col nativo, che quelle sezioni le ricarica via AJAX.

Nessuna di queste verifiche garantisce che il modulo funzioni: dicono dove guardare per primo in staging.

✅ Prima di comprare un modulo o di aggiornare

Il checkout in una pagina nativo è una buona notizia e, sui temi giusti, potrà far risparmiare un modulo a parecchi negozi. Non è ancora da produzione, e sul Classic non è una scelta affatto. La decisione giusta la prendi con davanti la tua versione, il tuo tema e i tuoi moduli di pagamento, ed è il tipo di verifica che faccio come tecnico PrestaShop prima che un cliente spenda o aggiorni. Raccontami da che versione parti e che tema usi da uno dei canali qui sotto.

Fonti primarie: release 9.2.0-rc.1 su GitHub, annuncio della rc.1, presentazione del one page checkout sul blog build, documentazione per chi sviluppa temi, modifiche della 9.2 nella devdocs, README di ps_onepagecheckout, registro delle decisioni del modulo, annuncio della beta.1, roadmap di PrestaShop, issue di rilascio della 9.2.0, Core Monthly di agosto 2026, devdocs sui temi figli, OrderOpcController della 1.6. Screenshot e misure vengono dalla 9.2.0-rc.1 installata in locale il 26 settembre 2026; prezzi e funzioni dei moduli a pagamento sono quelli dichiarati dai produttori sulle loro pagine.