L’integrazione tra WooCommerce e i gestionali italiani per la fatturazione elettronica ha un problema tecnico specifico che impatta direttamente le conversioni dell’ecommerce: quasi tutti i plugin di fatturazione eseguono la chiamata API al gestionale in modo sincrono nel momento in cui il cliente clicca su “Completa ordine”. Il cliente aspetta. Il server aspetta la risposta del gestionale. Se la risposta tarda più di qualche secondo, il cliente vede una pagina che non risponde e abbandona. La fattura viene generata, ma l’ordine è perso.
Non è un problema teorico. Lavorando con agenzie che gestiscono ecommerce WooCommerce per clienti italiani, abbiamo trovato questa configurazione su diversi siti in produzione. Il checkout rallentava a ogni ordine, con picchi di latenza durante le ore di maggiore traffico quando il gestionale era sotto carico. La soluzione tecnica esiste ed è documentata, ma richiede di configurare il plugin in modo diverso da quello predefinito.
Il mercato dei gestionali italiani nel 2026
Prima di entrare nella parte tecnica, vale la pena fare il punto sullo scenario dei gestionali italiani compatibili con WooCommerce, perché la scelta del gestionale impatta direttamente le opzioni di integrazione disponibili.
Fatture in Cloud è il gestionale più diffuso tra le PMI italiane che usano WooCommerce. Ha API REST ben documentate, un plugin WordPress ufficiale e una community di developer attiva. La versione gratuita ha limiti sul numero di fatture mensili; la versione a pagamento è compatibile con la maggior parte dei workflow di ecommerce.
Aruba Fatturazione ha integrazione diretta con il Sistema di Interscambio (SDI) dell’Agenzia delle Entrate. Il plugin WooCommerce è sviluppato da terze parti ed è meno maturo rispetto all’integrazione di Fatture in Cloud. Abbiamo trovato più casi di incompatibilità con versioni recenti di WooCommerce su siti in produzione.
Fatture in Cloud, Danea Easyfatt e il gestionale TeamSystem sono tutti prodotti dello stesso gruppo TeamSystem, con posizionamenti diversi: Fatture in Cloud è orientato alle micro-imprese e ai professionisti con API REST moderne, Danea Easyfatt è più diffuso tra artigiani e piccole imprese con architettura client-server locale, il gestionale TeamSystem è rivolto ad aziende strutturate. L’integrazione WooCommerce più matura e documentata è quella di Fatture in Cloud. Danea e TeamSystem gestionale richiedono quasi sempre sviluppo custom o middleware perché le loro architetture non sono progettate nativamente per il web.
Invoiceninja e Quadro sono alternative più recenti con API moderne, più facili da integrare ma con minore adozione nel mercato italiano tradizionale.
Il problema tecnico: chiamate sincrone al checkout
Quando un cliente clicca “Completa ordine” su WooCommerce, si avvia una sequenza di operazioni: validazione del pagamento, creazione dell’ordine nel database, notifica email al cliente e al negozio, e, se il plugin di fatturazione è configurato in modo sincrono, chiamata API al gestionale per generare e inviare la fattura via SDI.
Il problema è questa ultima operazione. La chiamata API al gestionale è una richiesta HTTP verso un server esterno. Se quel server è lento, sotto carico o temporaneamente non disponibile, la pagina di WooCommerce resta in attesa. Il timeout predefinito di PHP è 30 secondi: in 30 secondi il cliente ha già chiuso la scheda convinto che il pagamento non sia andato a buon fine.
Un ecommerce nel settore arredo con cui abbiamo lavorato attraverso un’agenzia partner aveva questo problema. Il gestionale usato era Fatture in Cloud. Durante i giorni normali il checkout era rapido. Nei momenti di picco, venerdì pomeriggio e pre-weekend, quando il traffico sull’ecommerce aumentava e il gestionale era sotto carico, il checkout impiegava da 8 a 15 secondi. L’analisi in Google Analytics mostrava un tasso di abbandono al checkout del 34% nei weekend contro il 22% nei giorni feriali. La correlazione con i picchi del gestionale era inequivocabile.
La soluzione tecnica in questo caso ha richiesto circa quattro ore di lavoro. Ma prima di descriverla, è utile capire i campi obbligatori che qualsiasi integrazione deve gestire correttamente.
I campi obbligatori italiani che appesantiscono il checkout
La normativa italiana sulla fatturazione elettronica richiede campi specifici che la maggior parte dei plugin WooCommerce internazionali non prevede nativamente. Aggiungerli al form di checkout senza una progettazione attenta crea un’esperienza utente scadente.
Codice SDI (o codice destinatario): il codice a 7 caratteri che identifica il canale di ricezione delle fatture elettroniche del destinatario. Obbligatorio per le fatture B2B. Molti checkout lo rendono obbligatorio per tutti, anche per i clienti privati che non ne hanno bisogno.
PEC: l’indirizzo di posta elettronica certificata come alternativa al codice SDI per le fatture B2B. Campo alternativo al codice SDI: uno o l’altro, non entrambi.
Partita IVA e Codice Fiscale: entrambi possono essere necessari, ma la logica di quando uno è sufficiente e quando servono entrambi dipende dal tipo di cliente (persona fisica o giuridica) e dal tipo di transazione.
La soluzione che implementiamo è un form di checkout condizionale: i campi per la fatturazione elettronica appaiono solo se il cliente seleziona “Acquisto come azienda” o “Richiedi fattura”. Il cliente privato che non ha bisogno della fattura elettronica non vede questi campi. Il cliente aziendale li vede e può compilarli.
Problema: Form di checkout sovraccarico con campi non necessari Causa: Plugin di fatturazione che aggiungono tutti i campi obbligatori per la fatturazione elettronica a tutti i clienti, indipendentemente dalla necessità. Soluzione Blurr: Logica condizionale con WooCommerce Checkout Fields o sviluppo custom che mostra i campi SDI, PEC e Partita IVA solo ai clienti che selezionano la richiesta di fattura. Riduzione del checkout a tre o quattro campi per i clienti privati.
La soluzione tecnica: chiamate asincrone con Action Scheduler
Tornando al problema principale: le chiamate API sincrone al checkout. La soluzione è spostare la chiamata al gestionale in background, dopo che l’ordine è già stato completato e il cliente è già sulla pagina di conferma.
WordPress include Action Scheduler nella maggior parte delle installazioni WooCommerce. È un sistema di code di azioni che permette di eseguire operazioni in background senza che il browser del cliente debba aspettare il risultato.
Il processo configurato correttamente funziona così: il cliente clicca “Completa ordine”, WooCommerce processa il pagamento e crea l’ordine, il cliente viene reindirizzato alla pagina di conferma d’ordine in meno di due secondi, e in background Action Scheduler esegue la chiamata API al gestionale e genera la fattura. Se la chiamata fallisce, Action Scheduler riprova automaticamente dopo un intervallo configurabile.
Problema: Plugin di fatturazione con chiamata API sincrona al checkout Causa: Il plugin esegue la chiamata al gestionale nell’hook woocommerce_checkout_order_processed o woocommerce_payment_complete, che sono hook sincroni eseguiti durante la richiesta HTTP del checkout. Soluzione Blurr: Spostare la chiamata al gestionale in un’azione schedulata con as_schedule_single_action() o as_enqueue_async_action() di Action Scheduler, triggerata dall’hook woocommerce_order_status_completed con un delay di 30 secondi per garantire che il pagamento sia completamente processato prima di generare la fattura. Aggiungere retry logic per gestire i fallimenti temporanei del gestionale.
Il codice base per implementare questa soluzione è relativamente semplice in un plugin custom. La complessità sta nel gestire correttamente i casi limite: ordini con pagamento differito, ordini rimborsati prima della generazione della fattura, fatture duplicate in caso di retry multipli.
Problema: Fatture duplicate in caso di retry di Action Scheduler Causa: Action Scheduler riprova le azioni fallite automaticamente. Se la chiamata API al gestionale ha un timeout ma la fattura è stata comunque creata, il retry genera una seconda fattura per lo stesso ordine. Soluzione Blurr: Salvare il numero di fattura come meta-dato dell’ordine WordPress (update_post_meta) prima di inviare la chiamata API, e verificare l’esistenza di questo meta-dato all’inizio di ogni retry prima di eseguire la chiamata. Se il meta-dato esiste, la fattura è già stata creata e il retry viene saltato.
Come verificare che l’integrazione non stia impattando il checkout
Il test più diretto è misurare il TTFB (Time to First Byte) della pagina di conferma ordine con e senza il plugin di fatturazione attivo. Gli strumenti per farlo sono gratuiti e non richiedono competenze tecniche avanzate.
Con WebPageTest o GTmetrix, misura il tempo di caricamento della pagina di conferma ordine durante un ordine di test. Se il TTFB supera i 2 secondi, il problema è quasi certamente nella chiamata sincrona al gestionale.
Un test più diretto è controllare i log di PHP durante un ordine di test: il timestamp di inizio e fine della chiamata API al gestionale è visibile nei log se il debug è attivo. La differenza tra i due timestamp è il tempo che il cliente aspetta.
Su ogni ecommerce WooCommerce che prendiamo in manutenzione per le agenzie partner, includiamo una verifica della configurazione del plugin di fatturazione come parte dell’audit iniziale. È uno dei check che produce più frequentemente interventi correttivi immediati, perché il problema è silenzioso: il cliente non vede errori, ma i dati di conversione mostrano l’impatto.
Per approfondire come gestiamo i progetti ecommerce dall’analisi alla consegna, leggi come gestire un progetto ecommerce per conto del tuo cliente. Per capire come configurare WooCommerce per performance elevate, leggi come strutturare un sito WordPress per performance elevate. Per approfondire i Core Web Vitals e l’impatto delle chiamate sincrone sul LCP e TTFB, leggi l’articolo dedicato.
Su blurr.it/contatti/ puoi prenotare una chiamata per verificare la configurazione del plugin di fatturazione sui siti ecommerce che gestisci.
FAQ
Quasi sempre per una chiamata API sincrona al gestionale eseguita durante il processo di checkout. Il server WordPress aspetta la risposta del gestionale prima di reindirizzare il cliente alla pagina di conferma. Se il gestionale è lento o sotto carico, il cliente aspetta o vede un timeout. La soluzione è spostare la chiamata in background con Action Scheduler, generando la fattura dopo che il cliente è già sulla pagina di conferma.
Fatture in Cloud ha l’integrazione più matura con API REST documentate e plugin WordPress ufficiale. Aruba Fatturazione ha integrazione diretta con SDI ma plugin meno aggiornato. TeamSystem e Danea Easyfatt richiedono quasi sempre sviluppo custom o middleware per l’integrazione con WooCommerce. La scelta dipende dal gestionale già in uso dal cliente: sostituire il gestionale solo per facilitare l’integrazione WooCommerce raramente è la scelta giusta.
Codice SDI o PEC per le fatture B2B (uno o l’altro, non entrambi obbligatori contemporaneamente), Partita IVA per i clienti aziendali, Codice Fiscale per i clienti privati che richiedono fattura. La soluzione ottimale mostra questi campi solo ai clienti che selezionano la richiesta di fattura, evitando di appesantire il checkout dei clienti privati che non ne hanno bisogno.
Misurando il TTFB della pagina di conferma ordine con uno strumento come WebPageTest durante un ordine di test, con e senza il plugin attivo. Una differenza superiore a un secondo indica che il plugin sta eseguendo operazioni sincrone durante il checkout. Un test più preciso è abilitare il debug di WordPress e controllare i log PHP per il timestamp di inizio e fine della chiamata API al gestionale durante l’ordine di test.