Abbiamo testato il One Page Checkout nativo di PrestaShop 9.2: cosa funziona, cosa no e quando serve di piu

Testato a luglio 2026 su PrestaShop 9.2.0 beta 1.

PrestaShop 9.2 include un One Page Checkout nativo. Per chiunque gestisca un negozio, questo trasforma una vecchia certezza in una domanda concreta: se il checkout è ormai integrato, serve ancora un modulo di checkout?

Non volevamo rispondere partendo dalle note di rilascio. Abbiamo quindi installato la beta 9.2 in un container pulito, attivato il one page checkout nativo e percorso l'intero flusso con un browser guidato da script, registrando ogni navigazione, ogni script, ogni richiesta XHR e documento (le risorse statiche come immagini e font sono state escluse dal log) insieme ai tempi. Questo articolo riporta ciò che gli strumenti hanno realmente misurato.

Il punto principale prima dei dettagli: è migliore di quanto ci aspettassimo. Siamo partiti con un sospetto preciso, ovvero che inserire un indirizzo avrebbe forzato silenziosamente dei ricaricamenti di pagina e che il "one page" sarebbe stato vero solo sulla carta. Quel sospetto era sbagliato, e lo diciamo per primo perché era proprio la cosa che più ci aspettavamo di trovare.

Non è perfetto, ma le imperfezioni sono più piccole di quanto avevamo riferito all'inizio. Due dei nostri rilievi originali si sono rivelati difetti del nostro stesso script di test, e li ritiriamo qui sotto invece di lasciarli in piedi. Restano una richiesta duplicata, alcuni attributi di form mancanti, un problema di layout mobile e una scelta progettuale deliberata che toglie qualcosa che il vecchio checkout sapeva fare.

Prima di tutto: il nostro conflitto di interessi

Vendiamo moduli di checkout per PrestaShop. Un checkout nativo nel core è, commercialmente, un concorrente per noi. Leggete quindi tutto ciò che ne diciamo tenendolo presente.

Ecco come lo abbiamo gestito, in modo che possiate verificare il nostro lavoro invece di fidarvi delle nostre intenzioni. Ogni affermazione qui sotto è un numero che abbiamo registrato o uno screenshot che abbiamo scattato, su un'installazione che chiunque può riprodurre da un'immagine Docker pubblica. Dove ci aspettavamo un difetto e non lo abbiamo trovato, lo diciamo. Dove la nostra prima lettura era sbagliata, l'abbiamo corretta invece di tenere la versione che ci faceva comodo: all'inizio pensavamo che al nuovo checkout mancassero i codici sconto, e non è vero. I passaggi di installazione, le versioni esatte e tutto ciò che non abbiamo potuto testare sono elencati. Se una misura non si riproduce da voi, ditecelo e andremo a fondo.

Cosa abbiamo testato, esattamente

Ogni numero qui sotto viene da questo ambiente. Se qualcosa non si riproduce da voi, può dipendere dalla vostra versione, dalla vostra configurazione o dal nostro metodo, e preferiamo saperlo.

Due note sull'installazione servono per onestà. Primo, l'installazione predefinita non aveva alcun corriere che servisse il paese stesso del negozio, perché il Regno Unito si trova nella zona "Europa (non UE)" mentre i corrieri di esempio coprono solo due altre zone. Abbiamo assegnato i corrieri a quella zona, che è normale configurazione da commerciante e non un problema del checkout. Secondo, i tempi provengono da una rete locale: consideratelo un confronto tra i due checkout su hardware identico, non valori che il vostro negozio riprodurrà.

Cos'è davvero l'OPC nativo di 9.2

Arriva come modulo, ps_onepagecheckout, incluso nel pacchetto 9.2. Due dettagli che abbiamo confermato in fase di installazione vale la pena conoscerli prima di pianificare qualsiasi cosa:

• È disattivato di default. Dopo un'installazione pulita di 9.2 il modulo è presente e abilitato, ma l'impostazione PS_ONE_PAGE_CHECKOUT_ENABLED vale 0. Lo si attiva da Design > Checkout nel back office e si può tornare al classico checkout in quattro pagine quando si vuole.
• O 9.2 o niente. Il modulo dichiara ps_versions_compliancy con un minimo di 9.2.0. Un negozio su 1.7, 8.x, 9.0 o 9.1 non può installarlo.

Dal punto di vista architetturale fa quello che descrive l'annuncio ufficiale sul blog build di PrestaShop. Inietta il proprio processo di checkout tramite un hook del core invece di sovrascrivere il controller degli ordini, e sostituisce le quattro classi di step con un unico step combinato. Login e creazione account sono stati deliberatamente spostati fuori dal checkout su pagine dedicate. Avevamo trattato il progetto prima del rilascio in cosa dovrebbero sapere commercianti e sviluppatori sull'OPC nativo di 9.2. Questo articolo sostituisce quelle supposizioni con misurazioni.

Il benchmark

Il one page checkout nativo di 9.2 con l'indirizzo compilato. Metodo di spedizione, metodo di pagamento, termini e pulsante di pagamento sono tutti sulla stessa schermata, e il riepilogo a destra si aggiorna in tempo reale.

Stesso negozio, stesso prodotto, stessi valori di indirizzo, stessi corrieri, ogni volta in un carrello nuovo. I due percorsi erano equivalenti ma non identici azione per azione, perché i due checkout non offrono le stesse azioni. I "caricamenti di pagina completi" contano le navigazioni del frame principale dall'apertura del checkout fino alla conferma d'ordine.

Lo stesso negozio con il one page checkout disattivato. Tre dei quattro passaggi non sono raggiungibili finché il precedente non è completato, e ogni passaggio completato costa un caricamento di pagina completo.

Valutate questo scambio onestamente, e tenete conto della dimensione del campione. Sono cinque esecuzioni su rete locale, quindi puramente descrittive. In particolare lo scarto sul primo rendering rientra nella dispersione tra esecuzioni (one page checkout da 152 a 180 ms, classico da 148 a 188 ms) e non lo presenteremmo come una differenza reale. Lo scarto su DOMContentLoaded e i conteggi di byte erano invece costanti in tutte le esecuzioni. Il one page checkout impiega circa 50 ms in più per arrivare a DOMContentLoaded e porta all'incirca 28 KB di JavaScript in più, perché rende contatto, indirizzo, spedizione, pagamento e riepilogo in un unico documento invece che un passaggio alla volta. In cambio elimina dal percorso tre caricamenti di pagina completi. Su qualsiasi connessione reale, tre round trip verso il server in meno battono comodamente 50 ms di rendering locale.

Dove è morta l'ipotesi sull'indirizzo

Era esattamente ciò che volevamo cogliere in fallo, ecco quindi il dettaglio grezzo per azione. Ognuna è stata registrata con il log di rete del browser.

Aggiungere un indirizzo non ricarica la pagina. Modificarne uno non ricarica la pagina. Cambiare paese non ricarica la pagina: ricostruisce il form dell'indirizzo via AJAX, perché cambiano i campi obbligatori e il comportamento fiscale. Il cambio di corriere ha aggiornato il totale in tempo reale, da 19,12 EUR a 26,12 EUR, senza alcuna navigazione.

Anche la logica di aggiornamento è più accurata di quanto pensassimo. Modificare la via, che non può cambiare un prezzo di spedizione, ha generato una singola richiesta di salvataggio bozza e nulla più. Corrieri e opzioni di pagamento venivano richiesti di nuovo solo quando cambiava qualcosa che li riguarda davvero, come il paese o l'indirizzo completato. È un comportamento sensato, con una riserva: i nostri corrieri di esempio erano a tariffa fissa, quindi un cambio di CAP non poteva comunque alterare il prezzo. Un corriere che tariffa per CAP richiederebbe un test a sé, perché qui sia una modifica della via sia una del CAP hanno prodotto solo un salvataggio bozza.

Cosa fa bene

Riconoscerlo correttamente conta, perché sono le parti che i commercianti percepiranno.

• È davvero una sola schermata. Contatto, indirizzo di spedizione, metodo di spedizione, pagamento, riepilogo e pulsante di pagamento sono tutti in un unico form già al primo rendering. Non c'è alcun blocco a passaggi e nulla è nascosto dietro un pulsante "continua".
• Gli stati di attesa si spiegano da soli. Finché l'indirizzo non è completo, i blocchi spedizione e pagamento non restano vuoti. Dicono "Completa sopra il tuo indirizzo di spedizione per vedere le opzioni di consegna" e poi elencano esattamente cosa manca: "Ancora necessari: Nome, Cognome, Indirizzo, Città, CAP". È un microtesto insolitamente chiaro per un checkout predefinito.
• La validazione inline blocca i dati errati senza ricaricare. Con la Francia selezionata (che definisce un formato di CAP), inserire ABC ha marcato il campo come non valido, mostrato "CAP non valido, dovrebbe essere come "NNNNN"", sostituito la lista corrieri con "Correggi i campi indirizzo evidenziati" e rifiutato l'invio. Cliccare su Paga ha prodotto zero richieste di rete e ha riportato il focus nel form. Nulla è andato perso e nulla è stato ricaricato. Nel test separato in cui abbiamo svuotato un campo Città obbligatorio, il browser ha messo il focus esattamente su quel campo all'invio.
• Il pulsante di pagamento resta onesto. Rimane disattivato finché manca un consenso obbligatorio, cosa che abbiamo registrato con un cliente di ritorno il cui corriere e pagamento erano già risolti ma con la casella dei termini non spuntata, e mostra il totale aggiornato su di sé. Non è però un indicatore completo di prontezza: con un campo Città obbligatorio svuotato è rimasto attivo, ed è stato il browser e non il checkout a bloccare l'invio ("Paga 19,12 EUR", poi "Paga 26,12 EUR" dopo aver scelto il corriere a pagamento).
• Gli indirizzi salvati si gestiscono senza lasciare la pagina. Per un cliente loggato la lista indirizzi propone "Usa un altro indirizzo di spedizione", e sia quella opzione sia il menu di modifica per ciascun indirizzo aprono una finestra modale sulla stessa schermata. Aggiungere e modificare un indirizzo durante il checkout non porta mai via dalla pagina.
• I codici promozionali sono supportati e ricalcolano in tempo reale. Il riepilogo contiene una fisarmonica "Codice promozionale" con un campo "Incolla qui il tuo buono". Applicare un codice ha ricalcolato sconto, corrieri e opzioni di pagamento via AJAX, senza alcun ricaricamento. Una cosa da sapere: il campo compare solo quando nel negozio esiste almeno una regola carrello, perché PrestaShop disattiva del tutto la funzione finché non ce n'è nessuna.
• I clienti di ritorno hanno un percorso davvero rapido. Effettuato l'accesso con un indirizzo salvato, il form del checkout è comparso in 193 ms, e la lista indirizzi, entrambi i corrieri e tutti e tre i metodi di pagamento si sono risolti poco dopo via AJAX, senza una singola interazione. Completare l'ordine ha richiesto due azioni: spuntare i termini, cliccare paga. Il campo e-mail sparisce del tutto per un cliente loggato, esattamente come descrive l'annuncio.
• Il layout mobile tiene. A 375 px non c'era alcun overflow orizzontale (larghezza documento 375 px, viewport 375 px), e il primo rendering di contenuto è avvenuto a 152 ms. Le righe dei corrieri e la riga dei termini hanno ampie aree toccabili (351x136 px e 327x48 px).

Un CAP francese non valido. Il campo viene segnalato inline, la lista dei corrieri è sostituita da un invito alla correzione, e cliccare su Paga non ha prodotto alcuna richiesta di rete.

Un cliente loggato ritrova i propri indirizzi salvati come schede selezionabili, con un menu per indirizzo e la possibilità di aggiungerne uno nuovo.

Aggiungere un indirizzo apre una modale sopra il checkout. La pagina sottostante non viene mai ricaricata e nulla di ciò che è già stato inserito va perso.

Anche la pagina di conferma ordine è stata rivista e appare decisamente più pulita di quella che sostituisce.

Le imperfezioni che abbiamo davvero misurato

Sono cose che possiamo dimostrare, non impressioni.

1. L'endpoint dei metodi di pagamento viene richiamato due volte

Ogni volta che l'indirizzo si risolve, il checkout richiede le sue opzioni di pagamento due volte con un URL identico byte per byte:

GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17
GET /module/ps_onepagecheckout/paymentmethods?ajax=1&action=opcPaymentMethods&id_country=17

Lo abbiamo registrato sei volte in quattro sessioni di browser indipendenti: al primo inserimento dell'indirizzo e a un cambio di paese nell'esecuzione ospite, nell'esecuzione mobile, in un'esecuzione con CAP non valido, e sia in un primo sia in un secondo checkout di un cliente loggato. Il caso del secondo checkout è il più eloquente, perché avviene al semplice caricamento della pagina, senza alcuna interazione da script. È una richiesta duplicata, non due stati diversi. In un negozio dove i moduli di pagamento fanno lavoro vero a ogni rendering (calcolo commissioni, regole di disponibilità, chiamate remote), è tempo server sprecato sulla pagina più critica per la conversione. È esattamente il genere di cosa che un modulo 0.6.2 ha ancora da sistemare.

2. Nessun suggerimento di compilazione automatica sui campi indirizzo

Abbiamo verificato ogni campo del blocco indirizzo di spedizione. Nessuno porta un attributo autocomplete, nessuno porta un inputmode:

La compilazione automatica degli indirizzi in browser e telefoni si basa proprio su questi token (given-name, address-line1, postal-code e così via). Senza di essi, l'unica cosa che elimina più digitazione su mobile funziona in modo inaffidabile, il che penalizza un checkout il cui obiettivo dichiarato è proprio l'attrito su mobile. Sappiamo che è una dimenticanza e non una scelta, perché la pagina di registrazione di 9.2 nello stesso tema imposta i token correttamente: email, given-name, family-name, new-password e tel-national. Il form indirizzo del checkout, che ne avrebbe più bisogno, non ne ha nessuno. Il telefono almeno usa type="tel", quindi quella tastiera è corretta.

3. Non si può creare un account mentre si ordina, ed è una regressione

Login e registrazione sono stati deliberatamente spostati fuori dal checkout, cosa che l'annuncio dice chiaramente. Vale la pena esplicitare cosa significhi in pratica, perché è un passo indietro rispetto al checkout che sostituisce.

Abbiamo confrontato i due checkout sullo stesso negozio. Il classico checkout in quattro passaggi rende un vero <input type="password" name="password"> dentro il checkout, quindi un acquirente può creare un account mentre ordina, e il suo "Accedi" è una scheda nella stessa pagina. Il one page checkout non ha alcun campo password da nessuna parte, ed entrambi i controlli sono normali link che portano via:

Un cliente che vuole acquistare e mantenere un account deve quindi lasciare il checkout, registrarsi su una pagina separata e tornare. Per un checkout pensato prima di tutto per gli ospiti è una decisione coerente, e chi compra come ospite non se ne accorge mai. Per un negozio che dipende dalle iscrizioni al momento dell'acquisto, toglie qualcosa che il vecchio checkout sapeva fare. Significa anche che il momento in cui un cliente è più motivato a registrarsi, subito dopo aver deciso di comprare, è l'unico momento in cui il checkout non glielo permette.

4. Su mobile il pulsante di pagamento è molto in basso

Il one page checkout a 375 px. Il layout regge senza overflow orizzontale, ma l'intero checkout è un'unica colonna molto alta.

Mettere tutto su una schermata rende quella schermata molto alta. Su un viewport da 375 px il pulsante di pagamento si trova 3337 px più in basso, e non è appiccicato: la sua posizione calcolata è static, senza antenati fixed o sticky. Anche un cliente di ritorno con indirizzo salvato deve scorrere tutto il form per raggiungerlo. Un riepilogo o una barra di pagamento sticky sono la risposta abituale, e ancora non ci sono.

5. È un modulo pre-1.0, e lo dice il suo stesso README

Non è un difetto, ma è il fatto più importante per pianificare. Il pacchetto beta testato include il modulo in versione 0.6.2, mentre upstream aveva già taggato la 0.6.5 pochi giorni prima del nostro test: trattate quindi i numeri di versione precisi come un bersaglio mobile. E l'annuncio della beta di PrestaShop è inequivocabile: "questa versione beta è software pre-rilascio. È possibile che incontriate dei problemi. Non usatela nel vostro negozio di produzione!" Inoltre non si può aggiornare una beta a release candidate o a stabile tramite il normale percorso di aggiornamento.

Il repository del modulo è ancora più diretto. Il README di PrestaShop/ps_onepagecheckout afferma: "Questo modulo è in sviluppo intenso. Non è pronto per la produzione e non dovrebbe essere usato in ambienti live." Al momento in cui scriviamo conta una manciata di issue aperte, e due coincidono esattamente con quanto abbiamo incontrato in modo indipendente: #94 segnala id di campo duplicati tra la modale indirizzo nascosta e il form inline, motivo per cui lo stesso id #field-postcode compare più di una volta nella pagina che abbiamo analizzato, e #102 descrive la pila di caselle di consenso che mette il blocco più pesante sulla prima schermata, esattamente l'attrito che descriviamo più sotto. #132 riguarda il form indirizzo che ignora l'ordine dei campi specifico per paese, e #105 è una richiesta aperta di esporre un contratto per l'express checkout. Quest'ultima conta se vendete tramite wallet o pagamenti express, perché la superficie a cui si aggancerebbero è ancora in fase di progettazione.

6. Tre caselle di consenso obbligatorie separano il cliente dalle opzioni

In un'installazione 9.2 predefinita, chi compra per la prima volta come ospite incontra tre spunte obbligatorie: privacy dei dati cliente, la casella propria del modulo GDPR e i termini e condizioni. Per un ospite le prime due bloccano le opzioni di spedizione e pagamento, che restano dietro un messaggio "accetta i termini richiesti" finché non vengono spuntate. Per un cliente di ritorno è più leggero: abbiamo misurato le opzioni risolversi normalmente con la sola casella dei termini non spuntata, che blocca il pulsante di pagamento e non le opzioni. Quella pila è configurazione del vostro negozio e non colpa del checkout, ed è rimovibile, ma è ciò che un'installazione 9.2 nuova presenta a chi compra per la prima volta. PrestaShop ha una issue aperta esattamente su questo, la #102.

Una correzione: due rilievi ritirati

Una versione precedente di questo articolo conteneva altri due rilievi. Entrambi erano sbagliati, ed entrambi dipendevano da noi e non dal checkout. Li lasciamo a verbale invece di cancellarli in silenzio.

Avevamo riferito che applicare un codice sconto azzerava il metodo di spedizione del cliente e, separatamente, che il checkout poteva mostrare un corriere e un totale mentre il carrello salvato ne conteneva un altro. Entrambi nascevano dallo stesso errore: il nostro script selezionava il corriere in modo programmatico invece di cliccarlo, così la scelta non raggiungeva mai il server e ogni rendering successivo mostrava semplicemente la versione del server.

A chiarire la cosa è stato completare un ordine vero e poi leggere la riga nel database invece di fidarsi dello schermo:

Cliccato come farebbe una persona, l'ordine corrisponde allo schermo ogni volta, con e senza buono. I codici sconto funzionano correttamente: il campo compare non appena il negozio ha davvero una regola carrello, e applicarne uno ricalcola sconto, corrieri e opzioni di pagamento via AJAX senza ricaricare. Non avremmo dovuto pubblicare nessuna delle due affermazioni, e mettiamo a verbale la correzione perché un benchmark di cui non ci si può fidare che si corregga da solo non merita di essere letto.

Cosa non abbiamo potuto testare

Dirlo chiaramente è la differenza tra un benchmark e un'opinione.

• Gateway di pagamento reali. Abbiamo testato solo con metodi offline. Un gateway carte, un flusso wallet o un passaggio 3D Secure aggiungeranno ciascuno il proprio passaggio di consegne, che può essere un redirect, un popup o un frame incorporato. L'ultima navigazione misurata è stata il modulo assegno che passava alla sua pagina di validazione.
• Il tema classic. Abbiamo testato su hummingbird, il tema che 9.2 installa. L'annuncio ufficiale avverte che i temi classic non sono supportati di default e che "potrebbe essere necessario sovrascrivere alcuni template del modulo One Page Checkout per farlo funzionare". Non abbiamo completato un'installazione classic pulita e correttamente migrata, quindi su questo punto citiamo PrestaShop e non un nostro risultato.
• Carico e concorrenza. Misurazioni con un solo browser su rete locale. Nulla qui dice come si comportino gli endpoint AJAX aggiuntivi sotto traffico reale.
• Moduli di checkout di terze parti. Non abbiamo testato come i moduli esistenti di corriere, commissioni o upsell vengano resi nel flusso one page. È la cosa più importante da verificare sulla vostra copia di staging.

Riproducetelo voi stessi

Nulla di tutto ciò vale molto se non potete verificarlo. L'intero banco di prova è un'immagine pubblica e circa dieci minuti di configurazione. Questa è una versione ridotta del file compose che abbiamo usato (aggiungete le solite MYSQL_* e le corrispondenti DB_*, e puntate il dominio dove lo eseguite):

services:
  prestashop:
    image: prestashop/prestashop:9.2.0-6.0-beta.1-classic-apache
    ports: ["8088:80"]
    environment:
      DB_SERVER: ps92-db
      PS_INSTALL_AUTO: 1
      PS_DEV_MODE: 0          # lasciatelo DISATTIVATO o tutti i tempi sono falsati
      PS_DOMAIN: localhost:8088
  ps92-db:
    image: mysql:8.0

Poi quattro cose che altrimenti vi costeranno il pomeriggio, perché sono costate il nostro:

• Attivate il checkout. Viene fornito installato ma disattivato. Design > Checkout, oppure impostate PS_ONE_PAGE_CHECKOUT_ENABLED a 1.
• Date ai corrieri la zona giusta. Un'installazione predefinita mette il Regno Unito in "Europa (non UE)" mentre i corrieri di esempio servono solo due altre zone, quindi un indirizzo britannico non mostra legittimamente alcun corriere. Sono dati di esempio, non un difetto del checkout, e per poco non lo abbiamo segnalato come tale.
• Testate la validazione del CAP con la Francia, non con il Regno Unito. PrestaShop fornisce per GB uno zip_code_format vuoto, quindi passa qualunque sciocchezza e il checkout sembra rotto pur non essendolo. La Francia definisce NNNNN e valida correttamente.
• Per riprodurre il caso del buono serve più del negozio predefinito. Il benchmark principale girava sui due corrieri di esempio, ma il test del buono richiede un corriere la cui perdita si noti: abbiamo aggiunto Standard Delivery a 4,90, Economy a 6,90 (gratis oltre 100) ed Express 24h a 12,90, ciascuno per tutte le zone, poi creato una regola carrello del 10% con il codice TEST10 e la spedizione gratuita disattivata. Scegliete il corriere più caro, applicate il codice, completate l'ordine e confrontate il metodo di spedizione dell'ordine finito con quello che avevate scelto. Un tranello: il campo del codice promozionale è invisibile finché non esiste almeno una regola carrello, perché PrestaShop porta PS_CART_RULE_FEATURE_ACTIVE a 0 in un negozio che non ne ha.

Per contare i ricaricamenti, aprite il pannello Rete, filtrate su Doc e osservate quante navigazioni del frame principale ottenete tra l'apertura del checkout e la pagina di conferma. Per la richiesta duplicata, filtrate su paymentmethods.

L'OPC nativo di 9.2 vi basta?

Sulla base di ciò che abbiamo misurato, ecco la divisione onesta.

L'OPC nativo basta davvero se

• State comunque passando a 9.2 e usate il tema hummingbird o un suo tema figlio.
• Il vostro checkout è standard: pochi corrieri, metodi di pagamento consueti, nessun campo personalizzato.
• Vendete a consumatori e l'ordine come ospite è la norma.
• Volete il flusso in quattro passaggi compresso e un totale aggiornato in tempo reale, che è esattamente ciò che offre, con zero ricaricamenti.
• Siete disposti ad aspettare la 9.2 stabile prima di attivarlo.

Per quel negozio la risposta è semplice: la piattaforma ora lo copre, e non dovreste comprare un modulo per fare ciò che fa il core. Se il vostro checkout oggi perde ordini e volete capire se è davvero lui il problema, partite da perché la pagina di checkout perde vendite e dai motivi per cui i clienti se ne vanno prima di pagare.

Sbatterete comunque contro un muro se

• Non siete su 9.2. È il punto duro. Il modulo si rifiuta di installarsi sotto la 9.2.0, e gli aggiornamenti che toccano il checkout sono esattamente quelli che i commercianti rimandano. Un negozio su 1.7, 8.x, 9.0 o 9.1 non ricava nulla da questa release.
• Volete che il passaggio di pagamento stesso sia un tocco solo. Il one page checkout rimuove l'attrito prima del pagamento. Non trasforma un gateway in un pulsante wallet. È un'altra funzionalità, trattata in checkout veloce e in checkout in un clic su PrestaShop.
• Il mobile è la maggior parte del vostro fatturato e vi serve una barra di pagamento sticky, oppure un form indirizzo che collabori con la compilazione automatica del telefono. Entrambe sono lacune misurate sopra.
• Volete che i clienti si registrino al momento dell'acquisto. Nel checkout non c'è un campo password, quindi creare un account significa uscirne.
• Vi servono regole del tipo "questo metodo di pagamento solo tra valore ordine X e Y". Questo tipo di logica condizionale su pagamenti e spedizioni non fa parte del modulo nativo.
• Vi servono campi personalizzati nel checkout, regole B2B, upsell a livello di ordine o selettori di data di consegna. Nulla di ciò rientra nell'ambito del modulo nativo.

Dove un modulo mantiene il suo posto

Vendiamo moduli di checkout, quindi trattate questo paragrafo con lo scetticismo che merita e confrontatelo con la tabella qui sopra. Le lacune che abbiamo effettivamente misurato sono più strette di un anno fa, e su un negozio 9.2 standard il checkout nativo ora fa bene il lavoro di base.

L'unica lacuna che non è questione di gusti è la copertura di versioni. L'OPC nativo parte da 9.2, come conferma la dichiarazione di compatibilità del modulo stesso. Il nostro Checkout Revolution esiste per portare un checkout in una pagina sulle versioni di PrestaShop che la maggior parte dei negozi live fa girare davvero oggi, senza toccare il core. Verificate sulla pagina prodotto l'esatto intervallo di versioni supportate, e tenete presente che non lo abbiamo ancora certificato sulla 9.2 stessa. La sua storia è in Checkout Revolution 3.0. Se invece volete comprimere il gesto di pagamento in sé anziché il form sopra, quello è Express Checkout, e resta rilevante qualunque checkout renda la pagina. Se state confrontando le strade, la guida all'ottimizzazione del checkout e la panoramica su processo e alternative le mettono in fila.

Se siete su 9.2 con un catalogo standard e un checkout standard, vi diremmo di usare quello nativo. È ciò che le misurazioni sostengono.

FAQ

Il one page checkout di PrestaShop 9.2 è abbastanza stabile per la produzione?

Non ancora, e PrestaShop lo dice due volte. L'annuncio della beta 9.2 precisa che è software pre-rilascio e sconsiglia ai commercianti di usarlo su un negozio di produzione, e il README del modulo dice: "Questo modulo è in sviluppo intenso. Non è pronto per la produzione e non dovrebbe essere usato in ambienti live." Il modulo stesso è alla versione 0.6.2. Ogni ordine che abbiamo effettuato corrispondeva a quanto il checkout aveva mostrato, ma un modulo pre-1.0 su una piattaforma in beta va comunque tenuto in staging finché 9.2 non sarà stabile. Inoltre non si può passare dalla beta alla release candidate o alla stabile tramite il percorso di aggiornamento standard, quindi testate su una copia usa e getta.

Funziona con il mio tema?

È costruito per hummingbird, il tema che il pacchetto 9.2 installa e quello su cui abbiamo testato, dove ha funzionato senza alcuna modifica. L'annuncio ufficiale di PrestaShop avverte che i temi classic non sono supportati di default e che potreste dover sovrascrivere alcuni template del modulo per farlo funzionare. Non abbiamo verificato noi stessi il caso del tema classic, quindi trattate il vostro tema come la prima cosa da testare in staging, soprattutto se sovrascrive template del checkout.

Mi serve ancora un modulo di checkout?

Se siete su 9.2, usate hummingbird o un tema figlio e avete un checkout convenzionale, allora onestamente no. Il modulo nativo comprime i quattro passaggi in una schermata, aggiorna i totali in tempo reale, valida inline e completa un ordine in due azioni per un cliente di ritorno. Un modulo dedicato lo vorrete comunque per ciò che dai nostri test non fa: funzionare su PrestaShop da 1.6 a 9.1, il pagamento wallet con un tocco, campi di checkout personalizzati o B2B, upsell a livello di ordine e rifiniture mobile come una barra di pagamento sticky.

Come lo attivo?

Andate su Design > Checkout nel back office e selezionate il layout one page checkout. Il modulo viene fornito installato con 9.2 ma l'impostazione è disattivata di default, quindi un'installazione nuova vi dà il classico checkout in quattro passaggi finché non lo attivate. Potete tornare indietro in qualsiasi momento, e in configurazione multinegozio la scelta si fa per negozio e non globalmente.

I clienti possono usare codici sconto nel one page checkout?

Sì. Il riepilogo ordine include una fisarmonica "Codice promozionale" con un campo, e applicare un codice ricalcola sconto, corrieri e opzioni di pagamento via AJAX senza ricaricare la pagina. Inizialmente avevamo riferito che applicare un codice azzera il corriere scelto dal cliente. Era il nostro script di test che selezionava il corriere in modo programmatico invece di cliccarlo, e abbiamo ritirato quell'affermazione: guidato da clic reali, l'ordine finale corrispondeva ogni volta al metodo di spedizione scelto, con e senza buono. L'unica vera particolarità è che il campo del codice resta nascosto finché il negozio non ha almeno una regola carrello, perché PrestaShop altrimenti disattiva del tutto la funzione.

One page checkout significa nessun redirect?

No, ed è il fraintendimento più comune. Su tutto il percorso abbiamo misurato due caricamenti di pagina completi: l'apertura del checkout e il passaggio di consegne del modulo di pagamento dopo l'invio. Tutto quello in mezzo, compresi inserire un indirizzo, modificarlo, cambiare paese, cambiare corriere e scegliere un metodo di pagamento, è avvenuto senza un solo ricaricamento. Ma un metodo di pagamento reale può ancora passare a una pagina ospitata, a una sfida 3D Secure, a un popup o a un frame incorporato. Abbiamo misurato solo il passaggio del modulo assegno offline, e quel tipo di passaggio è normale comportamento e-commerce, non un difetto del checkout.

I miei moduli di pagamento e spedizione esistenti continueranno a funzionare?

Per progettazione dovrebbero, perché il checkout nativo usa il normale meccanismo PrestaShop di rilevamento delle opzioni di pagamento invece di aggirarlo, e i nostri tre metodi offline sono comparsi e hanno funzionato senza modifiche. La riserva è che ora tutto viene reso contemporaneamente su una sola schermata, quindi i moduli corriere che reagiscono ai cambi di indirizzo in tempo reale e i moduli di pagamento resi in un contesto a pagina singola sono esattamente i punti in cui le assunzioni del flusso a passaggi possono rompersi. Notate anche che l'endpoint delle opzioni di pagamento viene attualmente richiamato due volte per ogni cambio di indirizzo, il che conta se i vostri moduli di pagamento svolgono lavoro costoso a ogni rendering.

Fonti e metodo di test

Fonti primarie, tutte pubbliche:

• Introducing One Page Checkout in PrestaShop 9.2, l'annuncio ufficiale sul blog build di PrestaShop.
• PrestaShop 9.2 Beta is open for feedback, che riporta l'avviso di pre-rilascio citato sopra.
• PrestaShop/ps_onepagecheckout su GitHub, il codice sorgente del modulo, il suo README e l'elenco delle issue aperte.

Metodo. Un'installazione pulita di PrestaShop 9.2.0 beta 1 dall'immagine Docker ufficiale, tema hummingbird, modalità debug disattivata e cache di produzione calda. Il percorso ospite, il percorso del cliente di ritorno e il confronto con il classico checkout in quattro passaggi sono stati guidati ciascuno da un browser via script che registrava navigazioni e richieste XHR, fetch e documento, escluse le risorse statiche, con le navigazioni del frame principale contate separatamente dalle chiamate AJAX. I tempi di caricamento sono la mediana di cinque esecuzioni, con la cache HTTP svuotata prima di ognuna. Due rilievi di una versione precedente di questo articolo sono stati ritirati dopo averli ricondotti al nostro stesso script che selezionava il corriere in modo programmatico invece di cliccarlo; ogni ordine effettuato con clic reali corrispondeva a quanto mostrato dal checkout, verificato sulla riga dell'ordine nel database. Le catture automatiche hanno usato viewport CSS da 1440 px e 375 px; le immagini pubblicate sono state ritagliate o ridimensionate per la presentazione, ma il loro contenuto non è ritoccato.

Datato e provvisorio. Queste misurazioni descrivono PrestaShop 9.2.0 beta 1 con ps_onepagecheckout 0.6.2, testato il 27 luglio 2026. È software pre-rilascio in sviluppo attivo, quindi i difetti descritti potrebbero benissimo essere corretti quando 9.2 sarà stabile, e potrebbero comparirne di nuovi. Intendiamo rieseguire esattamente questo benchmark alla release candidate e di nuovo alla versione stabile, e aggiornare questo articolo con i nuovi numeri invece di lasciare in silenzio i vecchi. Se riproducete qualcosa di diverso, ditecelo e correggeremo.