Che stati ordine include WooCommerce e cosa rappresentano (panoramica core)
WooCommerce include di default una serie di stati ordine core: Pending payment (In attesa di pagamento), Processing (In lavorazione), On-Hold (In sospeso), Completed (Completato), Cancelled (Annullato), Refunded (Rimborsato) e Failed (Non riuscito).
Brevi definizioni pratiche:
- Pending payment: ordine creato ma pagamento non ancora confermato; considerato non pagato.
- Processing: pagamento ricevuto e ordine pronto per evasione; normalmente lo stock è già ridotto.
- On-Hold: stato usato quando il pagamento richiede verifica o il metodo è offline.
- Completed: ordine evaso o prodotto digitale rilasciato; non sono richieste ulteriori azioni amministrative.
- Cancelled: ordine annullato dall’amministratore o dal cliente.
- Refunded: indica che il pagamento è stato restituito (totale o parziale).
- Failed: tentativo di pagamento non andato a buon fine.
Evita sinonimi non ufficiali nelle procedure interne: usa le etichette core quando comunichi con team e integrazioni per non generare ambiguità.
Stati che riflettono esito o attesa del pagamento (Pending, On-Hold, Failed)
Gli stati Pending payment, On-Hold e Failed sono quelli che più direttamente riflettono un’attesa o l’esito del processo di pagamento.
Quando si utilizzano gateway asincroni (ad esempio che inviano webhooks o IPN), un ordine può rimanere in Pending payment finché il gateway non notifica il successo del pagamento: l’assenza di webhook/IPN può quindi lasciare l’ordine bloccato in Pending.
Esempio operativo:
- Caso tipico: il cliente completa il pagamento con un gateway che invia conferma via webhook; fino alla notifica l’ordine resta Pending. Se il webhook non arriva, diagnostica i log e le order notes prima di aggiornare manualmente lo stato.
Avvertenza: non cambiare lo stato manualmente come prima azione senza investigare logs e webhook, perché potresti nascondere un problema di integrazione.
Processing vs Completed: differenze pratiche e quando usare ciascuno
Processing significa che il pagamento è stato ricevuto e l’ordine è pronto per essere evaso; non implica automaticamente che l’ordine sia stato spedito o che il cliente abbia ricevuto il prodotto.
Completed indica che l’ordine è stato evaso (per prodotti fisici) o che il download è stato reso disponibile (per prodotti digitali).
Quando si può auto-completare:
- Prodotti virtuali/downloadable possono essere autocompletati perché non richiedono spedizione fisica; in questi casi lo stato può passare direttamente a Completed.
- L’estensione Order Status Control consente di impostare regole per auto-completare ordini pagati (saltando Processing), ma l’auto-complete avviene solo se il metodo di pagamento chiama la funzione che marca l’ordine come pagato (woocommerce_payment_complete / $order->payment_complete()).
Consiglio operativo: per store con prodotti fisici, mantieni Processing fino alla conferma di evasione per evitare rilasci prematuri di ordini e incoerenze operative.
Cancelled vs Refunded: cosa significano davvero e come gestire i rimborsi
Cancelled e Refunded sono concetti distinti: Cancelled è l’annullamento dell’ordine; Refunded indica che (almeno in registrazione) il pagamento è stato restituito, in tutto o in parte.
Importante: cambiare lo stato in Refunded o Cancelled non esegue necessariamente l’operazione finanziaria sul gateway. I rimborsi possono essere automatici o manuali a seconda del gateway e della sua integrazione; pertanto è necessario eseguire il rimborso via gateway quando previsto dalle procedure interne.
Esempi pratici:
- Hai rimborsato offline (bonifico o cash): registra il rimborso in WooCommerce impostando lo stato Refunded e aggiungendo la nota transazionale per tracciabilità.
- Vuoi rimborsare via Stripe/PayPal: verifica se il gateway supporta il rimborso dalla pagina dell’ordine; alcuni gateway permettono di eseguire il rimborso direttamente dall’admin, altri richiedono l’azione nell’interfaccia del gateway. Testa in sandbox per confermare il comportamento.
Avvertenza obbligatoria: non assumere che il solo cambio di stato esegua un rimborso finanziario; verifica per ogni gateway e testa in ambiente di staging/sandbox.
Impatto degli stati su stock, notifiche e Analytics
Gli stati ordine influenzano comportamenti collegati come riduzione/ripristino stock, invio di email e inclusione nei report.
Stock: a partire da WooCommerce 11.0, se un ordine che aveva ridotto lo stock passa allo stato Failed, WooCommerce ripristina lo stock ridotto; il ripristino avviene solo se l’ordine aveva effettivamente ridotto lo stock.
Analytics e report: per default WooCommerce Analytics include gli ordini con stati Processing e Completed come “paid”; gli stati custom non sono inclusi automaticamente nelle metriche se non vengono aggiunti alle ‘Actionable Statuses’ e se non si esegue la pulizia della cache o il re-import dei dati.
Notifiche e azioni in blocco: gli stati custom non partecipano automaticamente alle email e alle bulk actions a meno che non siano configurati con le proprietà appropriate (ad esempio il flag “Paid”).
Implicazione operativa: prima di introdurre stati custom valuta l’impatto su KPI e automazioni; potresti dover aggiornare regole di reportistica o re-importare dati per conservare la continuità dei report.
Stati personalizzati: come crearli e farli comportare come gli stati core
È possibile creare stati ordine personalizzati con l’estensione Order Status Manager; gli stati custom possono avere icone, colori, next statuses, azioni in blocco, email collegate e un flag che definisce se lo stato è considerato ‘Paid’.
Per far comportare uno stato custom come uno stato core occorre:
- Configurare il flag “Paid” se lo stato rappresenta un pagamento già ricevuto.
- Aggiungere lo stato custom alle ‘Actionable Statuses’ di Analytics e rieseguire eventuale re-import o pulizia cache per includere gli ordini nei report.
- Mappare le email e le bulk actions al nuovo stato tramite le impostazioni dell’estensione o tramite snippet/plugin aggiuntivi.
Esempio pratico: creare lo stato “In controllo qualità” per ordini fisici già pagati; impostare il flag Paid = sì se si vuole che l’ordine compaia nei report delle vendite e collegare notifiche interne per il reparto QC.
Checklist operativa prima di cambiare workflow o aggiungere stati (staging/tests)
Prima di applicare cambiamenti in produzione, esegui questi test in staging:
- Verificare webhook/IPN e log del gateway per ordini in Pending/Failed.
- Simulare pagamenti in sandbox per tutti i gateway attivi e verificare il comportamento di transizione degli stati.
- Testare rimborsi manuali e automatici: prova sia la registrazione del rimborso in WooCommerce che l’esecuzione via gateway in sandbox.
- Verificare l’effetto su stock, inclusi scenari in cui un ordine va a Failed (controlla il comportamento introdotto in 11.0).
- Se aggiungi stati custom: impostare il flag Paid dove necessario, mappare email/bulk actions e aggiungere lo stato alle Actionable Statuses per Analytics; poi reimportare o pulire la cache dei dati.
- Controllare compatibilità dei plugin installati con HPOS / WooCommerce 11.x in staging (verificare changelog dei plugin).
Avvertenza: non applicare cambi di stato in bulk senza aver prima verificato l’impatto su stock e report.
Troubleshooting rapido: ordini bloccati su Pending o che non passano a Completed
Procedura diagnostica rapida:
- Controlla le order notes e i log del gateway per trovare errori o webhook mancanti.
- Verifica la modalità del gateway (authorize vs authorize-and-capture) perché può influire sulla transizione automatica degli stati.
- Controlla che il metodo di pagamento chiami
woocommerce_payment_complete()o equivalenti se ti aspetti un auto-complete. - Se non arrivano notifiche webhook, isola il problema con strumenti di logging o replay dei webhooks in staging.
Non cambiare lo stato manualmente come soluzione definitiva: risolvi la causa sottostante per evitare inconsistenze ricorrenti.
Risorse ufficiali e dove testare
Documentazione utile da consultare e link per il testing in sandbox/staging: documentazione ufficiale sui rimborsi e gestione ordini, documentazione Order Status Manager e Order Status Control, e advisory su WooCommerce 11.0 relativo allo stato Failed.
Per test operativi, crea ambienti di staging con copie dei plugin attivi e gateway in modalità sandbox per riprodurre i flussi reali prima di fare modifiche in produzione.
Conclusione operativa: tratta gli stati ordine come contratti operativi tra i reparti (assistenza, logistica, contabilità). Verifica gateway e webhook prima di cambiare stati, testa gli effetti su stock/report quando aggiorni policy e configura esplicitamente gli stati custom perché possano comportarsi come “paid” ed entrare nelle Analytics.