Quando il pagamento non passa su un negozio PrestaShop, il rischio non è solo tecnico. Il rischio immediato sono gli ordini persi mentre provi troppe piste contemporaneamente.
La cosa più utile è procedere con un ordine breve: sintomo preciso, modalità test o produzione, chiavi API, notifiche o webhooks, compatibilità dopo aggiornamenti, poi i log. Alla fine di questa guida saprai cosa controllare senza confondere il diagnosi, cosa fare subito per limitare le perdite e quando passare a un intervento per bug di pagamento PrestaShop.
Inizia identificando il tipo di guasto
Prima di qualsiasi azione, separa il guasto in famiglie di sintomi. Un metodo di pagamento scomparso, un clic che fallisce e un pagamento accettato senza ordine hanno logiche tecniche diverse. Se mescoli questi casi rischi di correggere lo strato sbagliato.
Questa fase ti aiuta anche a capire se hai davanti un problema di visualizzazione del metodo di pagamento, un blocco nel funnel o un difetto di ritorno tra il PSP e il negozio. Se il dubbio riguarda l’intero funnel, guarda anche i guasti del carrello e del checkout PrestaShop.
Il metodo di pagamento è scomparso nella fase d'ordine
Qui il cliente non raggiunge nemmeno la fase di conferma del pagamento. Il sintomo è visivo: il metodo non appare più, o appare solo in alcuni percorsi. Annotati subito se la scomparsa riguarda tutti i clienti, tutti i vettori, tutti i paesi o solo un caso preciso.
In questa situazione non partire subito dai webhooks. Verifica prima cosa controlla la visualizzazione del metodo di pagamento: stato del modulo, modifica recente della configurazione e variazione del funnel lato negozio.
Il bottone è visibile ma il pagamento fallisce al clic o alla redirezione
Secondo caso: il metodo è lì, ma il clic restituisce un errore, un loop, una redirezione fallita o un rifiuto immediato. Qui le cause da controllare per prime sono la modalità test o produzione, poi le credenziali API.
Non concludere troppo in fretta che il modulo sia difettoso. Un ambiente sbagliato o una chiave incoerente può produrre esattamente questo tipo di sintomo.
Il pagamento è accettato dal PSP ma l'ordine non appare in PrestaShop
È il caso più delicato. Il cliente ha pagato, il prestatore indica un'operazione accettata, ma nessun ordine viene creato o lo stato dell'ordine resta incoerente. Qui bisogna pensare al ritorno tecnico del PSP verso PrestaShop, non solo al clic di pagamento.
Il buon riflesso è mettere da parte la questione del front-office e controllare notifiche, webhooks e log di eventi.
Verifica prima la modalità test o produzione, poi le chiavi API
Questo è il primo filtro da applicare. Finché non hai validato l’ambiente e le credenziali, è troppo presto per incolpare un aggiornamento o un bug più profondo. Questo controllo richiede poco tempo ed evita molti avanti‑indietro.
Individuare un mix tra test e produzione
Il classico tranello è semplice: un modulo impostato in produzione con credenziali di test, o viceversa. PayPal segnala allo stesso modo che un mix tra sandbox e produzione è causa comune di errori di autenticazione o configurazione. Stripe distingue chiaramente le chiavi di test e produzione nella sua documentazione ufficiale Authentication | Stripe API Reference (consultato il 27/10/2026).
Su Stripe, una chiave segreta di test inizia con sk_test_, una chiave live con sk_live_ e una chiave ristrette live con rk_live_. Se questi prefissi non corrispondono alla modalità attiva nel modulo, hai una pista solida.
Controllare le chiavi e le credenziali senza confonderle
Confronta ciò che è registrato nel modulo con ciò che è previsto nell'ambiente corretto del conto PSP. Lo scopo non è sostituire valori a caso, ma verificare che ogni identificativo corrisponda davvero alla modalità attiva.
Lavora in modo ordinato. Annota le impostazioni presenti prima di qualsiasi modifica. Così puoi tornare allo stato funzionale precedente se necessario.
Verificare se una modifica recente ha riscritto la configurazione
Se il guasto è apparso subito dopo un intervento, un aggiornamento o una migrazione, considera l'ipotesi che una impostazione sia stata alterata. Un modulo di pagamento può restare attivo pur avendo perso parte della sua configurazione.
Fatti una domanda semplice: cosa è cambiato dall'ultimo pagamento andato a buon fine? Questa fase evita di lanciare un'indagine troppo ampia.
Se il pagamento parte ma l'ordine non arriva, controlla notifiche e webhooks
Quando il cliente paga ma PrestaShop non crea l'ordine, il problema non sempre è al momento del clic. Può essere nel ritorno d'informazione che il prestatore invia al negozio. Questo tipo di incidente va quindi trattato a parte.
Cosa rompe davvero un webhook mancante
Un webhook che non arriva, che risponde male o che punta a un'URL sbagliata può impedire al negozio di ricevere l'informazione attesa dopo il pagamento. Per PayPal la documentazione precisa che un'URL di webhook deve essere registrata, legata a un abbonamento di eventi, avere un Webhook ID, ascoltare in HTTPS sulla porta 443 e rispondere con uno status HTTP 2xx. Altrimenti PayPal ritenta l'invio fino a 25 volte in 3 giorni Integrate webhooks | PayPal Developer (aggiornato il 18/06/2026).
In altre parole, un pagamento può sembrare concluso lato PSP mentre il negozio non ha ricevuto, o non ha validato correttamente, l'evento che doveva creare o aggiornare l'ordine.
Cosa verificare lato PayPal
Controlla prima l'URL effettivamente dichiarata, poi l'abbonamento agli eventi attesi e infine l'identificativo del webhook usato dal modulo. Se il modulo verifica la firma, deve fare riferimento al giusto Webhook ID e al corpo grezzo della richiesta.
Non limitarti alla sola presenza del webhook. Un webhook esistente ma mal collegato o che non risponde correttamente produce spesso lo stesso risultato: pagamento ricevuto, ordine assente o incompleto.
Perché una simulazione non basta
Un test simulato può dare rassicurazione fuorviante. Può aiutare a validare un listener, ma non dimostra che i veri eventi di produzione arrivino realmente fino al modulo nella tua catena reale.
Se hai dubbi, parti da una transazione recente, cerca l'evento reale lato prestatore e confrontalo con quello che il negozio ha registrato. È il controllo più affidabile.
Controlla poi cosa è cambiato immediatamente prima della panne
Un guasto al pagamento che compare senza causa apparente spesso segue una modifica recente: aggiornamento di PrestaShop, aggiornamento del modulo, riattivazione di un'impostazione o cambiamento dell'ambiente. Il più efficace è quindi esaminare la storia immediata.
Dopo un aggiornamento di PrestaShop, ricontrolla il Module Manager
La documentazione ufficiale PrestaShop raccomanda, dopo un aggiornamento, di verificare il Module Manager, riattivare i moduli disattivati se necessario e poi testare il front-office con un vero percorso d'ordine Post-update checklist | PrestaShop Developer Documentation (consultato il 27/10/2026).
Su un negozio in produzione, verifica se il modulo di pagamento è stato disattivato, se un altro modulo del tunnel è cambiato di stato e se il problema è comparso subito dopo quell'intervento.
Rileggi la compatibilità e le impostazioni sensibili del modulo
Se il guasto è iniziato dopo un'evoluzione del negozio, confronta la versione di PrestaShop con la compatibilità dichiarata del modulo e rileggi le impostazioni sensibili. Un modulo dichiarato compatibile con una versione non è automaticamente affidabile dopo ogni aggiornamento.
Se vuoi individuare questo rischio prima che rompa il funnel, leggi anche i segnali di un modulo PrestaShop mal codificato.
Testa tutto il funnel, non solo il pulsante di pagamento
Un modulo può sembrare attivo e tuttavia fallire solo nel percorso reale. Per questo un test completo del funnel è utile dopo un aggiornamento: carrello, indirizzo, vettore, pagamento e ritorno di conferma.
Evita anche la formula vaga tipo “l'aggiornamento ha rotto i pagamenti”. La domanda giusta è più precisa: quale modifica ha reso questo modulo, in questo funnel, incompatibile o mal configurato?
Leggi i log utili prima di attivare il debug ovunque
Quando i controlli precedenti non danno risultati, passa ai log. È la fase che permette di tornare ai fatti: messaggio d'errore, istante esatto e componente coinvolto. PrestaShop offre una pagina Logs nel back-office per consultare errori e azioni del negozio Logs | PrestaShop 8 documentation (consultato il 27/10/2026).
Dove cercare per primo
Inizia annotando l'ora di un fallimento reale, poi cerca quella fascia temporale nei log del negozio e nei registri del modulo se il PSP li fornisce. Lo scopo non è leggere tutto il diario, ma correlare un tentativo preciso con un messaggio specifico.
Se il guasto fa emergere un errore server più ampio, il metodo assomiglia a quello di un diagnostico di errore 500 su PrestaShop: isolare l'istante, il componente e la modifica recente.
Quando attivare la modalità debug
La modalità debug può aiutare, ma non è il primo strumento. Attivala solo se i log non sono sufficienti e solo per il tempo del diagnostic. La documentazione PrestaShop precisa che impatta significativamente le prestazioni. Appena ottieni il messaggio utile, disattivala.
Questa regola è importante in produzione: il debug deve confermare una pista, non sostituire il metodo di triage.
Cosa correlare tra negozio, modulo e PSP
Un buon diagnostico non si basa su una sola fonte. Verifica insieme l'ora dell'azione cliente, l'eventuale errore lato negozio, lo stato riportato dal modulo e l'evento visibile lato PSP. Senza questa correlazione puoi confondere un rifiuto al clic con un'assenza di webhook.
A questo punto resisti alla tentazione di disattivare più moduli in produzione “per vedere”. Confonderesti il diagnostico e perderesti la traccia della causa iniziale.
Durante il guasto, limita le perdite e decidi velocemente se salire di livello
Durante l'incidente l'obiettivo è duplice: evitare di peggiorare la situazione e mantenere tracce utili dei pagamenti in sospeso.
- Disattiva solo il metodo di pagamento difettoso se genera errori ripetuti. Non toccare più moduli contemporaneamente.
- Se un altro metodo di pagamento è disponibile, lascialo attivo per ridurre la perdita immediata.
- Mostra un messaggio breve e chiaro al checkout per spiegare che un incidente temporaneo interessa un metodo di pagamento specifico.
- Monitora i pagamenti catturati senza ordine e prepara una lista semplice: ora, importo, cliente, stato lato PSP, stato lato PrestaShop.
- Riconcilia manualmente i casi in sospeso finché la catena automatica non è affidabile.
Se il triage in questo ordine non basta, è preferibile passare a un intervento mirato. KLN-WEB offre supporto PrestaShop una tantum o mensile, con diagnosi gratuita, risposta entro 24 h e preventivo in 24 h lavorative.
Domande frequenti
Perché il modulo di pagamento è scomparso nella fase d'ordine su PrestaShop?
Quando il metodo di pagamento scompare, tratta prima il problema come un difetto di visualizzazione o disponibilità nel funnel, non come un problema di webhook. Verifica se la scomparsa riguarda tutti i clienti o solo certi percorsi. Distinguere questo caso dal pagamento accettato senza ordine evita ricerche nel posto sbagliato.
Come capire se il mio modulo è rimasto in modalità test invece che produzione?
Confronta la modalità attivata nel modulo con l'ambiente usato nel tuo account PSP. Su Stripe le chiavi segrete di test iniziano con sk_test_ e le chiavi live con sk_live_. Se il modulo è in produzione con chiavi di test, o viceversa, il pagamento può fallire subito anche se la configurazione sembra corretta.
Dove controllare le chiavi API Stripe o PayPal quando il pagamento non passa?
Il controllo va fatto in due posti: nella configurazione del modulo in PrestaShop e nell'ambiente corretto dell'account Stripe o PayPal. L'essenziale è la coerenza tra la modalità attiva e le credenziali registrate. Prima di modificare, annota le impostazioni per poter tornare allo stato precedente.
Perché il pagamento è accettato lato banca o PSP ma l'ordine non appare in PrestaShop?
Questo caso indica spesso un problema di ritorno tecnico tra il prestatore e il negozio. Occorre controllare notifiche o webhooks, l'URL dichiarata, l'abbonamento agli eventi attesi e come il modulo gestisce quel ritorno. Un pagamento validato lato PSP non garantisce che PrestaShop abbia ricevuto l'evento necessario alla creazione dell'ordine.
Cosa controllare subito dopo un aggiornamento di PrestaShop o del modulo di pagamento?
Dopo un aggiornamento verifica prima lo stato del modulo nel Module Manager, poi la compatibilità dichiarata con la versione del negozio. Poi testa un vero percorso d'ordine sul front-office. L'importante è non concludere prematuramente che l'aggiornamento abbia “rotto” i pagamenti senza aver identificato l'impostazione o l'incompatibilità responsabile.
Dove trovare i log utili in PrestaShop per diagnosticare un fallimento di pagamento?
PrestaShop offre una pagina Logs nel back-office. Usala con metodo: annota l'ora esatta di un fallimento, poi cerca le voci corrispondenti nei log del negozio, del modulo e del prestatore se disponibili. Se attivi la modalità debug, fallo solo per il tempo del diagnostic e poi disattivala subito.