Drupal Commerce - Quando Batte Shopify

Drupal Commerce è la risposta sbagliata per la maggior parte dei negozi online. Non è una critica al progetto, ben costruito da quindici anni. È una constatazione su che cosa siano quasi tutti i negozi: qualche centinaio di codici articolo, una valuta, clienti privati, un pagamento con carta alla fine. Per un’attività di questa forma una piattaforma ospitata vince su ogni asse che conta e la discussione è chiusa prima di cominciare.

Esiste una minoranza per cui il calcolo si ribalta del tutto, ed è una minoranza redditizia. Prodotti configurabili che non stanno in una griglia di varianti. Conti professionali con listini negoziati. Un catalogo che è anche il contenuto editoriale. Un ERP che possiede giacenze e prezzi e tratta il sito come una superficie di visualizzazione. In queste aziende la piattaforma ospitata non costa meno: è una tassa permanente pagata in app, aggiramenti e cose che non vi è permesso cambiare.

Questo articolo dice dove cade davvero quel confine, con i numeri di entrambe le parti. Se leggete la sezione su Shopify e riconoscete la vostra azienda, fermatevi lì. Risparmierete molto denaro e questo articolo avrà fatto il suo lavoro.

Quando Drupal Commerce batte Shopify? Quando i vostri prodotti non si modellano come una semplice griglia di varianti, quando clienti diversi vedono prezzi diversi per lo stesso codice articolo, quando catalogo e contenuto editoriale sono la stessa cosa, oppure quando un ERP è la fonte di verità e il negozio ne è solo una vista. Per un catalogo consumer lineare in una o due valute, Shopify costa meno su tre anni e converte meglio. La linea di separazione è la complessità di prodotto e di prezzo, non il traffico o il fatturato.

Che cosa è davvero Drupal Commerce

Drupal Commerce non è un prodotto per negozi. È un insieme di tipi di entità posato sul sistema di entità e campi di Drupal, e tutto ciò che segue in questo articolo discende da questa frase.

Un prodotto in Drupal Commerce è un’entità con un bundle, esattamente come un nodo. Lo stesso vale per una variazione di prodotto, un ordine, una riga d’ordine, un pagamento, una promozione e un negozio. Ognuna accetta campi arbitrari, così una variazione può portare un numero di lotto, un riferimento di certificato, un tempo di consegna in giorni lavorativi e una misura usata per calcolarne il prezzo. Nulla di questo è un campo personalizzato avvitato al fianco di uno schema fisso. È lo schema.

La cosa acquistabile è la variazione, non il prodotto. Il prodotto è l’involucro di presentazione e la variazione è l’articolo con codice e prezzo, con gli attributi che generano le combinazioni selezionabili. Un tipo di prodotto decide quali campi ha un prodotto, e un tipo di variazione decide quali attributi portano le sue variazioni. Nulla in questa disposizione presuppone abbigliamento, beni fisici o un numero fisso di scelte.

La conseguenza è che Drupal Commerce non ha quasi alcuna opinione su ciò che vendete. Il prezzo di quella libertà è che non fornisce quasi nessuna decisione, e qualcuno deve prenderle tutte.

Dove si trova oggi Drupal Commerce

La versione raccomandata è Drupal Commerce 3.3.8, pubblicata il 17 luglio 2026, e funziona con Drupal 10.3 o successivo e con Drupal 11. Le release stabili rientrano nella politica di sicurezza di Drupal, il che conta più di quanto sembri: una vulnerabilità divulgata riceve una pubblicazione coordinata invece di una segnalazione su GitHub.

La pagina del progetto Drupal Commerce riporta 35.870 siti che usano il modulo. Commerce 3.0.0 è stata la prima release stabile della linea 3.x, nel gennaio 2025, e ha abbandonato il supporto a Drupal 9. Attorno c’è un piccolo ecosistema contribuito: Commerce Shipping è alla 3.0.3 con circa 15.200 installazioni, e i moduli specialistici discussi più avanti si contano in poche migliaia.

Confrontatelo con WooCommerce, che dichiara oltre 7 milioni di installazioni attive e richiede WordPress 6.9 e PHP 7.4 o superiore. Rapportato alla base installata, Drupal Commerce è circa 200 volte più piccolo.

Quel rapporto è il numero più importante di questo articolo, ed è un avvertimento, non un vanto. Significa che alla domanda se esista già un modulo per una certa cosa la risposta è spesso no.

L’argomento onesto a favore di Shopify

Shopify risolve i quattro problemi che affondano quasi tutti i negozi auto-ospitati, e li risolve prima che abbiate scritto una riga di codice.

È ospitato, quindi disponibilità, scalabilità e patch smettono di essere una vostra voce di bilancio. Gestisce i dati di carta, per cui la superficie di conformità che ereditate è una frazione di quella che avreste altrimenti. Il suo checkout è collaudato su un volume di transazioni reali che nessuna agenzia può riprodurre, e a quella scala piccole differenze di conversione valgono più di qualunque preferenza architetturale. E il suo ecosistema di app fa sì che quasi ogni requisito arrivi come abbonamento invece che come progetto.

Per un catalogo consumer con qualche migliaio di codici articolo, una o due valute e nessun prezzo negoziato, nessuno dei vantaggi descritti più avanti si applica. Paghereste un’agenzia per ricostruire, peggio, ciò che oggi ottenete per £65 al mese.

Diciamolo chiaramente, visto che il resto del pezzo argomenta al contrario: quasi tutti i negozi dovrebbero fermarsi a Shopify. Se il vostro è tra questi, il nostro confronto tra Shopify e un ecommerce su misura tratta la decisione più in dettaglio di questa pagina.

Quanto costa Shopify nel Regno Unito

Shopify pubblica i prezzi britannici in sterline, quindi non serve alcuna conversione. Letti sulla pagina dei prezzi di Shopify a settembre 2026: Basic costa £25 al mese con fatturazione mensile o £19 con fatturazione annuale, Grow £65 oppure £49, Advanced £344 oppure £259, e Plus parte da £1.800 al mese. POS Pro aggiunge £69 al mese per punto vendita.

Le commissioni sulle carte pesano più dell’abbonamento. Le tariffe per carta online tramite Shopify Payments sono del 2 % più 25 p su Basic, dell'1,7 % più 25 p su Grow e dell'1,5 % più 25 p su Advanced. Il numero che quasi tutti trascurano è la commissione per fornitore di pagamento terzo, addebitata quando usate un gateway diverso da Shopify Payments: 2 % su Basic, 1 % su Grow, 0,6 % su Advanced e 0,2 % su Plus.

Quella commissione si somma a quanto vi addebita il gateway. In un negozio che fattura 1 milione di sterline all’anno e usa un acquirer esterno su Advanced, la sola commissione per terzi vale £6.000 all’anno, cioè £18.000 su tre anni, per il privilegio di non usare Shopify Payments.

Dove Shopify finisce lo spazio

I limiti sono pubblicati e sono precisi. La documentazione Shopify sull’aggiunta di varianti afferma che ogni prodotto può avere fino a tre opzioni e fino a 2.048 varianti, e che superare l’una o l’altra soglia richiede un’app di terze parti o codice del tema che catturi proprietà di riga.

Tre opzioni è il soffitto che stringe per primo. Una finestra, un pannello stampato, una tenda su misura o una macchina configurata hanno di norma sei o otto scelte indipendenti, e nel momento in cui superate tre la piattaforma smette di modellare il vostro prodotto e comincia ad approssimarlo.

Il checkout è il secondo muro. Le estensioni di interfaccia del checkout di Shopify per i passi informazioni, spedizione e pagamento sono disponibili solo sul piano Plus. Sotto Plus potete personalizzare la grafica del checkout ma non inserirvi logica, il che esclude la scelta della fascia di consegna, i controlli di fido commerciale e i blocchi di conformità nel punto in cui devono avvenire.

Il terzo limite è l’accumulo. Ogni lacuna viene colmata da un’app, ogni app è un canone mensile e una dipendenza di aggiornamento, e un negozio con venti app ha un problema di manutenzione che somiglia molto a quello da cui era fuggito.

L’argomento a favore di WooCommerce, e dove fatica

WooCommerce merita un’udienza più equa di quella che riceve di solito. È gratuito, gira su hosting da poche decine di sterline al mese, i dati sono vostri, e il suo catalogo di estensioni è di gran lunga il più ampio dell’ecommerce. Per un negozio consumer piccolo o medio il cui team conosce già WordPress, è spesso la risposta giusta e la più economica.

Fatica in tre punti prevedibili. Il primo è il modello dati: i prodotti sono un tipo di contenuto WordPress con attributi memorizzati come metadati serializzati, quindi filtrare un catalogo grande e ricco di attributi significa interrogare una tabella chiave-valore invece di colonne vere. È sopportabile con 1.000 prodotti e doloroso con 50.000.

Il secondo è la prestazione al crescere delle varianti, di gran lunga il motivo più comune per cui un negozio WooCommerce risulta lento. Ne abbiamo descritto la meccanica in dettaglio nel nostro pezzo su perché un negozio WooCommerce è lento, e in breve i prodotti variabili moltiplicano le query, non le righe.

Il terzo è la proliferazione di plugin. WooCommerce risolve i problemi installando cose, e dopo quattro anni il negozio è definito dai calendari di rilascio di trenta fornitori invece che dal vostro.

Modellazione di prodotto complessa: la prima vera linea di separazione

Il caso più chiaro a favore di Drupal Commerce è un prodotto che si configura invece di sceglierlo. Tessuto venduto al metro con spese di taglio. Vetro con prezzo dato da larghezza per altezza e un minimo di fatturazione. Una macchina con otto gruppi di opzioni, alcuni dei quali ne invalidano altri. Stampa con una curva di sconto quantità e un costo di avviamento per commessa.

Nessuno di questi è una griglia di varianti. Su una piattaforma ospitata vengono approssimati con un’app e una serie di proprietà di riga, il che significa che il prezzo mostrato al cliente è calcolato fuori dalla logica di prezzo della piattaforma e va riconciliato in un momento successivo.

In Drupal Commerce il prezzo è risolto da codice che scrivete voi. Un risolutore di prezzo riceve la variazione, la quantità e il contesto corrente, e restituisce un prezzo. Non c’è nulla di esotico, e significa che il prezzo configurato è il prezzo vero ovunque: nel carrello, nell’ordine, nel calcolo dell’imposta e nell’esportazione verso l’ERP.

Il test da applicare è semplice. Se potete scrivere il vostro catalogo come un foglio di calcolo con una riga per ogni cosa acquistabile, non vi serve tutto questo. Se non potete, tutto il resto dell’articolo diventa rilevante.

Prezzi B2B, listini e condizioni negoziate

La seconda linea di separazione è se due clienti vedano mai prezzi diversi per lo stesso codice articolo. I negozi consumer rispondono no. Le aziende commerciali rispondono sì, e quella risposta di solito è tutto il loro mestiere.

Shopify il B2B ce l’ha, e la sua documentazione sulle funzioni B2B per piano conferma che è disponibile su Basic, Grow, Advanced e Plus. I limiti stanno nel dettaglio: sotto Plus avete fino a tre cataloghi attivi su tutti i mercati B2B, i cataloghi aziendali diretti sono solo su Plus, e depositi, pagamenti parziali e richieste di pagamento per singola spedizione sono anch’essi solo su Plus. Tre cataloghi bastano per tre fasce di prezzo e non servono a nulla per quaranta conti negoziati.

Su Drupal l’equivalente è il modulo Commerce Price List, attualmente 8.x-2.16 con circa 1.662 installazioni dichiarate e copertura del team di sicurezza. Imposta prezzi per utente o per ruolo, gestisce scaglioni di quantità e intervalli di date, e importa da CSV.

Quest’ultimo punto è quello pratico. Un grossista con quaranta conti, ciascuno sul proprio listino concordato, aggiornato ogni trimestre dall’ERP, è un lavoro di importazione CSV e non una migrazione di piattaforma.

Multinegozio, multivaluta e multilingua da una sola base di codice

Un negozio è un’entità di prima classe in Drupal Commerce, e i prodotti vengono assegnati ai negozi che possono venderli. È una piccola decisione di progetto con una grande conseguenza: più vetrine possono condividere un catalogo, una pipeline di ordini e un’amministrazione, pur portando valute, configurazioni fiscali, gateway di pagamento e regole di spedizione diverse.

La forma consueta è un sito britannico, un sito UE e un portale professionale, tutti da un unico deployment. I dati di prodotto si inseriscono una volta sola. Un listino si applica solo al negozio professionale. L’imposta si risolve per negozio, perché il negozio porta con sé il proprio paese di fatturazione e le proprie registrazioni.

Il core di Drupal porta inoltre uno strato multilingua davvero solido, con alias URL per lingua, entità tradotte e link a lingue alternative, ed è il motivo per cui Drupal è così presente nell’istruzione superiore e nel settore pubblico.

Shopify Markets copre ormai buona parte di questo, ma checkout contestuale e personalizzazione della vetrina tramite Markets sono limitati ai piani Advanced e Plus, quindi il confronto è come minimo contro £259 al mese invece che contro £25.

Quando il catalogo è editoriale

Alcuni cataloghi sono contenuto. Un rivenditore specializzato le cui schede prodotto portano guide all’acquisto, tabelle comparative, spiegazioni tecniche e le note di un collaudatore gestisce una pubblicazione che per inciso incassa pagamenti.

Su una piattaforma ospitata quelli sono due sistemi. Il CMS tiene l’articolo, il negozio tiene il codice articolo, e a unirli sono un collegamento e un’esportazione notturna. I redattori lavorano in due posti, la ricerca indicizza due volte, e la struttura degli URL cresce con una cucitura nel mezzo.

In Drupal Commerce un prodotto è un’entità nello stesso sistema di ogni articolo, quindi condivide il flusso editoriale, lo storico delle revisioni, i vocabolari di tassonomia, la libreria media, l’indice di ricerca e il modello di accesso. Una scheda prodotto può referenziare tre articoli e un articolo nove prodotti, in entrambi i casi come riferimenti reali fra entità e non come link incollati.

È l’argomento che più spesso giustifica Drupal per un’azienda che altrimenti starebbe comodamente su Shopify, ed è quello che più spesso viene liquidato come un lusso, finché una redazione non ha passato un anno a lavorare in due interfacce di amministrazione.

Prodotti regolamentati e ricchi di attributi

I prodotti che portano dati di conformità sono il quarto caso. Sostanze chimiche con schede di sicurezza. Dispositivi medici con numeri di certificato e date di scadenza. Alimenti con matrici di allergeni. Apparecchi elettrici con dichiarazioni di conformità. Qualunque cosa con tracciabilità di lotto o un contrassegno di vendita limitata.

Il requisito non è soltanto memorizzare quei valori. È convalidarli, versionarli, mostrare quello giusto per il lotto che il cliente ha davvero ricevuto, e dimostrare in seguito che cosa era pubblicato in una certa data. La Field API di Drupal e il suo sistema di revisioni fanno questo perché sono nati per la governance dei contenuti e non per il merchandising.

Il lato applicativo delle regole conta altrettanto. Un processore d’ordine può rifiutare un checkout che spedirebbe un articolo con limite d’età verso un paese che lo vieta, oppure che unirebbe due articoli che non possono viaggiare insieme, e può farlo dentro la pipeline dell’ordine invece che in un template del tema.

Su una piattaforma ospitata ognuno di quei controlli è un’app, e le app non si compongono. Due app che modificano entrambe il carrello sono due app che prima o poi non andranno d’accordo.

Quando l’ERP è la fonte di verità

Il quinto caso è strutturale. In un’azienda di distribuzione o di produzione l’ERP possiede giacenze, prezzi, fido cliente e stato dell’ordine, e il sito è una superficie di visualizzazione con un carrello attaccato. La domanda non è che cosa sappia fare il negozio, ma quanto costi poco tenerlo in accordo con il sistema che comanda davvero.

Drupal Commerce sta a suo agio qui perché l’integrazione gira nel vostro processo. La Queue API gestisce il lavoro asincrono, la Migrate API gestisce importazioni ripetibili e idempotenti, e non c’è alcun intermediario che fatturi a record o limiti la vostra finestra di sincronizzazione. Un’importazione notturna di prezzi e giacenze da 200.000 righe è un cron job.

Su una piattaforma ospitata la stessa integrazione è un abbonamento a un’app oppure a un middleware, e i limiti di chiamate API della piattaforma diventano un vincolo architetturale attorno a cui progettare invece che un dettaglio. È praticabile, e per molte aziende è il compromesso corretto. Smette di esserlo quando la sincronizzazione è al tempo stesso grande, frequente e critica per l’attività.

Se il lavoro di integrazione è il grosso del progetto invece del negozio stesso, si tratta di un incarico di sviluppo software con una vetrina attaccata, e va inquadrato così fin dall’inizio.

Le imposte sono il punto in cui le piattaforme ospitate smettono di costare poco

Le imposte sono il centro di costo silenzioso dell’ecommerce transfrontaliero, ed è lì che il confronto fra abbonamenti mensili comincia a ingannare. Due soglie decidono quasi tutto.

La soglia di registrazione IVA nel Regno Unito

La guida GOV.UK su quando registrarsi ai fini IVA fissa la soglia a £90.000 di fatturato imponibile totale. Due test distinti fanno scattare la registrazione: un test mobile su dodici mesi, in cui dovete registrarvi entro 30 giorni dalla fine del mese in cui il fatturato ha superato £90.000, e un test prospettico, in cui dovete registrarvi appena vi rendete conto che il fatturato supererà £90.000 nei 30 giorni successivi.

Il test prospettico è quello che coglie i negozi in crescita, perché la data di registrazione è il giorno in cui ve ne siete resi conto, non il giorno in cui il denaro è arrivato.

IVA UE e lo sportello unico

La guida della Commissione europea sul luogo di imposizione fissa una soglia annua combinata di EUR 10.000 che copre insieme le vendite a distanza intracomunitarie di beni e i servizi di telecomunicazione, teleradiodiffusione ed elettronici. Al di sotto, il luogo di imposizione è quello in cui inizia la spedizione o il trasporto. Al di sopra, l’imposizione si sposta dove il trasporto finisce, cioè all’aliquota del cliente nel suo paese.

Lo sportello unico permette di dichiarare tutto questo in un’unica dichiarazione in un solo Stato membro, presentata ogni trimestre con scadenze a fine aprile, luglio, ottobre e gennaio. Lo sportello unico per le importazioni copre i beni importati da fuori UE in spedizioni che non superano EUR 150.

Che cosa fa Drupal Commerce in modo nativo

Commerce include un plugin fiscale per l’IVA dell’Unione europea nel core invece che come componente aggiuntivo. Porta le aliquote di tutti i 27 Stati membri più Monaco, distingue aliquote ordinarie, ridotte, intermedie, super ridotte e a zero, e gestisce i territori speciali su cui inciampano le tabelle piatte, fra cui Corsica, Azzorre, Madeira, isole greche e l’enclave austriaca di Jungholz.

Applica anche le regole e non solo le aliquote: imposizione a destinazione per i beni digitali e cessioni intracomunitarie fra imprese a zero quando viene fornito un numero fiscale valido. Su una piattaforma ospitata quel comportamento è di norma un’app con un costo per transazione.

Pagamenti, PCI DSS e come incassate la carta

Il modo in cui raccogliete il numero di carta decide il vostro carico di conformità, e le regole sono cambiate di recente in un modo largamente frainteso.

Il chiarimento del PCI Security Standards Council sui criteri di ammissibilità al SAQ A spiega un criterio entrato in vigore il 1 aprile 2025. L’esercente deve confermare che il proprio sito non è suscettibile ad attacchi da script che potrebbero incidere sui suoi sistemi di ecommerce, cosa che si soddisfa applicando le tecniche dei requisiti PCI DSS 6.4.3 e 11.6.1 oppure ottenendo dal fornitore di pagamento la conferma che la sua soluzione integrata include quelle protezioni.

La delimitazione precisa è la parte che si sbaglia. Quel criterio si applica soltanto agli esercenti la cui pagina incorpora il modulo di pagamento del fornitore, tipicamente in un iframe. Il Council afferma che non si applica agli esercenti che reindirizzano il cliente verso il fornitore, sia tramite redirect HTTP, sia con meta refresh o JavaScript, né agli esercenti che esternalizzano completamente le funzioni di pagamento.

Un reindirizzamento ospitato tiene quindi piccola la superficie. I campi incorporati, che convertono meglio e che quasi tutti in realtà vogliono, portano l’integrità di ogni script della vostra pagina di checkout dentro la vostra conversazione di conformità.

È qui che sta il vero vantaggio di Shopify, perché il checkout è loro e gli script che vi girano sono loro. Su Drupal Commerce il checkout è vostro, quindi la risposta va progettata: una content security policy rigorosa, subresource integrity, un inventario di ogni script che gira sulla pagina di pagamento e un rilevamento delle modifiche quando uno di essi si muove. Quel lavoro non è né difficile né facoltativo, e deve stare nel budget invece di essere scoperto durante un audit.

L’accessibilità è un rischio legale e commerciale

I difetti di accessibilità nell’ecommerce si concentrano nel checkout, che è anche il punto in cui ogni difetto costa denaro in modo diretto.

Il riferimento utile è WCAG 2.2, raccomandazione del W3C pubblicata il 12 dicembre 2024. I criteri che mordono in un negozio sono precisi. 1.3.5 Identify Input Purpose, livello AA, copre il riempimento automatico dei campi di indirizzo e carta. 3.3.7 Redundant Entry, livello A, viene violato ogni volta che un checkout costringe il cliente a ridigitare l’indirizzo di consegna al passo di pagamento. 3.3.8 Accessible Authentication, livello AA, governa creazione account e accesso. 2.5.8 Target Size, livello AA, coglie i selettori di quantità e i comandi di rimozione dal carrello, e 1.4.3 Contrast, livello AA, coglie il pulsante grigio disattivato che in realtà è attivo.

Altri due stanno attorno all’ordine stesso: 3.3.1 Error Identification, livello A, e 3.3.4 Error Prevention per transazioni legali, finanziarie e di dati, livello AA, che riguarda proprio l’inoltro di un ordine.

La posizione giuridica britannica è spesso esagerata. Un rivenditore privato non è vincolato da una legge che nomini un livello di conformità WCAG. Ciò che si applica è l’obbligo dell’articolo 20 dell’Equality Act 2010 di adottare misure ragionevoli per evitare uno svantaggio sostanziale alle persone con disabilità, compresa la fornitura di ausili. I regolamenti che nominano un livello, i Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, riguardano gli enti pubblici e non i negozi.

Il punto commerciale è più netto di quello legale. Su un tema ospitato non sempre potete correggere ciò che un’app inietta nel vostro checkout. Su una piattaforma che controllate, potete.

Quanto costano davvero tre anni

Il confronto che si fa di solito mette l’abbonamento mensile contro l’hosting mensile, che è la riga meno significativa della tabella. Costo di costruzione e manutenzione dominano, e a volume dominano le percentuali sulle transazioni.

Le fasce qui sotto sono stime interne di Mecanik per un negozio britannico di fascia media, tranne i valori di abbonamento e commissione Shopify, riportati in sterline esattamente come Shopify li pubblica. Tutto il resto è ciò che ci aspetteremmo di preventivare, e la forbice dentro ogni riga è più ampia della distanza fra le piattaforme nella parte bassa.

Che cosa compra davvero ogni riga della tabella

In prosa: Shopify Advanced costa fra £9.324 e £12.384 di abbonamento su tre anni a seconda che vi impegniate su base annuale, e include l’hosting, ma aggiunge abbonamenti ad app che realisticamente vanno da £5.400 a £14.400 nello stesso periodo. WooCommerce non paga nulla per la piattaforma e fra £3.600 e £14.400 per l’hosting, con estensioni da £3.000 a £9.000 nei tre anni. Drupal Commerce non paga nulla di licenza, spende di più in hosting, da £5.400 a £21.600, perché è la più pesante delle tre applicazioni, e spende meno in componenti aggiuntivi, fra nulla e circa £3.000, perché gli equivalenti sono moduli contribuiti e non commerciali.

Il costo di costruzione separa le piattaforme. Una realizzazione Shopify da £8.000 a £25.000 compra un negozio con tema e le integrazioni standard, contro £10.000 a £35.000 su WooCommerce. Lo stesso capitolato su Drupal Commerce vale £35.000 a £120.000, perché checkout, logica di prezzo e integrazioni vengono scritti invece che configurati. La manutenzione segue la stessa forma, con £3.000 a £9.000 all’anno per Shopify, £4.000 a £12.000 per WooCommerce e £12.000 a £30.000 per Drupal Commerce, a riflettere tariffe giornaliere di agenzia britannica di circa £600 a £900, trattate nella nostra guida alle tariffe degli sviluppatori Drupal.

Dove atterrano i totali a tre anni

I totali a tre anni atterrano attorno a £32.000 a £79.000 per Shopify, £29.000 a £94.000 per WooCommerce e £76.000 a £235.000 per Drupal Commerce. Le commissioni di carta e gateway si sommano a tutte e tre e crescono con il fatturato, motivo per cui la commissione Shopify per gateway terzo dello 0,6 % su Advanced vale £18.000 su tre anni in un negozio da 1 milione di sterline.

Leggete la tabella onestamente e Drupal Commerce costa da due a tre volte tanto. Si giustifica solo quando l’alternativa in realtà non è disponibile, che è tutto il senso delle cinque sezioni precedenti.

Drupal Commerce headless e disaccoppiato

Disaccoppiare Drupal Commerce è un requisito reale in un insieme ristretto di casi e una moda in quasi tutto il resto. Il test onesto è se qualcosa di diverso da un sito web abbia bisogno dello stesso catalogo.

È un requisito reale quando un’app mobile nativa e un sito devono condividere un solo modello di prodotto e di prezzo, quando un frontend esistente costruito da un altro team non viene sostituito, quando terminali di cassa o chioschi consumano lo stesso carrello, oppure quando un design system appartiene a chi sta fuori dal progetto e non può essere espresso in Twig. In quei casi l’API è il prodotto e il CMS è deliberatamente invisibile.

È moda quando la ragione addotta è la prestazione. Un frontend Drupal tradizionale ben messo in cache serve le pagine prodotto anonime dal bordo della rete, e il metodo di rendering è raramente ciò che rende lento un negozio lento.

Il costo si concentra in un solo punto. Il core di Drupal espone i contenuti su JSON:API senza configurazione, e il modulo Commerce Cart API mette i carrelli dietro un’interfaccia REST, quindi leggere un catalogo e costruire un carrello costano quasi nulla. Il checkout no. Gestione degli indirizzi, esposizione delle imposte, scelta della spedizione, promozioni, integrazione dell’elemento di pagamento e conferma d’ordine vanno tutti ricostruiti nel frontend, e di solito sono il 40 % o più dell’intera realizzazione.

La regola di decisione in cinque minuti

Rispondete a sei domande sul vostro catalogo. Ogni sì vale un punto.

Qualcuno dei vostri prodotti ha bisogno di più di tre opzioni, o di più di 2.048 combinazioni acquistabili? Due clienti diversi pagano mai prezzi diversi per lo stesso codice articolo? Vendete in più di un paese con trattamenti IVA differenti, o prevedete di presentare una dichiarazione OSS? Il catalogo è anche contenuto editoriale che lo stesso team scrive e mantiene? Un ERP o un PIM è l’autorità su prezzo e giacenze, con il negozio a valle? Dovete inserire logica vostra nel checkout invece di limitarvi a personalizzarne la grafica?

Con zero o un punto scegliete Shopify. I vantaggi descritti in questo articolo non vi riguardano e paghereste per ricostruire ciò che oggi affittate.

Con due punti la decisione è davvero aperta, e WooCommerce è spesso la via di mezzo migliore, soprattutto se il team già gestisce WordPress.

Con tre punti o più vale la pena preventivare Drupal Commerce come si deve, perché gli aggiramenti richiesti altrove costeranno più della piattaforma su tre anni. Con cinque o sei punti la piattaforma ospitata non è un’opzione più economica, è un prodotto diverso che non fa il lavoro.

Dove i progetti Drupal Commerce di solito sbagliano

Il fallimento più comune è sceglierlo per il motivo sbagliato. Usiamo già Drupal non è un requisito di commercio. Un sito di contenuti e un sito transazionale hanno esigenze di disponibilità diverse, test diversi e conseguenze diverse quando un rilascio va male, e trattare il negozio come un’altra sezione del sito esistente è il modo in cui un piccolo progetto ecommerce si ritrova con un team di piattaforma non previsto.

Il secondo è dotare troppo poco la manutenzione. Con 35.870 installazioni l’ecosistema è abbastanza piccolo da farvi usare moduli con una manciata di manutentori, e qualcuno dalla vostra parte deve seguire gli avvisi di sicurezza e programmare gli aggiornamenti. Un sito Drupal Commerce di cui nessuno è responsabile è un incidente di sicurezza a scoppio ritardato, tema che approfondiamo insieme ai requisiti di hosting che Drupal ha davvero.

Il terzo è dare per scontato che un modulo esista. Verificatelo prima di preventivare. Se non c’è, il lavoro è uno sviluppo di siti web su misura e richiede una stima vera invece di una voce di elenco.

Il quarto è la disciplina sulle versioni principali. Commerce 3 richiede Drupal 10.3 o successivo, e un sito che resta indietro rispetto al core prima o poi scopre che i suoi moduli commerce sono andati avanti senza di lui. La nostra guida allo sviluppo Drupal nel 2026 e il pezzo su costi e scadenze di migrazione trattano entrambi questo ciclo.

Prendere la decisione giusta

La scelta si decide sulla complessità di prodotto e di prezzo, non sul traffico, sul fatturato o sulle preferenze. Modellate prima il vostro catalogo, su carta, con ogni opzione, ogni prezzo negoziato e ogni integrazione che deve restare in accordo con qualcos’altro. Se quel modello sta in una griglia di varianti, comprate la piattaforma ospitata e spendete il budget risparmiato in merchandising.

Mecanik costruisce e mantiene entrambi i tipi di negozio, e vi diremo da che parte della linea vi trovate prima di preventivare qualsiasi cosa. Se la risposta è Drupal Commerce, il lavoro è un incarico di sviluppo di siti web con una componente di integrazione consistente; se il lavoro sull’ERP supera la vetrina, appartiene invece allo sviluppo software. Se la risposta è Shopify, lo diremo, e preferiamo dirlo adesso piuttosto che diciotto mesi dentro un rifacimento.

Domande frequenti

Drupal Commerce è meglio di Shopify? Non per la maggior parte dei negozi. Shopify costa meno su tre anni, gestisce conformità PCI e hosting, e ha un checkout collaudato a una scala che nessuna agenzia può eguagliare. Drupal Commerce vince in un insieme ristretto di casi: prodotti con più di tre opzioni o 2.048 varianti, prezzi negoziati per singolo cliente, cataloghi che sono anche contenuto editoriale, e negozi in cui un ERP possiede prezzo e giacenze.

Quanto costa una realizzazione Drupal Commerce nel Regno Unito? Aspettatevi £35.000 a £120.000 per la costruzione iniziale e £12.000 a £30.000 all’anno di manutenzione, a tariffe giornaliere di agenzia britannica di circa £600 a £900. Su tre anni un negozio Drupal Commerce si colloca di norma fra £76.000 e £235.000 hosting incluso, contro circa £32.000 a £79.000 per Shopify Advanced. Sono stime interne, non preventivi.

Quale versione di Drupal Commerce conviene usare? Drupal Commerce 3, attualmente alla 3.3.8, pubblicata il 17 luglio 2026. Funziona con Drupal 10.3 o successivo e con Drupal 11, e le sue release stabili rientrano nella politica di sicurezza di Drupal. Commerce 2 supportava Drupal 9 e 10 ed è il ciclo di rilascio precedente, quindi i nuovi progetti dovrebbero partire dalla linea 3.x.

Drupal Commerce gestisce IVA UE e OSS? Le regole fiscali sono integrate nel core di Commerce invece di essere vendute come componente aggiuntivo. Il plugin IVA dell’Unione europea porta le aliquote di tutti i 27 Stati membri più Monaco, distingue aliquote ordinarie, ridotte, intermedie, super ridotte e a zero, gestisce i territori speciali, applica l’imposizione a destinazione ai beni digitali e azzera le cessioni B2B intracomunitarie contro un numero fiscale valido. Presentare la dichiarazione OSS resta un compito contabile.

Quando conviene Drupal Commerce headless? Quando qualcosa di diverso da un sito web consuma lo stesso catalogo, per esempio un’app nativa, un terminale di cassa o un frontend di proprietà di un altro team. Non conviene per la sola velocità, dato che un frontend tradizionale in cache è già rapido. Mettete a budget la ricostruzione del checkout, che di norma è il 40 % o più di una realizzazione disaccoppiata.