One Page Checkout nativo di PrestaShop 9.2: cosa fa e quando ti serve di più

Come funziona

• È un modulo separato. Il checkout arriva con la 9.2 come ps_onepagecheckout e può essere aggiornato indipendentemente da PrestaShop stesso, quindi controlla sul tuo negozio sia la versione del core sia quella del modulo.
• È spento finché non lo attivi. Una nuova installazione della 9.2 mantiene il classico checkout in quattro passaggi. Scegli il layout in una pagina in Design > Checkout e puoi tornare indietro in qualsiasi momento.
• Richiede la 9.2. Il modulo dichiara PrestaShop 9.2.0 come minimo. I negozi su 1.7, 8, 9.0 o 9.1 non possono installarlo.
• Si aggancia al core, non lo aggira. Il modulo fornisce il proprio processo di checkout tramite l'hook actionCheckoutBuildProcess invece di fare l'override del controller dell'ordine, e sostituisce le quattro classi dei passaggi (informazioni personali, indirizzi, spedizione, pagamento) con un unico passaggio combinato.
• La pagina si aggiorna per sezioni. Un cliente ospite viene creato non appena email e consensi obbligatori sono validi, il form dell'indirizzo viene ricostruito quando cambia il paese, e corrieri e opzioni di pagamento si aggiornano man mano che l'indirizzo viene completato. Le opzioni di pagamento arrivano ancora dal meccanismo standard di PrestaShop per rilevare le opzioni di pagamento.
• Login e registrazione hanno pagine proprie. Il checkout classico permette all'acquirente di impostare una password e creare un account mentre ordina. Il One Page Checkout rimanda invece alle pagine separate di login e registrazione. Chi acquista come ospite non se ne accorgerà; un negozio che conta sulla creazione di account al momento dell'acquisto sì.

Il modulo è ancora sotto la versione 1.0, e il suo README sconsiglia ancora di usarlo su negozi live. La release 0.6.6 ha aggiunto un hook displayExpressCheckout sopra il form di checkout, la validazione del CAP per gli ospiti e l'ordine dei campi dell'indirizzo per paese. Leggi le note di rilascio della versione che intendi usare.

Prima di attivarlo

• Tema. L'annuncio di PrestaShop dice che il checkout è pensato per i temi basati su Hummingbird. Classic non è supportato di default, e potresti dover fare l'override di alcuni template del modulo.
• Moduli di pagamento e di spedizione. Gli hook esistenti sono mantenuti, quindi molti moduli compaiono senza modifiche. Ma ora tutto viene mostrato su un'unica schermata e si aggiorna per sezioni, quindi prova ogni modulo di pagamento e di spedizione su una copia di staging, soprattutto i corrieri che calcolano il prezzo in base al CAP e i moduli di pagamento che generano il proprio markup.
• Il pagamento può ancora lasciare la pagina. Un form in una pagina elimina i passaggi prima del pagamento. Una verifica della carta con 3D Secure, una pagina di pagamento ospitata o una conferma della banca possono comunque portare l'acquirente altrove e poi riportarlo indietro.
• Codici promozionali. Il campo del buono sconto compare solo quando il tuo negozio ha almeno una regola carrello, perché PrestaShop disattiva l'intera funzione delle regole carrello quando non ce n'è nessuna. Un campo vuoto su un negozio di test non è un bug.
• Un altro modulo di checkout. Se è già attivo un checkout sostitutivo, leggi prima le sue istruzioni per il passaggio e le sue dipendenze. Non sovrapporre due checkout sostitutivi senza aver verificato che possano coesistere.
• Codice di checkout personalizzato. Chiedi al tuo sviluppatore di elencare cosa modifica template, campi, scelte di pagamento o selezione del corriere del checkout, compresi gli script legati al vecchio markup dei passaggi e i selettori dei punti di ritiro. Una ricerca nel codice mostra cosa esaminare; un hook o un nome file corrispondente non prova un conflitto.

Scegli in base alla tua configurazione esistente: registra le versioni esatte di PrestaShop e PHP, il tema e la sua versione, le versioni dei moduli di pagamento e corriere, le regole di checkout personalizzate e i sistemi collegati. Prova prima la modifica su una copia di staging. Esegui il backup di file e database, effettua un ordine di riferimento con il checkout attuale, poi cambia il layout senza altre modifiche a tema o pagamenti nello stesso momento. Ripeti gli stessi ordini e confronta i record risultanti, non gli screenshot:

• Un cliente ospite e un cliente di ritorno, su smartphone e desktop, compreso un indirizzo di fatturazione separato se lo usi.
• Un carrello con un buono sconto o una promozione sulla consegna: inserisci un indirizzo, scegli un corriere, poi passa a un altro paese in cui vendi. Consegna, imposte, promozione e scelte di pagamento devono ricalcolarsi tutte prima del pagamento.
• Pagamenti riusciti, rifiutati e annullati, 3D Secure e un pagamento confermato dopo che l'acquirente ha chiuso il browser, usando gli strumenti di test del fornitore.
• L'ordine risultante, il riferimento del pagamento, l'email di conferma e la variazione delle scorte, più qualsiasi esportazione collegata per l'evasione o la contabilità. Se usi pulsanti express, prova separatamente ogni punto di accesso abilitato, comprese combinazioni di prodotto, quantità e un carrello esistente.
• I campi obbligatori per gli acquirenti professionali e le regole di pagamento per gruppo di clienti, come casi separati: un ordine come ospite riuscito non li copre.

Interrompi l'attivazione se il totale sullo schermo differisce dall'importo inviato al fornitore di pagamento o registrato sull'ordine. Usa credenziali di pagamento di test, indirizza le email dello staging a una casella di test e disattiva le esportazioni live per evasione e contabilità.

Prima di passare al live, esegui un nuovo backup di file e database, registra la configurazione attuale e verifica la procedura di ripristino testata in staging. Tornare indietro richiede una sola impostazione, ma non annulla i pagamenti. Conserva e riconcilia gli ordini e le transazioni del fornitore ricevuti dopo il backup prima di valutare un ripristino del database. Dopo il passaggio live, confronta ordini completati, pagamenti falliti e richieste di assistenza con la tua base di riferimento, a parità di traffico e offerte, separatamente per mobile e desktop. Mantieni coerente tra i due layout la definizione di inizio del checkout. Un layout su una pagina non garantisce un aumento delle conversioni.

Il checkout nativo ti basta?

È una buona scelta predefinita se sei sulla 9.2, usi Hummingbird o un tema child basato su Hummingbird e hai un checkout B2C standard: pochi corrieri, metodi di pagamento comuni e acquisti come ospite come norma. In questo caso, provalo in staging prima di acquistare un modulo. Usalo sul live solo quando la versione scelta è documentata come adatta alla produzione e supera gli scenari d'ordine concordati.

Guarda oltre quando puoi indicare un requisito che non soddisfa, per esempio se:

• il tuo negozio usa PrestaShop dalla 1.6 alla 9.1 e un aggiornamento non è previsto a breve;
• vuoi i pulsanti dei wallet digitali sulle pagine prodotto e carrello, non solo dentro il checkout. Il modulo nativo dà ai moduli di pagamento uno spazio in cui mostrare i pulsanti express, ma non li fornisce lui stesso;
• vuoi che gli acquirenti creino un account mentre ordinano;
• dipendi da campi di checkout personalizzati, regole B2B o restrizioni di pagamento per gruppo di clienti. Scrivi prima queste regole (chi può pagare a credito, dove deve comparire un riferimento d'acquisto, come un preventivo accettato diventa un ordine), poi verifica che i moduli che le forniscono funzionino all'interno del flusso su una pagina prima del passaggio.

Conviene aspettarlo?

• Già sulla 9.2: il codice è disponibile, ma l'avviso nel README resta un motivo per aspettare prima di usarlo sul live. Visto lo stato pre-1.0 del modulo e l'avviso nel README, mantieni live il tuo checkout funzionante finché una versione che hai provato non supera i tuoi ordini in staging.
• Sulla 9.0 o 9.1: il checkout nativo arriva con l'aggiornamento alla 9.2. Pianifica quell'aggiornamento in base ai suoi meriti (tema, moduli, PHP) e prova il checkout come parte di esso. Se il tuo checkout attuale funziona, aspettare quell'aggiornamento è ragionevole.
• Sulla 1.6, 1.7 o 8: arrivare alla 9.2 richiede un piano di migrazione basato su moduli, integrazioni, tema e dati esistenti. Per negozi più vecchi o molto personalizzati, il percorso sicuro abituale è un negozio 9.2 pulito in staging, una migrazione dei dati già provata e un passaggio definitivo pianificato; la checklist di migrazione a PrestaShop 9 ti guida passo per passo. Non cambiare versione principale solo per un layout del checkout.
• Stai perdendo ordini adesso: non aspettare. Un errore di pagamento riproducibile o un abbandono noto richiedono una diagnosi oggi, e un nuovo layout non corregge un errore di pagamento.

Se non sai dove gli acquirenti abbandonano, il PrestaShop B2C Conversion & Revenue Audit esamina il percorso d'acquisto dei consumatori e fornisce un piano di correzioni in ordine di priorità, senza installare né modificare nulla.

Checkout Revolution offre un checkout su una pagina e una finestra modale di checkout express anche su PrestaShop da 1.6 alla 9.1, con regole per campi e pagamenti per gruppo di clienti e paese e preventivi professionali accettati che diventano ordini. Express Checkout aggiunge una finestra d'acquisto Stripe (carte, wallet e metodi locali) su pagine prodotto, elenchi o carrello accanto al tuo checkout esistente e offre un checkout opzionale su una pagina che include i tuoi altri moduli di pagamento e spedizione. Le alternative più ampie sono confrontate nella nostra guida al checkout.

Una volta scelto un modulo, il PrestaShop Module Installation & Configuration Service installa e configura un modulo esistente e verifica il percorso interessato, con passaggi documentati per annullare la modifica.