In breve
La prima diagnosi mette in relazione cliente, ordine, tentativo di pagamento e incasso. Solo dopo questa ricostruzione si decide quale operazione correggere.
- Distinguere autorizzazione, incasso e rimborso.
- Confrontare ordini e identificativi delle transazioni.
- Gestire i nuovi tentativi senza duplicare le operazioni.
- Provare timeout, ritorno dal pagamento e notifiche ripetute.
Distinguere due movimenti da due incassi
Un’autorizzazione riserva un importo; l’acquisizione, o cattura, è il passaggio con cui il pagamento viene incassato. In alcuni flussi avvengono separatamente. Stripe spiega questa distinzione e segnala che alcune interfacce bancarie non la mostrano chiaramente. Non dedurre quindi l’esito da una sola schermata: cerca nel pannello del gestore lo stato, l’importo acquisito e l’eventuale annullamento.
Due acquisizioni possono anche appartenere a ordini separati o a un piano di pagamento previsto. Verifica importi, valuta e riferimenti prima di definirle duplicate. Se il gestore mostra un solo incasso ma il cliente ne vede due, apri una verifica con l’assistenza del servizio, fornendo gli identificativi disponibili. Evita di promettere tempi universali di sblocco: dipendono dal metodo, dal circuito e dalla situazione concreta.
Preparare una scheda dell’incidente
Assegna un referente alla segnalazione e registra ciò che è già verificato, separandolo da quello che il cliente riferisce. Annota data e ora con fuso, numero d’ordine, importo, metodo, identificativi delle transazioni e sequenza delle azioni. Un acquisto ritentato dopo una schermata bloccata è diverso da un addebito ricorrente o da un ordine duplicato da un’integrazione.
Chiedi solo i dati necessari al confronto. Non servono numeri completi della carta, codici di sicurezza o credenziali bancarie. Conserva eventuali schermate oscurando i dettagli estranei alla diagnosi e limita l’accesso al personale incaricato. Se il pagamento risulta acquisito ma manca del tutto l’ordine, segui anche il percorso dedicato a pagamento riuscito e ordine assente: è un problema correlato, con una verifica diversa.
Confrontare negozio, gestore e magazzino
Per ogni ordine cerca tutte le transazioni collegate, comprese quelle fallite o ancora in elaborazione. Poi fai il controllo inverso: ogni incasso deve ricondurre a un ordine o a un’operazione spiegabile. La tabella serve a scegliere la verifica successiva; non sostituisce la lettura degli eventi registrati dal gestore.
| Situazione | Controllo decisivo | Attenzione operativa |
|---|---|---|
| Un ordine, due movimenti | Stato e importo acquisito di ciascuna transazione | Non confondere un’autorizzazione con un secondo incasso |
| Due ordini, un incasso | Riferimento del pagamento associato agli ordini | Evitare una seconda spedizione |
| Due ordini, due incassi | Sequenza dei tentativi e intenzione del cliente | Distinguere acquisto ripetuto ed errore del flusso |
Controlla anche prenotazioni di stock, documenti ed email: correggere il pagamento lasciando due consegne aperte mantiene il problema operativo.
Verificare doppi clic, timeout e nuovi tentativi
Disabilitare il pulsante dopo il clic rende il percorso più chiaro, ma il controllo deve esistere anche sul server. Una risposta lenta può indurre il cliente a ricaricare la pagina o il sistema a ripetere una richiesta. Chi sviluppa deve stabilire quando si sta riprovando la stessa operazione e quando inizia davvero un nuovo pagamento.
Nei sistemi che la supportano, una chiave di idempotenza permette di riconoscere i tentativi della stessa richiesta. È il comportamento descritto dalla documentazione Stripe sulle richieste idempotenti. La chiave va progettata nel contesto del flusso e non riutilizzata indiscriminatamente per acquisti diversi. Per i PaymentIntent, Stripe raccomanda un riferimento per ordine o sessione. Il controllo concreto dipende dal plugin e dall’integrazione presenti nel negozio.
Controllare le notifiche e i cambi di stato
Il ritorno del browser alla pagina di conferma e la notifica inviata dal gestore al server possono arrivare in momenti diversi. Una notifica, spesso chiamata webhook, può inoltre essere consegnata più volte. La documentazione Stripe sui webhook descrive la gestione degli eventi duplicati. Ricevere due notifiche non significa aver incassato due volte.
Il team tecnico deve verificare che lo stesso evento non crei un nuovo ordine, ripeta la cattura o avvii un’altra spedizione. Controlla identificativi già elaborati, passaggi di stato consentiti e registrazione degli errori. Su WooCommerce raccogli note ordine, versione del gateway e log pertinenti prima di intervenire sui plugin. Gli aggiornamenti o le prove vanno eseguiti in un ambiente separato, mantenendo in produzione una gestione controllata degli ordini coinvolti.
Correggere il caso e dare una risposta precisa
Spiega al cliente quale ordine è stato identificato, che cosa risulta dal gestore e quale verifica rimane aperta. Una risposta come “abbiamo trovato un incasso e un’autorizzazione” è utile soltanto se confermata dai dati. Se il duplicato è accertato, il responsabile autorizzato del negozio deve gestire l’operazione appropriata attraverso il servizio di pagamento, coordinandola con eventuali rimborsi o contestazioni già aperti.
Evita correzioni parallele eseguite da persone diverse. Registra il riferimento dell’intervento, aggiorna lo stato dell’ordine interessato e controlla gli effetti su stock e spedizione. Non cancellare le tracce necessarie alla ricostruzione. Il cliente deve ricevere un riscontro coerente dal negozio e dall’assistenza, senza essere invitato a ripetere l’acquisto mentre l’esito del precedente è ancora incerto.
Un esempio di ricostruzione del problema
Esempio ipotetico: dopo il pagamento il telefono perde la connessione. Il cliente torna al carrello e riprova. Il negozio mostra due ordini uguali. Se il gestore contiene una sola transazione acquisita, il difetto può riguardare la creazione o l’associazione degli ordini. Se contiene due incassi distinti, occorre ricostruire perché il secondo tentativo sia stato trattato come un nuovo acquisto.
Il risultato atteso della verifica è una linea temporale: primo ordine, richiesta al gestore, risposta o timeout, secondo tentativo, notifiche e azioni successive. Questa sequenza permette di correggere il punto preciso. Cambiare genericamente il testo del pulsante o svuotare la cache non dimostra che il percorso sia diventato affidabile.
Collaudare i casi che possono ripresentarsi
In modalità di test prova il flusso completo, verificando sia ciò che vede il cliente sia gli effetti sul pannello amministrativo. Per ogni prova definisci prima quanti ordini, incassi, email e movimenti di magazzino sono attesi.
- Doppio clic ravvicinato e ricaricamento della pagina.
- Connessione interrotta dopo l’autorizzazione.
- Ritorno tardivo dalla pagina del gestore.
- Stessa notifica ricevuta più volte.
- Nuovo tentativo dopo un pagamento realmente fallito.
- Annullamento o rimborso già avviato da un operatore.
Dopo la correzione controlla i nuovi casi e conserva una procedura breve per l’assistenza. La guida sui pagamenti rifiutati aiuta a distinguere i fallimenti dai tentativi ancora in corso.
Domande frequenti
Due email di conferma indicano due addebiti?
No. Possono derivare da notifiche duplicate o da due ordini associati allo stesso pagamento. Occorre confrontare gli identificativi e gli importi acquisiti nel gestore.
Basta bloccare il secondo clic sul pulsante?
Il blocco aiuta l’utente, ma non copre richieste ripetute dal server, connessioni interrotte o notifiche duplicate. Serve una verifica dell’intero flusso.
Fonti e approfondimenti
Documentazione ufficiale per gli aspetti tecnici richiamati nella guida.
