Pagamenti WooCommerce falliti: come capire perché un ordine viene rifiutato o resta in attesa

Quando un cliente segnala un pagamento non riuscito, non chiedergli subito di riprovare e non modificare manualmente lo stato dell’ordine. Prima controlla l’esito reale nel pannello del gateway di pagamento.

Un ordine Fallito, In attesa di pagamento o In sospeso può dipendere da cause molto diverse: pagamento rifiutato, autorizzazione non ancora acquisita oppure pagamento acquisito dal provider ma non registrato correttamente in WooCommerce. Trattare questi casi allo stesso modo può portare a doppi addebiti, spedizioni senza incasso o riconciliazioni errate.

Controllo rapido: cosa fare prima di intervenire sull’ordine

1. Cerca la transazione nel gateway usando ID ordine, importo, valuta, orario e identificativo della transazione.
2. Se non esiste alcuna transazione, il problema è probabilmente avvenuto prima che la richiesta raggiungesse il provider: verifica checkout, errori JavaScript e richieste di rete.
3. Se la transazione è rifiutata, non forzare l’ordine su Processing: comunica al cliente il mancato pagamento e proponi un nuovo tentativo o un metodo alternativo.
4. Se è acquisita o completata, non richiedere un nuovo pagamento: controlla webhook, note e log per capire perché WooCommerce non ha aggiornato l’ordine.

Se il gateway mostra una transazione solo Authorized, verifica anche che l’autorizzazione sia ancora attiva e catturabile. Un’autorizzazione può essere annullata, scaduta o non più acquisibile; in quel caso potrebbe essere necessario un nuovo tentativo di pagamento.

Prima verifica: il denaro è stato rifiutato, autorizzato o incassato?

Il dashboard del gateway è la fonte principale per stabilire che cosa sia accaduto al denaro. WooCommerce mostra lo stato elaborato dal negozio, ma non sostituisce il dato della transazione presso Stripe, PayPal, il provider bancario o un altro gestore di pagamenti.

I dati da raccogliere

Annota numero dell’ordine, data e ora del tentativo con relativo fuso orario, importo, valuta, metodo di pagamento ed email del cliente. Recupera anche gli identificativi presenti nelle note dell’ordine: transaction ID, Payment Intent, Charge, Capture o equivalenti.

L’ID ordine e l’importo non sempre bastano: il cliente può avere effettuato più tentativi con lo stesso totale. Associare l’ordine al tentativo sbagliato è un errore frequente durante l’assistenza.

Sequenza di controllo

1. Apri l’ordine WooCommerce e leggi le note: cerca risposte del gateway, codici di errore, ID transazione e variazioni di stato.
2. Cerca la transazione nel dashboard del gateway usando prima gli identificativi disponibili, poi importo, valuta e orario.
3. Stabilisci se l’operazione è assente, rifiutata, autorizzata, acquisita o completata.
4. Se il gateway riporta un esito positivo ma WooCommerce non avanza, verifica notifiche webhook o callback e i log dell’estensione.

Il ritorno del cliente alla pagina di conferma non dimostra da solo l’avvenuto incasso. Nei flussi con reindirizzamento, 3D Secure o conferme differite, l’aggiornamento dell’ordine può dipendere da una notifica inviata dal provider al sito.

Cosa indicano gli stati dell’ordine WooCommerce

Gli stati aiutano a orientarsi, ma non sono una prova assoluta dell’esito finanziario. Il comportamento può cambiare in base al gateway, alle sue impostazioni e al metodo di pagamento. La definizione degli stati standard è disponibile nella documentazione WooCommerce sugli stati degli ordini.

 
Un ordine On hold non è necessariamente un errore. Bonifico, assegno, controlli antifrode, alcuni metodi locali o pagamenti differiti possono richiedere un’azione successiva. Solo alcuni gateway o configurazioni possono usare questo stato anche per una preautorizzazione senza cattura.

Con il Checkout Block possono comparire bozze o aggiornamenti di ordini pending e failed durante un nuovo tentativo nella stessa sessione. La presenza di più ordini non dimostra quindi, da sola, che siano avvenuti più addebiti.

Diagnosi per scenario: dove si è interrotto il pagamento

Nessuna transazione nel gateway

Se nel gateway non esiste alcuna transazione e nelle note non compare una risposta dell’estensione, la richiesta potrebbe non essere mai arrivata al provider. I sintomi più utili da osservare sono un pulsante di pagamento che non produce richieste, uno spinner che non termina, un errore JavaScript o una richiesta checkout con risposta anomala.

Durante un test controllato, apri gli strumenti per sviluppatori del browser e verifica prima la console, poi la scheda Network. Cerca errori JavaScript e richieste AJAX o Store API fallite. Se il problema è riproducibile, testalo in staging mantenendo attivi WooCommerce e il gateway.

Solo dopo aver raccolto questo dato, escludi una variabile alla volta: prima cache e ottimizzazioni JavaScript, poi personalizzazioni del tema o altri plugin. Se usi il Checkout Block, controlla inoltre che il gateway dichiari la compatibilità con quel checkout. Per problemi specifici di Stripe, WooCommerce fornisce indicazioni sul checkout che non si carica.

Transazione rifiutata dal gateway o dalla banca

Se l’ordine è Failed e il dashboard riporta declined o failed, il rifiuto è reale. Il provider può indicare, per esempio, fondi insufficienti, carta scaduta, CVC errato, limiti della carta, blocco dell’emittente, controlli antifrode o dati non accettati.

Un ordine Fallito con un codice equivalente a insufficient_funds non va impostato manualmente su Processing: non esiste un pagamento confermato da evadere. Mostra un messaggio comprensibile e consenti al cliente di usare un altro metodo, se disponibile. Stripe documenta scenari di rifiuto e carte di prova nella guida ai test dei pagamenti. Per PayPal, il trattamento dei rifiuti dipende dall’esito restituito dal servizio e dall’integrazione usata.

3D Secure non completato o pagamento rifiutato dopo la challenge

Non usare “3D Secure fallito” come spiegazione generica. La challenge può non essere richiesta, essere completata, essere abbandonata dal cliente oppure interrompersi nel checkout.

Un’autenticazione 3D Secure completata non equivale automaticamente a un pagamento acquisito: il gateway può ancora rifiutare l’autorizzazione o la cattura. Nel dashboard verifica separatamente l’esito dell’autenticazione e quello della transazione. Stripe descrive il flusso e i relativi casi di test nella documentazione su 3D Secure.

Autorizzato non significa incassato

Con una configurazione Authorize Only, il gateway può bloccare temporaneamente l’importo senza acquisirlo. A seconda dell’integrazione, WooCommerce può lasciare l’ordine in attesa, in sospeso o assegnare un altro stato previsto dal gateway.

Prima di spedire, verifica nel dashboard se l’operazione è solo autorizzata oppure acquisita. Controlla anche data di scadenza e possibilità effettiva di cattura. Segui poi la procedura prevista dal provider e dalla politica del negozio: acquisisci l’importo, annulla l’autorizzazione oppure, se l’autorizzazione non è più valida, richiedi un nuovo pagamento. Una preautorizzazione visibile nell’estratto conto del cliente non prova che il denaro sia stato incassato.

Pagamento acquisito ma ordine ancora in attesa: webhook, callback e log

Se il gateway mostra un pagamento acquisito o completato ma WooCommerce resta Pending payment, il sito potrebbe non avere elaborato la notifica del provider. Di conseguenza, stock, email e flusso di evasione potrebbero non essersi aggiornati.

Come controllare una notifica

Nel dashboard del gateway verifica endpoint configurato, ambiente live o test, evento inviato, orario, tentativi di consegna e codice HTTP ricevuto. Una risposta 2xx conferma soltanto che il provider ha ricevuto una risposta HTTP dall’endpoint; non prova da sola che WordPress o l’estensione abbiano validato, associato e applicato correttamente l’evento all’ordine.

Confronta quindi l’orario della notifica con le note dell’ordine e i log dell’estensione. Per Stripe, verifica anche che l’evento sia stato firmato e validato tramite l’header Stripe-Signature e il webhook secret corretto. La documentazione Stripe sui webhook spiega i requisiti di verifica della firma e le consegne degli eventi.

Un 403 può indicare un blocco o un problema di autorizzazione, un 404 un endpoint non raggiunto o errato, un 500 un errore dell’applicazione. In tutti i casi, controlla anche ciò che WooCommerce ha registrato: una consegna apparentemente riuscita può comunque essere ignorata per firma non valida, ID non riconosciuto o altra logica dell’estensione.

Cause comuni e verifiche utili

Firewall, WAF, CDN, autenticazione HTTP, certificato SSL non valido, dominio non aggiornato dopo una migrazione o regole errate sugli endpoint possono impedire la consegna delle notifiche. Se il gateway indica un pagamento acquisito e WooCommerce non è aggiornato, riconcilia l’ordine in base alla transazione reale prima di eseguire altre azioni sul pagamento.

Le procedure per Stripe e PayPal dipendono dall’estensione installata e dalla sua versione. Per WooCommerce Stripe consulta la pagina dedicata alla configurazione dei webhook e il relativo troubleshooting. Per WooCommerce PayPal Payments usa invece la documentazione di risoluzione dei problemi dell’estensione: non assumere che le voci o gli strumenti disponibili siano identici tra integrazioni diverse.

Log, azioni pianificate e test controllati

Dove cercare le evidenze

Dopo il controllo del gateway, segui questo ordine: note dell’ordine, log dell’estensione in WooCommerce → Stato → Log, cronologia delle consegne nel provider, log fatal-errors, log PHP o del server. Per un problema precedente alla richiesta al gateway, torna invece alla console e alla scheda Network del browser.

La documentazione sul System Status di WooCommerce indica dove reperire informazioni diagnostiche; per gli errori del server può essere utile anche la guida WooCommerce per individuare i log PHP.

Attiva i log prima di riprodurre il problema e riducili o disattivali dopo la diagnosi. Prima di condividerli, oscura chiavi API, webhook secret, token, dati personali e identificativi non necessari.

Quando controllare le azioni pianificate

Controlla WooCommerce → Stato → Azioni pianificate soltanto se il gateway usa elaborazioni in background oppure se trovi azioni scadute, Failed o Pending da tempo. La documentazione WooCommerce sulle azioni pianificate spiega come leggerne lo stato.

Non attribuire automaticamente un webhook non elaborato a WP-Cron: verifica prima se il provider ha consegnato l’evento e quale risposta ha ricevuto. Compatibilità con HPOS, conflitti tra plugin e codice personalizzato diventano piste più concrete se il problema è iniziato dopo un aggiornamento, una migrazione o l’attivazione di una nuova estensione.

Riprodurre senza rischiare nuovi addebiti

Usa staging o sandbox e carte o scenari di test ufficiali del provider. Evita come primo intervento la reinstallazione del plugin, la rigenerazione indiscriminata delle chiavi o la disattivazione del gateway in produzione: potresti perdere evidenze utili o interrompere acquisti legittimi.

Coinvolgi un tecnico WooCommerce quando il checkout restituisce un errore riproducibile, il provider registra webhook con errori 4xx o 5xx, un pagamento acquisito non aggiorna l’ordine oppure i log mostrano errori PHP associati al gateway. In questi casi, l’analisi congiunta di transazione, note dell’ordine, log e infrastruttura consente di correggere la causa senza creare ulteriori incongruenze.