Checkout PrestaShop: configurazione, pagamenti e diagnosi

Come procederemmo

Quale modifica aiuta dipende dal negozio esistente: la versione di PrestaShop, il tema, i moduli di pagamento e corriere, il codice personalizzato degli ordini e le integrazioni di magazzino, contabilità o consegna che ricevono i suoi ordini. Mappa quali dati di cliente, indirizzo e ordine riceve ciascuna di queste integrazioni. Seguiremmo un acquisto che non va a buon fine dal carrello alla conferma dell'ordine su quella combinazione esatta, come nuovo visitatore e come cliente di ritorno. Confronta ogni restrizione con la regola prevista dal negozio prima di considerarla un difetto, poi correggi prima gli errori di configurazione o integrazione dimostrati. Cambia il layout quando le prove indicano campi o navigazione poco chiari; cambia l'integrazione di pagamento quando manca un metodo o un'operazione di pagamento necessari.

Per la configurazione del checkout e le modifiche ai moduli: riproduci il problema su una copia di staging del negozio, isolata da pagamenti reali, email ai clienti ed evasione degli ordini; cambia un livello alla volta; prova scenari d'acquisto scritti; poi effettua il passaggio in un momento pianificato, con un backup di file e database, un modo testato per tornare indietro e un piano per riconciliare gli ordini ricevuti nel frattempo. Un checkout che soddisfa già le esigenze resta com'è. Se il lavoro sul checkout fa parte di una ricostruzione più ampia del negozio, il percorso sicuro abituale è un negozio di destinazione pulito in staging, una migrazione già provata dei dati necessari del negozio e un passaggio pianificato dopo aver testato moduli e integrazioni.

Se la causa degli ordini persi non è chiara, il PrestaShop B2C Conversion & Revenue Audit esamina scoperta dei prodotti, carrello, checkout, pagamento e conferma, partendo da uno smartphone, e fornisce un piano di correzioni in ordine di priorità senza installare né modificare nulla; l'implementazione è separata.

Comprendi il flusso del checkout

In PrestaShop 1.7.8 e 9.1, il controller degli ordini costruisce quattro passaggi logici: dati personali, indirizzi, consegna e pagamento. Un carrello di soli prodotti virtuali omette la consegna. Riepilogo del carrello e conferma dell'ordine sono parti distinte del percorso. Un solo URL del checkout può comunque contenere più passaggi, richieste e trasferimenti al pagamento.

Un cliente di ritorno può avere già dati salvati. Un tema o modulo di checkout può cambiare la presentazione. Conta le navigazioni tra documenti e le richieste in background nel browser prima di descrivere il negozio come un checkout di quattro o cinque pagine.

PrestaShop 9.2 include il modulo nativo ps_onepagecheckout. Va abilitato e configurato prima che il suo checkout unificato diventi attivo. Il checkout a passaggi resta disponibile. La documentazione attuale del checkout nativo spiega l'integrazione.

Tieni separate quattro scelte: il layout del checkout, l'integrazione di pagamento, l'account del fornitore che la sostiene e il modo in cui misuri il percorso.

Prima di seguire qualsiasi istruzione, registra la versione di PrestaShop installata, la versione PHP, il tema e le versioni dei moduli di checkout e di pagamento, e controlla cosa supportano esattamente quelle versioni. Valuta insieme le opzioni del checkout nativo e i moduli di terze parti; una vecchia roadmap non è una guida alla configurazione.

Associa il sintomo alla prossima azione

Prima di cambiare qualcosa

1. Prova lo stesso acquisto su uno smartphone come nuovo visitatore e come cliente di ritorno. Annota dove le informazioni vanno inserite di nuovo o dove un errore lascia poco chiara l'azione successiva.
2. Separa la navigazione dalle decisioni irrisolte. Un costo di consegna mostrato tardi, un corriere inadatto o un metodo di pagamento mancante richiedono una correzione propria, anche su una sola pagina.
3. Scrivi uno scenario di accettazione per l'ostacolo: tipo di cliente, carrello, destinazione, metodo di pagamento e risultato atteso. Usalo per confrontare il checkout attuale con qualsiasi alternativa proposta.

Per esempio, un'opzione di pagamento può comparire per un cliente privato nazionale ma sparire dopo che l'acquirente seleziona un altro paese, accede a un account professionale o sceglie un determinato corriere. Confronta il contesto di quel carrello con le regole di pagamento previste prima di dare la colpa al layout. Un metodo abilitato nella dashboard del fornitore può comunque non essere disponibile tramite l'integrazione installata.

Quando l'integrazione li usa entrambi, il ritorno del browser dall'autenticazione bancaria e la notifica server del fornitore sono percorsi di prova separati. Una pagina di ritorno non funzionante non dimostra che il pagamento sia fallito e una pagina di conferma mancante non dimostra che non esista alcun ordine. Confronta stato, importo, valuta e riferimento presso il fornitore con il record del negozio; pagamenti autorizzati, in attesa, acquisiti e completati possono richiedere una gestione diversa.

Una segnalazione utile all'assistenza contiene il carrello, il tipo e il gruppo del cliente, il mercato e la valuta, il dispositivo, l'ora dell'errore con il fuso orario, il riferimento del carrello o dell'ordine, un riferimento della transazione del fornitore oscurato, i passaggi per riprodurre il problema e il messaggio esatto. Chiedi allo sviluppatore di mettere in relazione le prove del browser e del server. Rimuovi credenziali, dati di pagamento e dati dei clienti non necessari prima di condividere log o screenshot.

Scegli un percorso di checkout dopo aver definito la lacuna

Mantieni il flusso nativo installato se soddisfa il requisito e mantieni un'integrazione di pagamento esistente se offre i metodi e la gestione degli ordini di cui hai bisogno. Non acquistare un modulo perché il suo nome suona più veloce: una sola pagina può comunque contenere tutte le decisioni necessarie e un wallet può ridurre la digitazione senza risolvere le opzioni di consegna o di prodotto.

Checkout Revolution mette contatti, indirizzo, consegna, pagamento, buoni sconto e riepilogo dell'ordine su un'unica pagina, in una, due o tre colonne, con l'ordine delle sezioni che scegli tu e la scelta di quali campi mostrare o rendere obbligatori. I tuoi corrieri e pagamenti esistenti compaiono al suo interno, un cliente di ritorno non deve digitare di nuovo l'indirizzo, le regole di pagamento possono seguire negozio, lingua, gruppo di clienti, paese, dispositivo e valore dell'ordine, e il preventivo accettato da un acquirente professionale può diventare un ordine senza reinserire i dati. Include anche una finestra di acquisto express su pagine prodotto, elenchi e carrello.

Express Checkout riunisce indirizzo, consegna, pagamento e conferma in un'unica finestra su pagine prodotto, elenchi o carrello. I pagamenti passano da Stripe, senza canone mensile e con una commissione per transazione, per carte, wallet e metodi locali; confronta queste condizioni separatamente dalla valutazione del percorso per il tuo negozio. Scegli tu le posizioni dei pulsanti, i campi d'indirizzo obbligatori e l'idoneità dei pagamenti per pubblico, paese e valuta. I prezzi di consegna si aggiornano in tempo reale, le combinazioni escluse di pagamento e corriere vengono respinte e i rimborsi totali o parziali si eseguono dalla schermata dell'ordine. Un checkout opzionale su una pagina include i tuoi altri moduli di pagamento e spedizione.

In entrambi, un pagamento completato dopo la chiusura del browser diventa comunque un ordine. Nessuna delle due descrizioni di prodotto promette carte salvate o nomina un wallet specifico come Apple Pay o Google Pay, quindi verifica un eventuale requisito di questo tipo con la versione e il tuo account di pagamento prima dell'acquisto. Nessuno dei due nomi di prodotto stabilisce la compatibilità con il tuo codice personalizzato: includi nel requisito override del checkout, campi aggiuntivi, integrazioni di magazzino o contabilità e regole B2B.

Se la scelta richiede test, il PrestaShop Module Selection & Fit Assessment confronta impostazioni native, prodotti già posseduti, fornitori e sviluppo personalizzato per un requisito, prova i candidati su una copia controllata del negozio e include configurazione, adattamento grafico e rilascio di un modulo pronto scelto; le licenze costano a parte e lo sviluppo personalizzato viene preventivato separatamente. Se possiedi già il modulo scelto, il PrestaShop Module Installation & Configuration Service installa e configura un modulo esistente secondo un ambito concordato e verifica il percorso interessato; licenze, moduli aggiuntivi e sviluppo hanno costi separati.

Scegli un checkout a passaggi, su una pagina o incorporato

PrestaShop 1.6 aveva un'impostazione del tipo di processo d'ordine. Il checkout ricostruito in 1.7 non usava quel vecchio interruttore. In 1.7, 8 e 9.0/9.1, un layout alternativo completo richiede un modulo appropriato o un'implementazione personalizzata. PrestaShop 9.2 fornisce OPC nativo, quindi valuta questa opzione disponibile prima di commissionare una sostituzione.

OPC nativo non è categoricamente limitato a Hummingbird. I temi derivati da Classic e quelli personalizzati possono integrarsi con il suo contratto di template e JavaScript. Segui la guida di compatibilità dei temi e prova la combinazione installata.

Acquisti complessi, prodotti regolamentati, personalizzazioni e più opzioni di spedizione possono trarre vantaggio da un raggruppamento ragionato. Gli ordini semplici possono adattarsi a una vista unificata. Per un articolo di valore elevato, come un orologio da €2.000, rendi chiara la revisione finale. Scegli il layout in base ai requisiti dei tuoi ordini e ai test di usabilità: l'obiettivo utile è avere meno passaggi superflui con l'ordine corretto ancora visibile per la revisione, non un numero di pagine inferiore.

Checkout Revolution implementa un checkout su una pagina e flussi express/modali; consulta la guida di Checkout Revolution. Controlla il riepilogo dell'ordine e i pulsanti di invio con larghezze desktop e mobile.

Evitare modifiche al core può ridurre la manutenzione, ma non garantisce compatibilità futura. Mantieni sotto controllo di versione le modifiche al tema child e prova gli aggiornamenti con i moduli di corriere e pagamento.

Misura gli eventi e diagnostica gli abbandoni

Registra ingresso dal carrello al checkout, completamento del checkout, pagamenti falliti, tempo di completamento e valore dell'ordine. Definisci se completamento significa ordine creato o pagamento confermato. Usa la stessa definizione per tutto il confronto e registra con essa i percorsi normali, express e con reindirizzamento, così un flusso wallet o modale non manca dai totali. Suddividi i risultati per dispositivo, tipo di cliente, paese e metodo di pagamento quando il volume lo consente.

Questi sono eventi ecommerce Google, non un evento per ogni passaggio dell'interfaccia nativa. Per distinguere l'abbandono dei dati personali da quello dell'indirizzo, registra esplicitamente visualizzazioni dei passaggi, invii, risultati di convalida ed eventi di completamento. Non inviare nomi, email, indirizzi o dettagli di pagamento agli strumenti di analisi.

Controlla ogni evento con gli strumenti di debug del browser e dell'analisi, compresi invio di spedizione e pagamento, carrelli virtuali e nuovi tentativi. Per l'integrazione Google Analytics GA4, usa la guida del modulo.

Usa feedback dei clienti, registrazioni delle sessioni mascherate conformi al consenso ed errori del browser per indagare su un calo. Un'uscita al passaggio di consegna può riguardare costi, corrieri non disponibili, tempi o un guasto tecnico. La posizione nel funnel non prova il motivo dell'acquirente. Dai priorità a errori confermati e opportunità in base a traffico coinvolto, costo e impatto previsto.

I sondaggi sui motivi di abbandono possono suggerire domande. Non misurano il tuo funnel PrestaShop né prevedono l'aumento ottenibile con una modifica, e non esistono un obiettivo di completamento o un periodo di rientro universali: confrontati con la tua base di riferimento. Scegli un disegno di confronto e una dimensione del campione in base alla tua base di riferimento, all'effetto che devi rilevare e alla variabilità del traffico. Tieni sotto controllo promozioni, stagionalità e composizione del traffico. Un'adozione dei wallet senza variazione della conversione complessiva non dimostra una cannibalizzazione.

A titolo illustrativo, aumentare il completamento dal 30% al 31% è un aumento relativo di circa il 3,33%. I ricavi cambiano nella stessa proporzione solo se volume del checkout e valore medio dell'ordine restano costanti. Questo calcolo non è una previsione.

Usa i dati dei carrelli senza inventare un funnel

PrestaShop conserva i carrelli. Ordini > Carrelli ti aiuta a esaminarli, ma una riga carrello non prova l'ingresso nel checkout. Scegli prefisso delle tabelle e ID negozio corretti. Il seguente esempio in sola lettura conta i carrelli creati di recente, attualmente non vuoti, e il sottoinsieme collegato a un ordine attualmente valido.

SELECT COUNT(*) AS nonempty_carts,
       SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) AS carts_with_valid_order,
       ROUND(100.0 * SUM(EXISTS (
         SELECT 1 FROM ps_orders o
         WHERE o.id_cart = c.id_cart AND o.valid = 1
       )) / NULLIF(COUNT(*), 0), 1) AS cohort_ratio_pct
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart);

È un rapporto di coorte tra carrelli non vuoti e ordini attualmente validi. Non è la conversione del checkout. I carrelli recenti hanno avuto meno tempo per convertire, gli ordini in attesa possono diventare validi dopo e un carrello può creare più ordini. EXISTS evita di contare un carrello più volte.

Definisci l'abbandono con una soglia di inattività e una politica sugli ordini. Questo secondo esempio usa 24 ore senza aggiornamenti del carrello come soglia illustrativa ed esclude ogni carrello con qualsiasi ordine, inclusi gli ordini non pagati.

SELECT CASE
         WHEN c.id_carrier > 0 THEN '3 - carrier value stored'
         WHEN c.id_address_delivery > 0 THEN '2 - delivery address stored'
         ELSE '1 - neither value stored'
       END AS stored_state,
       COUNT(*) AS inactive_nonempty_carts
FROM ps_cart c
WHERE c.id_shop = 1
  AND c.date_add >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 24 HOUR)
  AND EXISTS (SELECT 1 FROM ps_cart_product cp WHERE cp.id_cart = c.id_cart)
  AND NOT EXISTS (SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart)
GROUP BY stored_state
ORDER BY stored_state;

Leggi direttamente le etichette delle fasi. Indirizzi e corrieri memorizzati possono essere stati ripristinati o assegnati automaticamente; sono soltanto indizi euristici. Questa query non distingue ricerca, interruzione, traffico bot o checkout fallito. Applica le esclusioni bot documentate e riconcilia con i dati degli eventi. Monitora separatamente il recupero degli ordini non pagati se è questo il tuo obiettivo.

Configura gli ordini come ospite e i campi dell'account

1. Apri Parametri Negozio > Impostazioni Ordine ed esamina Abilita ordine ospite. Nelle versioni moderne corrisponde a PS_GUEST_CHECKOUT_ENABLED. Salva dal back office nel contesto del negozio desiderato.
2. Prova una nuova sessione ospite e un account di ritorno. Nel checkout nativo, l'ordine come ospite rende facoltativa la password del checkout. L'accesso resta disponibile.
3. Esamina separatamente richieste di data di nascita, titoli di cortesia e campi cliente aggiuntivi. La modalità B2B controlla specifici campi dell'account cliente; non rimuove universalmente azienda o identificativo VAT dagli indirizzi.
4. Esamina formato indirizzo, requisiti di CAP e stato/provincia di ogni paese di destinazione in Internazionale > Località > Nazioni. Requisiti degli indirizzi e dei corrieri devono corrispondere all'evasione.

Puoi esaminare le righe di configurazione senza modificarle:

SELECT id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name = 'PS_GUEST_CHECKOUT_ENABLED';

Un indirizzo email dell'ordine non è un'autorizzazione al marketing. Offri un consenso separato e appropriato. Il tracciamento degli ordini può usare il flusso nativo per ospiti. La conversione nativa dell'ospite è un processo esplicito; abilitare gli ordini ospite non installa la registrazione automatica dopo l'acquisto. Prova la gestione dell'email di un account esistente anziché promettere account duplicati o instradamento automatico delle email.

Gli account possono supportare accessi B2B riservati, gestione di servizi ricorrenti e record fedeltà. Decidi in base a questi requisiti: per le vendite ai consumatori, verifica se richiedere un account crea un ostacolo evitabile; per le vendite alle aziende, stabilisci quali acquirenti devono avere account approvati o dati aziendali. Cambiare fornitore di pagamento non decide queste regole sugli account. I download nativi dei prodotti virtuali possono usare link protetti per gli ospiti; vendere un prodotto scaricabile non richiede di per sé l'accesso con un account registrato.

Mantieni modificabili in modo indipendente l'indirizzo di consegna e quello di fatturazione. Chiedi un numero di telefono quando il tuo servizio di consegna ne ha bisogno. Conserva i caratteri internazionali validi e spiega gli errori dei campi senza svuotare i campi già compilati. Prima di rimuovere un campo obbligatorio che mette in difficoltà i clienti, stabilisci perché è obbligatorio.

Prova etichette ed errori in ogni lingua del negozio, compresi i messaggi dei moduli di pagamento, i campi d'indirizzo specifici per paese e i link alle condizioni. Un tema tradotto non dimostra che ogni messaggio di modulo o fornitore sia tradotto: quando un checkout francese mostra un errore d'indirizzo in inglese, scopri se lo produce il tema, un modulo o il fornitore prima di decidere dove tradurlo. Un campo provincia obbligatorio invisibile o un errore poco chiaro sul CAP possono bloccare un acquisto prima ancora che inizi il pagamento. La guida alle traduzioni e alla vendita internazionale tratta la configurazione linguistica più ampia.

I test su larga scala del Baymard Institute sul checkout mostrano quanto spesso i negozi trascurano entrambi i punti: il 98% dei siti non usa messaggi di errore specifici e il 62% non rende l’acquisto come ospite l’opzione più in evidenza. La ricerca UX di Baymard sul checkout spiega le prove dietro queste raccomandazioni.

Mostra costi, aspettative di consegna e condizioni di reso

Mostra presto prezzi, imposte e costi di consegna noti. Indica una stima come stima quando l'indirizzo finale o il corriere non sono ancora noti. Configura imposte, visualizzazione dei prezzi per gruppo di clienti e corrieri per le destinazioni che servi; la guida alle spedizioni tratta la configurazione dei corrieri e i costi di consegna. Spedizione > Preferenze offre le soglie di spedizione gratuita; un messaggio sull'importo mancante richiede il rendering del tema o di un modulo.

Per esempio, un acquirente che si aspetta €40 può ripensarci quando il totale diventa €49. Mostra l'addebito aggiuntivo e la sua base prima dell'azione finale d'ordine. Un prezzo più basso e una spiegazione anticipata risolvono problemi diversi.

Fornisci informazioni realistiche sui tempi di preparazione e di transito del corriere. Estimated Delivery Date fornisce i tempi di spedizione o di consegna; consulta la guida di Estimated Delivery Date. Per i costi di spedizione usa uno stimatore di prezzo testato separatamente o una politica chiara sui prezzi di consegna.

Rendi facili da trovare la politica effettiva di reso e il contatto nelle pagine prodotto e carrello. L'interruttore dei resi merce controlla un flusso tecnico. Non crea né elimina diritti di legge e non giustifica pubblicizzare resi entro 30 giorni se non li offri. Controlla le regole di recesso applicabili e le eccezioni.

Comprendi i wallet express e l'idoneità dei pulsanti

I wallet possono fornire contatti salvati e credenziali di pagamento tokenizzate. Un'integrazione express completa può raccogliere indirizzi, offrire scelte di spedizione supportate e aggiornare i totali nel proprio flusso. Il cliente potrebbe comunque dover confermare dettagli, scegliere la consegna, accettare condizioni o autenticarsi. Un pagamento con wallet all'ultimo passaggio del checkout non evita automaticamente i form precedenti.

Il checkout express è un percorso utente, non un obbligo di usare la Payment Request API del browser. Le integrazioni possono usare interfacce wallet, SDK dei fornitori, finestre modali o reindirizzamenti. Possono raccogliere dati distinti di fatturazione e spedizione. Mantieni un percorso regolare di checkout per browser, destinazioni e requisiti d'ordine non supportati.

I pulsanti possono comparire su pagine prodotto, carrelli, mini-carrelli o checkout, in base a integrazione e hook renderizzati. Prova se l'express nella pagina prodotto paga l'articolo selezionato, tutto il carrello esistente o un carrello appena creato. Misura valore del carrello e completamento anziché supporre che Acquista ora riduca il valore dell'ordine.

1. Conferma che il metodo di pagamento sia abilitato per account commerciante, paese, valuta e importo del carrello.
2. Registra ogni hostname pertinente del checkout secondo i requisiti del processore, inclusi i domini di pagamento incorporato applicabili.
3. Controlla HTTPS, certificati, permessi iframe ed errori nella console/rete del browser.
4. Controlla la matrice attuale dei browser del processore e il wallet o metodo di pagamento configurato dal cliente.
5. Controlla restrizioni specifiche del modulo e posizioni supportate. Le capacità del fornitore non provano il supporto del modulo.

Il supporto dei browser dipende da wallet e integrazione. Controlla la matrice del checkout express Stripe e le indicazioni di acquisto Apple per le opzioni attuali di dispositivo e autorizzazione.

Quando il processore richiede un file di associazione, questo verifica soltanto la raggiungibilità:

curl -I https://example.com/.well-known/apple-developer-merchantid-domain-association

Una risposta riuscita non dimostra la registrazione del dominio né l'idoneità del wallet. Un gateway supportato può già fornire pulsanti express; un acceleratore separato è un'altra opzione. Consulta la guida di Express Checkout.

Uno scenario di carrello che rivela il comportamento sbagliato

Un acquirente ha già un filtro nel carrello, seleziona una combinazione di ricarica in una pagina prodotto e preme il pulsante express. La tua specifica deve dire se quell'azione acquista solo la ricarica, il carrello esistente o entrambi dopo una revisione. Mostra il contenuto prima del pagamento e controlla cosa resta nel carrello dopo; l'etichetta di un pulsante non stabilisce il comportamento del modulo.

Ripeti con una personalizzazione obbligatoria lasciata vuota, poi compilata: il percorso rapido deve applicare gli stessi requisiti di prodotto del checkout principale. Se la destinazione non ha un corriere adatto, il cliente ha bisogno di una spiegazione e di un modo per cambiare indirizzo o carrello prima di pagare.

Distingui pagamenti salvati e ordini con un clic

Un token di pagamento riutilizzabile, un cliente noto, un indirizzo attuale, una spedizione risolvibile, il corretto contesto fiscale e un consenso valido possono accorciare un acquisto ripetuto. Ricontrolla disponibilità, prezzi, consegna e opzioni obbligatorie prima dell'addebito. Conserva i dettagli di pagamento presso il fornitore e memorizza solo gli identificatori cliente/metodo necessari all'integrazione. Non memorizzare numeri di carta grezzi o CVV in PrestaShop.

Per esempio, Anna riordina il caffè con indirizzo e carta salvati. Il suo prossimo ordine potrebbe richiedere pochi inserimenti, ma un prezzo di spedizione cambiato o un'autenticazione bancaria possono aggiungere un passaggio. Quando invia la confezione successiva all'indirizzo di un'amica, disponibilità della consegna e totale vanno ricontrollati. Un checkout rapido utile le permette di correggere l'indirizzo o completare la verifica della banca, poi mostra un esito chiaro dell'ordine; non tiene basso il numero di clic riutilizzando silenziosamente vecchie informazioni. Anche chi visita il negozio per la prima volta può avere un wallet configurato, pur senza alcun record cliente precedente nel tuo negozio, quindi giudica entrambi i percorsi in base a dati corretti e a un acquisto completato, non in base allo storico di registrazione.

Riconoscere un cliente che ha effettuato l'accesso è diverso dall'avere l'autorizzazione e il supporto tecnico per riutilizzare un metodo di pagamento. Una voce nella rubrica degli indirizzi o un ordine precedente riuscito non stabiliscono che il prossimo ordine possa essere addebitato, e salvare un indirizzo non salva una carta. Chiedi al fornitore dell'integrazione dove vengono conservati i dati riutilizzabili, come il cliente li sceglie e come può modificare questa scelta.

Un cliente che sta acquistando attivamente usa un flusso di pagamento salvato on-session. Off-session descrive addebiti avviati dal commerciante mentre il cliente è assente. Non contrassegnare come off-session un addebito di un checkout interattivo solo per evitare l'autenticazione. Gestisci l'autenticazione richiesta e gli esiti asincroni secondo l'integrazione del fornitore e chiedi al fornitore come vengono gestiti la conferma del cliente, l'autorizzazione al pagamento salvato e una richiesta di autenticazione.

1. Ricalcola e convalida il carrello sul server.
2. Conferma l'autorizzazione del cliente usando il flusso supportato dal fornitore.
3. Verifica risultato attendibile del pagamento, importo, valuta e corrispondenza al carrello.
4. Crea o aggiorna l'ordine PrestaShop in modo idempotente. Gestisci callback duplicati e nuovi tentativi.
5. Riconcilia lo stato finale pagato, fallito, in attesa o rimborsato.

Uno snippet di creazione PaymentIntent non completa questo ciclo di vita dell'ordine. Anche metodi offline possono semplificare l'ordine senza tokenizzare una carta, ma l'ordine risultante può essere ancora non pagato e richiedere riconciliazione bancaria o contrassegno. Non si può garantire un numero letterale di tocchi o un acquisto senza autenticazione.

Scegli e risolvi i problemi delle integrazioni di pagamento

ps_checkout, PrestaShop Checkout, è un'integrazione di pagamento, non il nome dell'intero processo di checkout. Gestisce opzioni di pagamento, autorizzazione/acquisizione, transazioni e rimborsi tramite l'integrazione PayPal supportata. Il commerciante collega un account PayPal Business. Esamina termini di regolamento e accredito per il tuo account commerciante collegato.

L'inclusione nella distribuzione dipende da distribuzione e data. Controlla modulo installato e versione supportata. Usa il repository ufficiale del modulo per la documentazione e la guida ufficiale alle transazioni per gli stati di pagamento. Esistono percorsi ufficiali per risoluzione dei problemi dell'account e assistenza; segui le condizioni pubblicate.

Per installazione, attivazione iniziale e rimozione, usa la documentazione ufficiale di PrestaShop Checkout. Prima di disabilitare qualsiasi fornitore, conferma che resti disponibile un altro percorso di pagamento funzionante.

Puoi valutare Stripe, Mollie, PayPal, Adyen, Amazon Pay e integrazioni dedicate di pagamento a rate come Klarna, Alma o Clearpay/Afterpay rispetto ai tuoi requisiti. Verifica lo specifico modulo PrestaShop invece del numero di metodi nell'intero catalogo del fornitore. Confronta supporto all'autorizzazione, rimborsi, contestazioni, accrediti, valute, idoneità dell'account, pagamenti ricorrenti, reportistica e assistenza. La guida ai pagamenti approfondisce la scelta e la gestione dei metodi.

Possibili metodi regionali da esaminare includono iDEAL per i Paesi Bassi, Bancontact per il Belgio, BLIK o Przelewy24 per la Polonia, SEPA o fattura per Germania/Austria, Cartes Bancaires o rate per la Francia, Bizum per la Spagna, Satispay o MyBank per l'Italia e open banking per il Regno Unito. Sono esempi di ricerca, non promesse di disponibilità nel tuo modulo. Non pianificare nuove integrazioni intorno ai dismessi SOFORT autonomo o Giropay. Controlla la documentazione attuale dei metodi del fornitore.

Confronta le commissioni reali per la tua entità giuridica, il metodo, l'origine della carta, la valuta, la conversione valutaria, i pagamenti non riusciti, i rimborsi e le contestazioni. Un modulo gratuito può comunque avere costi di elaborazione. Il bonifico bancario evita la commissione di un gateway di carte, ma può comportare spese bancarie e riconciliazione manuale. Controlla l'arrivo dei fondi prima dell'evasione; consulta il modulo nativo per il bonifico bancario.

Per qualsiasi metodo differito, definisci quando un ordine può essere evaso e chi conferma la ricezione dei fondi: una conferma d'ordine non prova che il pagamento sia arrivato, quindi includi nella scelta questo lavoro di riconciliazione del personale. Se ricevi bonifici su più conti o in più valute, Bank Transfer Accounts mostra ai clienti il conto per la valuta del loro ordine, con l'importo e il riferimento dell'ordine, nella pagina di conferma, nell'email con le istruzioni e nella pagina dei dettagli dell'ordine; la conferma della ricezione e l'aggiornamento dell'ordine restano compito tuo.

Domande per il fornitore di pagamento e il fornitore del modulo

• Ogni metodo richiesto è disponibile per la nostra entità giuridica, i mercati dei clienti, le valute e la versione del modulo?
• Dove troverà il personale i riferimenti delle transazioni, riconcilierà gli accrediti e gestirà i rimborsi totali o parziali?
• Chi gestisce difetti dell'integrazione, restrizioni dell'account e contestazioni dei pagamenti e quali prove serviranno all'assistenza?
• Dopo un cambio, dove vengono elaborati e registrati i rimborsi degli ordini incassati con il modulo precedente?

Nessun metodo di pagamento disponibile

1. Controlla i moduli attivi e le restrizioni in Pagamento > Preferenze per valuta, paese, gruppo e corriere.
2. Controlla credenziali del fornitore, stato dell'account, limiti di importo e modalità reale/test.
3. Esamina le opzioni effettivamente restituite, i log PHP e gli errori del browser.
4. Esamina gli header reali delle risposte se gli script sono bloccati. Non supporre che PrestaShop 8/9 standard abbia una CSP universale del checkout che causi il problema.

Le integrazioni di pagamento moderne dovrebbero implementare paymentOptions. I core 1.7.8 e 9.1 leggono anche i percorsi di compatibilità displayPaymentEU e advancedPaymentOptions. Cercare soltanto un vecchio nome di hook non diagnostica l'invisibilità. Le restrizioni di disponibilità differiscono dall'ordinamento: esamina il posizionamento di paymentOptions in Design > Posizioni e gli eventuali ordinamenti nel modulo di pagamento.

Prova spedizione dinamica, sconti e requisiti B2B

Cambiare paese, CAP, quantità o prodotto può cambiare corrieri, imposte, idoneità dei pagamenti e totale. Conserva le selezioni ancora valide, cancella visibilmente quelle non valide e impedisci l'invio finché il ricalcolo non è completo. Prova carrelli reali pesanti, virtuali, misti e multicollo.

A titolo illustrativo, un articolo da 0,5 kg più uno da 25 kg totalizzano 25,5 kg. Superano un ipotetico limite del corriere di 20 kg, ma non uno di 30 kg. Altre dimensioni, zone e restrizioni possono comunque escludere un corriere. Sono limiti di esempio, non condizioni pubblicate dei corrieri.

Le regole carrello hanno priorità, regole di compatibilità, restrizioni cliente/prodotto, date e limiti d'uso. Una regola del 20% non cumulabile e una separata di spedizione gratuita richiedono una configurazione di compatibilità verificata. Un buono fisso da €10 può entrare in conflitto con una regola automatica del 15%. Condizioni di idoneità e azione di sconto sono controlli diversi.

Il minimo delle regole carrello usa i totali dei prodotti con le impostazioni di imposte e valuta selezionate, più la spedizione quando configurato. Le riduzioni di prezzo specifiche dei prodotti incidono già su questi totali. In PrestaShop 9.1 il calcolo sottrae anche i regali applicabili dalle regole già presenti nel carrello. Prova una soglia di €100 con un carrello idoneo e uno appena al di sotto, con prodotti scontati, prodotti in regalo, conversione valutaria e spedizione inclusa o esclusa.

Prova anche un caso combinato. Un carrello ha uno sconto automatico sui prodotti, il cliente inserisce un buono e dovrebbe applicarsi una promozione sulla consegna. Scrivi prima il risultato previsto: quali sconti si combinano, quali corrieri sono idonei e l'importo finale da pagare. Ripeti dopo aver cambiato quantità, corriere e paese di consegna, e confronta il riepilogo visibile, l'importo inviato al fornitore e il record dell'ordine. Un buono respinto dovrebbe lasciare una spiegazione chiara e un percorso utilizzabile verso il pagamento.

Le restrizioni del corriere per le regole di spedizione gratuita devono corrispondere alle scelte desiderate. Analizza una valutazione lenta delle regole prima di eliminarne di storiche; le date scadute incidono già sull'idoneità. Conserva la configurazione secondo le tue esigenze operative.

Un controllo compatto “Hai un codice?” può ridurre l'ingombro mantenendo utilizzabili i buoni. L'applicazione del codice promozionale deve usare un flusso carrello verificato che gestisca i token. Il semplice URL addDiscount=1&discount_name=SUMMER10 non è sufficiente in tutti i casi, soprattutto per clienti autenticati. Convalida l'idoneità sul carrello effettivo.

Per il B2B, specifica fatturazione/consegna separate, dati aziendali, riferimenti d'ordine d'acquisto, approvazione dell'account e termini di pagamento concordati. Un'identificazione VAT valida è solo parte del trattamento VAT transfrontaliero; contano anche condizioni della cessione e documentazione di supporto. Distingui indisponibilità di VIES e risultato non valido. Controlla le indicazioni UE sulla VAT transfrontaliera.

I campi aggiuntivi richiedono un ciclo di vita completo: renderizzarli, convalidarli, salvarli ed esporli dove servono in ordini, esportazioni o fatture. Un riferimento d'ordine d'acquisto è utile solo se viene convalidato, conservato con l'ordine e reso visibile al personale o all'esportazione che ne ha bisogno; le istruzioni di consegna devono arrivare all'evasione. Far comparire un campo in un template non è un'implementazione completa. Le estensioni del form cliente possono usare additionalCustomerFormFields e validateCustomerFormFields; la guida a hook e override spiega come i moduli vi si collegano. actionValidateOrder da solo non può implementare il form.

Quell'hook di creazione ordine viene eseguito all'interno di PaymentModule::validateOrder(), prima della successiva gestione degli stati. Può essere eseguito per ordini in attesa o offline. Verifica stato del pagamento e conferma nel browser separatamente da questo hook. Usa callback appropriati del fornitore e gestione degli stati ordine per azioni su pagamento, disponibilità ed email.

Rendi il percorso usabile sui telefoni

Usa analisi per categoria di dispositivo con eventi di acquisto funzionanti. Il report legacy Browser e sistemi operativi è un report di compatibilità, non un moderno funnel di ricavi mobile. Intento del traffico, composizione dell'acquisizione, acquisti tra dispositivi e lacune di tracciamento possono spiegare anche differenze tra dispositivi.

Classic resta comune nei negozi meno recenti e aggiornati. Hummingbird è diventato predefinito nelle nuove installazioni PrestaShop 9.1. Né l'etichetta responsive né un tema nuovo garantiscono assenza di debordamenti, tastiere usabili o moduli accessibili.

• Usa type="email" e autocomplete="email" per l'email, e type="tel" con autocomplete="tel" per il telefono.
• Usa campi di testo per i CAP. Aggiungi inputmode="numeric" solo per il formato numerico del paese selezionato. I formati britannici, olandesi e canadesi richiedono lettere.
• Usa token di completamento automatico appropriati per nomi e indirizzi. Esamina i campi effettivamente generati. Il form degli indirizzi moderno usa customer/_partials/address-form.tpl e il rendering condiviso dei campi, non un presunto file di input nelle parti del checkout.
• Usa controlli grandi e distanziati e righe di corriere/pagamento completamente etichettate. Un obiettivo di 44-48 pixel CSS è un'opzione pratica di progettazione; verifica dimensioni e spaziatura sui dispositivi reali.
• Mantieni facili da raggiungere totale aggiornato e percorso di revisione. Assicurati che i comandi fissi di invio non coprano condizioni, errori, chat o controlli del consenso.
• Conserva valori digitati, focus visibile e messaggi di errore specifici in linea.

Nel resto del negozio mobile, usa espansione del menu tramite tocco con link ai livelli superiori, un pannello filtri usabile, informazioni prodotto leggibili e popup chiudibili. Mantieni contenuti importanti e dati strutturati disponibili nel rendering mobile. Usa immagini responsive e caricamento differito sotto la piega senza ritardare l'immagine principale.

I link telefonici possono aiutare su mobile e sulle app di chiamata desktop supportate. Prodotti visualizzati di recente e aggiunta al carrello fissa sono opzioni da provare nel tema o modulo installato, non comportamenti nativi universali. Confronta uscite dalle categorie, scoperta dei prodotti e acquisti insieme al completamento del checkout.

Analizza le richieste del checkout su una copia di staging isolata. Hook dei moduli, chiamate esterne per tariffe/imposte/indirizzi, risoluzione dei corrieri, regole carrello, query del database e lavoro degli script sono possibili colli di bottiglia. Usa _PS_DEBUG_PROFILING_ solo dove l'output di debug è privato. Abilita cache e opzioni delle risorse in produzione solo dopo aver provato il flusso di pagamento risultante. Escludi risposte personalizzate di carrello, checkout e JSON dalle cache condivise di pagina intera/CDN.

Usa PageSpeed Insights/Lighthouse attuali, Search Console e test su dispositivi reali. Il vecchio Google Mobile-Friendly Test è stato dismesso. Prova condizioni di rete cellulare, telefoni supportati, completamento automatico attivo e disattivo, cambi di paese, ogni metodo di pagamento offerto, annullamento dell'autenticazione e nuovi tentativi. Una finestra desktop ridimensionata non prova la tastiera o il wallet reali.

Ripristina i carrelli e analizza gli errori di aggiornamento

I clienti autenticati possono recuperare carrelli aperti utilizzabili secondo il comportamento del carrello al login del negozio. Il recupero ospite dipende soprattutto dal cookie del browser che identifica il carrello. Cancellare cookie, cambiare dispositivo o usare sessioni private può interrompere l'associazione mentre la riga nel database esiste ancora. I carrelli già ordinati non sono più carrelli aperti.

PS_COOKIE_LIFETIME_FO controlla la durata del cookie del front office, non la conservazione dei carrelli nel database. Trova il campo corrispondente alla durata del cookie nell'amministrazione della tua versione e confermane il valore nel corretto contesto del negozio. Le impostazioni dei cookie sono state spostate tra pagine amministrative nelle diverse versioni.

1. Riproduci il problema con prodotto, combinazione, quantità, cliente e paese specifici, e annota URL e ora dell'errore. Apri Console e Network negli strumenti del browser.
2. Esamina richiesta e risposta del carrello. Uno stato 200 può contenere comunque un errore applicativo o HTML dove era atteso JSON. Un 500 richiede i log PHP/server; un 403 richiede controlli su token, permessi, WAF e sicurezza.
3. Ripeti la richiesta effettiva del browser solo in un contesto di test sicuro con i relativi cookie di sessione e il token attuale. Un esempio curl inventato con token statico non è un test affidabile del carrello.
4. Svuota le cache di template/risorse pertinenti da Parametri Avanzati > Prestazioni. Disabilita temporaneamente la combinazione delle risorse in staging se un bundle combinato nasconde l'errore.
5. Controlla dominio dei cookie, HTTPS, comportamento SameSite/Secure e l'eventuale archiviazione delle sessioni con bilanciamento del carico. Verifica la gestione di www e non-www.
6. Controlla gli hook dei moduli legati al carrello e isola i conflitti su una copia di staging con backup e piano di ripristino. Disabilita gruppi di moduli, poi restringi al modulo responsabile. Prova di nuovo le callback dei fornitori dopo la modifica.

Considera i risultati su dominio, cookie e moduli come piste d'indagine finché l'errore non si riproduce e la correzione non lo elimina. Dopo una correzione, rigenera o svuota la cache CDN/delle risorse pertinente. La cache condivisa deve escludere gli endpoint del carrello specifici del cliente. Un errore JavaScript può bloccare il flusso interessato, ma un solo errore non dimostra automaticamente che tutti gli script della pagina abbiano smesso di funzionare.

Proteggi il pagamento e recupera i carrelli abbandonati rimasti

Servi il checkout e le risorse del fornitore tramite HTTPS valido. Controlla contenuti misti, URL di ritorno e raggiungibilità delle callback. Preferisci campi ospitati dal fornitore o un checkout in hosting dove appropriato e tieni i dati grezzi delle carte fuori dai log dell'applicazione e dai form del negozio. Non aggiungere codice personalizzato che faccia passare i dati grezzi delle carte attraverso il tuo negozio.

L'ambito PCI dipende dall'implementazione completa. Iframe in hosting o reindirizzamenti non garantiscono da soli l'idoneità SAQ A. Per i form incorporati, i criteri SAQ A attuali includono la conferma che la pagina del commerciante non sia vulnerabile ad attacchi tramite script. Conferma la valutazione applicabile con l'ente che accetta la tua dichiarazione di conformità. Segui le indicazioni di idoneità PCI SSC; non decidere tra SAQ A e A-EP dalla sola presenza di JavaScript del fornitore.

I requisiti di Strong Customer Authentication prevedono esenzioni e transazioni fuori ambito. 3D Secure è un meccanismo supportato dalle integrazioni delle carte, non la normativa stessa. Alcune transazioni si completano senza una verifica visibile; altre richiedono autenticazione. Prova successo, rifiuto, annullamento, timeout e ritorno da una pagina di pagamento esterna.

La conservazione dei carrelli e le email di recupero sono funzioni separate. L'archiviazione nativa dei carrelli non invia automaticamente promemoria. Uno strumento dedicato o un'integrazione di marketing può fornire il recupero, nel rispetto delle regole applicabili sui messaggi e delle condizioni di consenso o di soft opt-in. Consulta la guida di Sales Revolution e la guida di Klaviyo Integration.

Un promemoria può aiutare un acquirente interrotto o che voleva più tempo. Può anche riportarlo allo stesso errore irrisolto. Correggi i guasti confermati del checkout e misura separatamente il recupero. Includi costi dei messaggi, sconti, evasione e assistenza nel valutare l'utile. Rispetta le rinunce e non supporre che un promemoria senza sconto sia puramente transazionale.

Prova il percorso d'ordine prima del passaggio live

Conserva una base di riferimento con data e ora e un percorso di ripristino per le modifiche al checkout. Prima di sostituire, disabilitare o disinstallare un modulo di checkout o di pagamento, esegui un backup di file e database, lavora su una copia di staging e prova il ritorno indietro. Isola lo staging da pagamenti reali, email ai clienti ed evasione degli ordini. Segui le istruzioni di rimozione del modulo e conserva i record e gli accessi necessari per pagamenti e rimborsi esistenti; la guida alla rimozione dei moduli spiega cosa conservare.

• Nuovo cliente: un acquisto come ospite, se previsto, poi un acquisto con registrazione, su smartphone e desktop. Controlla i campi obbligatori e i dati separati di consegna e fatturazione.
• Cliente di ritorno: selezione di un indirizzo salvato, modifica dell'indirizzo e qualsiasi flusso di pagamento salvato o wallet confermato dal fornitore.
• Prodotto e carrello: una combinazione, una personalizzazione obbligatoria e un carrello con più articoli. Verifica che una finestra express acquisti il contenuto previsto.
• Consegna e totali: cambia paese e corriere a metà percorso, applica un buono e controlla gli importi finali di imposte e consegna per ogni paese, valuta e gruppo di clienti che servi.
• Pagamento: successo, rifiuto, autenticazione completata e annullata, conferma differita, chiusura del browser e notifica ripetuta, usando la procedura di test supportata dal fornitore.
• Operazioni: totali, fatture, variazioni delle disponibilità, email di conferma, rimborsi, record del fornitore ed esportazioni verso contabilità o evasione, compresa qualsiasi integrazione personalizzata.

Giudica ogni scenario da questi record, non solo dalla schermata di conferma. Verifica che un pagamento rifiutato o un'autenticazione annullata mostrino un esito di pagamento chiaro, conservino il carrello previsto e permettano di riprovare o cambiare metodo senza un addebito duplicato involontario. Registra lo stato previsto dell'ordine e del pagamento per ogni metodo: un bonifico in attesa e un pagamento con carta confermato non dovrebbero avere la stessa aspettativa di evasione. Controlla esplicitamente la prevenzione degli ordini duplicati: aggiornare o rivisitare la pagina di conferma non deve creare un secondo ordine o addebito involontario.

Chiedi al fornitore prove, non un aggettivo sulla velocità

• Quale percorso usa i nostri moduli di pagamento attuali e quale l'integrazione di pagamento propria del modulo? Quali versioni esatte sono state controllate?
• Un pulsante nella pagina prodotto acquista l'articolo selezionato o il carrello, e come vengono ricontrollati varianti, personalizzazioni e un indirizzo modificato?
• Quale requisito di pagamento salvato o wallet è supportato e cosa succede dopo un'autenticazione rifiutata o annullata?
• Come riconcilia il personale un pagamento completato dopo la chiusura del browser e come ripristina il checkout precedente se i controlli al lancio non vengono superati?

Chiedi a un'agenzia di consegnare un inventario delle versioni, gli scenari d'acquisto concordati, le prove dei test, la configurazione salvata e i passaggi di ripristino, e di indicare chi gestisce pagamenti differiti, rimborsi e monitoraggio dopo il lancio.

Dopo il lancio, riconcilia i nuovi ordini con le transazioni del fornitore. Se diventa necessario tornare indietro, tieni conto delle vendite successive al backup prima di ripristinare un database. Confronta ordini pagati completati, pagamenti falliti e problemi di assistenza per dispositivo e tipo di cliente con la tua base di riferimento.

Domande dei titolari di negozi

In PrestaShop è possibile un checkout con un clic?

Una sola azione può effettuare un ordine quando identità, indirizzo, consegna e modalità di pagamento sono già risolti. I flussi di pagamento salvato richiedono un riutilizzo supportato e l'autorizzazione del cliente; un metodo offline può creare un ordine non pagato senza dati di carta riutilizzabili. Anche così, un indirizzo modificato, un corriere non disponibile o una richiesta di autenticazione bancaria aggiungono un passaggio, quindi descrivi il checkout come rapido senza promettere lo stesso numero di azioni a ogni acquirente.

Un negozio con soprattutto nuovi clienti deve puntare a un clic?

Inizia con l'ordine come ospite dove appropriato, totali mostrati presto e un form usabile, poi prova un wallet supportato. Una scorciatoia per i clienti di ritorno risolve poco di ciò che affronta chi acquista per la prima volta.

Installare ps_checkout ci darà un checkout su una pagina?

No. Aggiunge opzioni di pagamento basate su PayPal al passaggio di pagamento. Sulla 9.2 la questione del layout spetta al modulo nativo su una pagina; nelle versioni precedenti a un modulo di checkout o a uno sviluppo personalizzato.

Ci servono sia Checkout Revolution sia Express Checkout?

Di solito no. Entrambi offrono una finestra d'acquisto su pagine prodotto, elenchi e carrello, ed entrambi trasformano in ordine un pagamento completato dopo la chiusura del browser. Scegli in base al requisito: un'unica pagina con i tuoi corrieri e pagamenti esistenti, oppure una finestra d'acquisto basata su Stripe; nessuna delle due descrizioni stabilisce che funzionino insieme, quindi prova la combinazione in staging prima di attivarli entrambi.