Drupal Commerce - Wann Es Shopify Schlägt

Drupal Commerce ist für die meisten Onlineshops die falsche Antwort. Das ist keine Kritik am Projekt, das seit fünfzehn Jahren sauber konstruiert ist. Es ist eine Aussage darüber, was die meisten Shops sind: ein paar hundert Artikelnummern, eine Währung, Endkunden, am Ende eine Kartenzahlung. Für diesen Zuschnitt gewinnt eine gehostete Plattform auf jeder Achse, die zählt, und die Diskussion ist beendet, bevor sie beginnt.

Es gibt eine Minderheit, für die sich die Rechnung vollständig umkehrt, und sie ist lukrativ. Konfigurierbare Produkte, die sich nicht als Variantenraster ausdrücken lassen. Händlerkonten mit ausgehandelten Preislisten. Ein Katalog, der zugleich der redaktionelle Inhalt ist. Ein ERP, dem Bestand und Preise gehören und das die Website als Anzeigefläche behandelt. In diesen Unternehmen ist die gehostete Plattform nicht billiger, sondern eine Dauersteuer, gezahlt in Apps, Umwegen und Dingen, die Sie nicht ändern dürfen.

Dieser Beitrag zeigt, wo diese Grenze tatsächlich verläuft, mit den Zahlen auf beiden Seiten. Wenn Sie den Shopify-Abschnitt lesen und Ihr eigenes Geschäft wiedererkennen, hören Sie dort auf. Sie sparen sehr viel Geld, und dieser Artikel hat seine Aufgabe erfüllt.

Wann schlägt Drupal Commerce Shopify? Wenn sich Ihre Produkte nicht als einfaches Variantenraster abbilden lassen, wenn verschiedene Kunden für dieselbe Artikelnummer verschiedene Preise sehen, wenn Katalog und redaktioneller Inhalt dasselbe sind, oder wenn ein ERP die Quelle der Wahrheit ist und der Shop nur eine Sicht darauf. Für einen geradlinigen Endkundenkatalog in ein oder zwei Währungen ist Shopify über drei Jahre günstiger und besser darin, zu konvertieren. Die Trennlinie ist die Produkt- und Preiskomplexität, nicht Traffic oder Umsatz.

Was Drupal Commerce wirklich ist

Drupal Commerce ist kein Shop-Produkt. Es ist ein Satz von Entitätstypen, der auf das Entitäts- und Feldsystem von Drupal gelegt wird, und alles Weitere in diesem Artikel folgt aus diesem Satz.

Ein Produkt in Drupal Commerce ist eine Entität mit einem Bundle, genau wie ein Knoten. Ebenso eine Produktvariation, eine Bestellung, eine Bestellposition, eine Zahlung, eine Aktion und ein Store. Jede davon nimmt beliebige Felder auf, sodass eine Variation eine Chargennummer, eine Zertifikatsreferenz, eine Lieferzeit in Arbeitstagen und eine Abmessung tragen kann, aus der ihr Preis berechnet wird. Nichts davon ist ein Zusatzfeld, das seitlich an ein festes Schema geschraubt wurde. Es ist das Schema.

Das Kaufbare ist die Variation, nicht das Produkt. Ein Produkt ist die darstellende Hülle, und die Variation ist der Artikel mit Artikelnummer und Preis, wobei Attribute die auswählbaren Kombinationen erzeugen. Ein Produkttyp entscheidet, welche Felder ein Produkt hat, und ein Variationstyp entscheidet, welche Attribute seine Variationen tragen. Nichts an dieser Anordnung setzt Bekleidung, physische Waren oder eine feste Anzahl von Auswahlmöglichkeiten voraus.

Die Folge ist, dass Drupal Commerce fast keine Meinung darüber hat, was Sie verkaufen. Der Preis dieser Freiheit ist, dass es auch fast keine Entscheidungen liefert, und irgendjemand muss sie alle treffen.

Wo Drupal Commerce heute steht

Die aktuell empfohlene Version ist Drupal Commerce 3.3.8, veröffentlicht am 17. Juli 2026, und sie arbeitet mit Drupal 10.3 oder neuer und mit Drupal 11. Stabile Releases fallen unter die Sicherheitsrichtlinie von Drupal, was mehr bedeutet, als es klingt: Eine gemeldete Schwachstelle bekommt ein koordiniertes Release statt eines GitHub-Tickets.

Die Projektseite von Drupal Commerce nennt 35.870 Websites, die das Modul einsetzen. Commerce 3.0.0 war im Januar 2025 das erste stabile Release der 3.x-Linie, und es hat die Unterstützung für Drupal 9 fallen gelassen. Darum herum liegt ein kleines beigetragenes Ökosystem: Commerce Shipping steht bei 3.0.3 mit rund 15.200 Installationen, und die unten besprochenen Spezialmodule liegen im niedrigen vierstelligen Bereich.

Vergleichen Sie das mit WooCommerce, das über 7 Millionen aktive Installationen meldet und WordPress 6.9 sowie PHP 7.4 oder höher voraussetzt. Gemessen an der Installationsbasis ist Drupal Commerce rund 200 Mal kleiner.

Dieses Verhältnis ist die wichtigste Zahl in diesem Artikel, und es ist eine Warnung, kein Werbeargument. Es bedeutet, dass die Antwort auf die Frage, ob es dafür schon ein Modul gibt, häufig nein lautet.

Das ehrliche Argument für Shopify

Shopify löst die vier Probleme, an denen die meisten selbst gehosteten Shops scheitern, und es löst sie, bevor Sie eine Zeile Code geschrieben haben.

Es ist gehostet, also sind Verfügbarkeit, Skalierung und Patches nicht länger Ihr Budgetposten. Es verarbeitet die Kartendaten, sodass die Compliance-Fläche, die Sie erben, ein Bruchteil dessen ist, was sie sonst wäre. Sein Checkout ist gegen ein Volumen echter Transaktionen getestet, das keine Agentur nachbilden kann, und kleine Konversionsunterschiede sind in dieser Größenordnung mehr wert als jede architektonische Vorliebe. Und sein App-Ökosystem sorgt dafür, dass die meisten Anforderungen als Abonnement statt als Projekt ankommen.

Für einen Endkundenkatalog mit einigen tausend Artikelnummern, ein oder zwei Währungen und ohne ausgehandelte Preise trifft keiner der später beschriebenen Vorteile zu. Sie würden eine Agentur dafür bezahlen, schlechter nachzubauen, was Sie derzeit für £65 im Monat bekommen.

Sagen wir es deutlich, weil der Rest des Textes anders argumentiert: Die meisten Shops sollten bei Shopify bleiben. Wenn Ihrer dazugehört, behandelt unser Vergleich von Shopify gegen einen individuellen E-Commerce-Aufbau die Entscheidung ausführlicher als diese Seite.

Was Shopify im Vereinigten Königreich kostet

Shopify veröffentlicht britische Preise in Pfund, eine Umrechnung ist also nicht nötig. Abgelesen auf der Preisseite von Shopify im September 2026: Basic kostet £25 im Monat bei monatlicher Zahlung oder £19 bei jährlicher, Grow £65 oder £49, Advanced £344 oder £259, und Plus beginnt bei £1.800 im Monat. POS Pro kommt mit £69 pro Monat und Standort hinzu.

Die Kartengebühren wiegen schwerer als das Abonnement. Die Online-Kartenraten über Shopify Payments betragen 2 % plus 25 p bei Basic, 1,7 % plus 25 p bei Grow und 1,5 % plus 25 p bei Advanced. Die Zahl, die die meisten übersehen, ist die Gebühr für Zahlungsdienste von Drittanbietern, fällig, wenn Sie ein anderes Gateway als Shopify Payments nutzen: 2 % bei Basic, 1 % bei Grow, 0,6 % bei Advanced und 0,2 % bei Plus.

Diese Gebühr kommt zu dem hinzu, was Ihr Gateway berechnet. In einem Shop mit 1 Million Pfund Jahresumsatz, der auf Advanced einen externen Acquirer nutzt, macht allein die Drittanbietergebühr £6.000 im Jahr aus, also £18.000 über drei Jahre, für das Privileg, Shopify Payments nicht zu verwenden.

Wo Shopify an Grenzen stößt

Die Grenzen sind veröffentlicht und sie sind konkret. Die Shopify-Dokumentation zum Hinzufügen von Varianten sagt, dass jedes Produkt bis zu drei Optionen und bis zu 2.048 Varianten haben kann und dass ein Überschreiten der einen oder der anderen Grenze eine App von Drittanbietern oder Theme-Code erfordert, der Positionseigenschaften erfasst.

Drei Optionen ist die Decke, die zuerst drückt. Ein Fenster, eine bedruckte Platte, ein maßgefertigtes Rollo oder eine konfigurierte Maschine hat routinemäßig sechs oder acht unabhängige Auswahlfelder, und sobald Sie drei überschreiten, bildet die Plattform Ihr Produkt nicht mehr ab, sondern nähert es an.

Der Checkout ist die zweite Wand. Die Checkout-UI-Erweiterungen von Shopify für die Schritte Information, Versand und Zahlung gibt es nur im Plus-Tarif. Unterhalb von Plus können Sie den Checkout branden, aber keine Logik einfügen, was die Auswahl von Lieferfenstern, Bonitätsprüfungen für Händlerkredit und Compliance-Sperren genau dort ausschließt, wo sie stattfinden müssten.

Die dritte Grenze ist die Anhäufung. Jede Lücke wird von einer App gefüllt, jede App ist eine Monatsgebühr und eine Upgrade-Abhängigkeit, und ein Shop mit zwanzig Apps hat ein Wartungsproblem, das dem bemerkenswert ähnelt, von dem er weggezogen ist.

Das Argument für WooCommerce, und wo es ächzt

WooCommerce verdient eine fairere Anhörung, als es meist bekommt. Es ist kostenlos, es läuft auf Hosting für ein paar Dutzend Pfund im Monat, die Daten gehören Ihnen, und sein Erweiterungskatalog ist mit großem Abstand der größte im E-Commerce. Für einen kleinen bis mittelgroßen Endkundenshop, dessen Team WordPress bereits kennt, ist es häufig die richtige und die günstigste Antwort.

Es ächzt an drei vorhersehbaren Stellen. Die erste ist das Datenmodell: Produkte sind ein WordPress-Beitragstyp mit Attributen, die als serialisierte Metadaten abgelegt werden, sodass das Filtern eines großen, attributreichen Katalogs eine Abfrage über eine Schlüssel-Wert-Tabelle statt über echte Spalten bedeutet. Das ist bei 1.000 Produkten erträglich und bei 50.000 schmerzhaft.

Die zweite ist die Leistung bei hoher Variantenzahl, der mit Abstand häufigste Grund dafür, dass sich ein WooCommerce-Shop langsam anfühlt. Die Mechanik dahinter haben wir ausführlich in unserem Beitrag darüber behandelt, warum ein WooCommerce-Shop langsam ist, und die Kurzfassung lautet: Variable Produkte vervielfachen Abfragen, nicht Zeilen.

Die dritte ist der Plugin-Wildwuchs. WooCommerce löst Probleme, indem es Dinge installiert, und nach vier Jahren wird der Shop von den Release-Plänen dreißig verschiedener Anbieter bestimmt statt von Ihren eigenen.

Komplexe Produktmodellierung: die erste echte Trennlinie

Der klarste Fall für Drupal Commerce ist ein Produkt, das konfiguriert statt ausgewählt wird. Stoff, der nach Metern mit einer Zuschnittgebühr verkauft wird. Verglasung, deren Preis sich aus Breite mal Höhe mit einem Mindestbetrag ergibt. Eine Maschine mit acht Optionsgruppen, von denen einige andere ausschließen. Druck mit einer Mengenstaffelkurve und einer Rüstgebühr je Auftrag.

Nichts davon ist ein Variantenraster. Auf einer gehosteten Plattform werden sie mit einer App und einer Reihe von Positionseigenschaften angenähert, was bedeutet, dass der dem Kunden gezeigte Preis außerhalb der plattformeigenen Preislogik berechnet wird und irgendwann später abgeglichen werden muss.

In Drupal Commerce wird der Preis von Code aufgelöst, den Sie schreiben. Ein Preis-Resolver bekommt die Variation, die Menge und den aktuellen Kontext und gibt einen Preis zurück. Daran ist nichts exotisch, und es bedeutet, dass der konfigurierte Preis überall der echte Preis ist: im Warenkorb, in der Bestellung, in der Steuerberechnung und im ERP-Export.

Der anzuwendende Test ist einfach. Wenn Sie Ihren Katalog als Tabelle mit einer Zeile je kaufbarem Ding schreiben können, brauchen Sie das hier nicht. Wenn nicht, wird alles Weitere in diesem Artikel relevant.

B2B-Preise, Preislisten und ausgehandelte Konditionen

Die zweite Trennlinie ist die Frage, ob zwei Kunden jemals verschiedene Preise für dieselbe Artikelnummer sehen. Endkundenshops antworten nein. Handelsunternehmen antworten ja, und die Antwort ist meistens das ganze Geschäftsmodell.

Shopify hat durchaus B2B, und seine Dokumentation zu den B2B-Tariffunktionen bestätigt, dass es auf Basic, Grow, Advanced und Plus verfügbar ist. Die Grenzen stecken im Detail: Unterhalb von Plus bekommen Sie bis zu drei aktive Kataloge über alle B2B-Märkte hinweg, direkte Firmenkataloge gibt es nur mit Plus, und Anzahlungen, Teilzahlungen und Zahlungsanforderungen je Lieferung ebenfalls nur mit Plus. Drei Kataloge reichen für drei Preisstufen und sind für vierzig ausgehandelte Konten nutzlos.

Auf Drupal ist das Gegenstück das Modul Commerce Price List, derzeit 8.x-2.16 mit rund 1.662 gemeldeten Installationen und Betreuung durch das Sicherheitsteam. Es setzt Preise je Benutzer oder je Rolle, unterstützt Mengenstufen und Zeiträume und importiert aus CSV.

Dieser letzte Punkt ist der praktische. Ein Großhändler mit vierzig Konten, jedes auf seiner eigenen vereinbarten Liste, quartalsweise aus dem ERP aufgefrischt, ist ein CSV-Importjob und keine Plattformmigration.

Multi-Store, Multi-Währung und Mehrsprachigkeit aus einer Codebasis

Ein Store ist in Drupal Commerce eine erstklassige Entität, und Produkte werden den Stores zugewiesen, die sie verkaufen dürfen. Das ist eine kleine Entwurfsentscheidung mit großer Folge: Mehrere Storefronts können einen Katalog, eine Bestellstrecke und eine Verwaltung teilen und dabei unterschiedliche Währungen, Steuerkonfigurationen, Zahlungsgateways und Versandregeln tragen.

Die übliche Form ist eine britische Website, eine EU-Website und ein Händlerportal, alle aus einem Deployment. Produktdaten werden einmal erfasst. Eine Preisliste gilt nur für den Händler-Store. Die Steuer löst sich je Store auf, weil der Store sein eigenes Rechnungsland und seine eigenen Registrierungen trägt.

Drupal-Core bringt außerdem eine wirklich starke mehrsprachige Schicht mit, mit URL-Aliassen je Sprache, übersetzten Entitäten und alternativen Sprachlinks, weshalb Drupal im Hochschulwesen und im öffentlichen Sektor so stark vertreten ist.

Shopify Markets deckt davon inzwischen einiges ab, aber kontextbezogener Checkout und Storefront-Anpassung über Markets sind auf die Tarife Advanced und Plus beschränkt, sodass der Vergleich mindestens gegen £259 im Monat läuft statt gegen £25.

Wenn der Katalog redaktionell ist

Manche Kataloge sind Inhalt. Ein Fachhändler, dessen Produktseiten Kaufberatungen, Vergleichstabellen, technische Erklärstücke und die Notizen eines Testers tragen, betreibt eine Publikation, die nebenbei Zahlungen entgegennimmt.

Auf einer gehosteten Plattform sind das zwei Systeme. Das CMS hält den Artikel, der Shop hält die Artikelnummer, und verbunden werden sie durch einen Link und einen nächtlichen Export. Redakteure arbeiten an zwei Orten, die Suche indexiert zweimal, und die URL-Struktur bekommt eine Naht in der Mitte.

In Drupal Commerce ist ein Produkt eine Entität im selben System wie jeder Artikel, teilt also den redaktionellen Workflow, die Versionsgeschichte, die Taxonomie-Vokabulare, die Medienbibliothek, den Suchindex und das Zugriffsmodell. Eine Produktseite kann drei Artikel referenzieren und ein Artikel neun Produkte, beides als echte Entitätsreferenzen statt als eingefügte Links.

Das ist das Argument, das Drupal am häufigsten für ein Unternehmen rechtfertigt, das sonst bequem auf Shopify säße, und es ist das, was am häufigsten als nette Zugabe abgetan wird, bis ein Redaktionsteam ein Jahr lang in zwei Verwaltungsoberflächen gearbeitet hat.

Regulierte und stark attribuierte Produkte

Produkte, die Compliance-Daten tragen, sind der vierte Fall. Chemikalien mit Sicherheitsdatenblättern. Medizinprodukte mit Zertifikatsnummern und Ablaufdaten. Lebensmittel mit Allergenmatrizen. Elektrogeräte mit Konformitätserklärungen. Alles mit Chargenrückverfolgung oder einem Kennzeichen für eingeschränkten Verkauf.

Die Anforderung ist nicht bloß, diese Werte zu speichern. Sie ist, sie zu prüfen, zu versionieren, den richtigen für die Charge zu zeigen, die ein Kunde tatsächlich erhalten hat, und hinterher zu belegen, was an einem bestimmten Datum veröffentlicht war. Drupals Field-API und sein Revisionssystem leisten das, weil sie für Inhaltssteuerung gebaut wurden und nicht für Merchandising.

Die Durchsetzungsseite zählt genauso. Ein Order-Prozessor kann einen Checkout ablehnen, der einen altersbeschränkten Artikel in ein Land liefern würde, das ihn verbietet, oder der zwei Artikel kombinieren würde, die nicht zusammen transportiert werden dürfen, und er kann das innerhalb der Bestellstrecke tun statt in einem Theme-Template.

Auf einer gehosteten Plattform ist jede dieser Prüfungen eine App, und Apps setzen sich nicht sauber zusammen. Zwei Apps, die beide den Warenkorb verändern, sind zwei Apps, die sich irgendwann uneinig sein werden.

Wenn das ERP die Quelle der Wahrheit ist

Der fünfte Fall ist struktureller Natur. In einem Distributions- oder Fertigungsbetrieb gehören Bestand, Preise, Kundenkredit und Auftragsstatus dem ERP, und die Website ist eine Anzeigefläche mit angehängtem Warenkorb. Die Frage ist nicht, was der Shop kann, sondern wie günstig er mit dem System in Übereinstimmung gehalten werden kann, das tatsächlich das Sagen hat.

Drupal Commerce fühlt sich hier wohl, weil die Integration im eigenen Prozess läuft. Die Queue-API erledigt asynchrone Arbeit, die Migrate-API erledigt wiederholbare, idempotente Importe, und es gibt keinen Zwischenhändler, der pro Datensatz abrechnet oder Ihr Sync-Fenster drosselt. Ein nächtlicher Preis- und Bestandsimport von 200.000 Zeilen ist ein Cronjob.

Auf einer gehosteten Plattform ist dieselbe Integration entweder ein App- oder ein Middleware-Abonnement, und die API-Ratenbegrenzungen der Plattform werden zu einer architektonischen Randbedingung, um die herum Sie entwerfen, statt zu einem Detail. Das ist machbar, und für viele Unternehmen ist es der richtige Kompromiss. Es hört auf, richtig zu sein, wenn der Abgleich gleichzeitig groß, häufig und geschäftskritisch ist.

Wenn die Integrationsarbeit den größeren Teil des Projekts ausmacht und nicht der Shop selbst, dann ist das ein Projekt der Softwareentwicklung mit angehängter Storefront, und es sollte von Anfang an so zugeschnitten werden.

Steuern sind der Punkt, an dem gehostete Plattformen aufhören, günstig zu sein

Steuern sind das stille Kostenzentrum im grenzüberschreitenden E-Commerce, und dort beginnt der Vergleich der Monatsabos, in die Irre zu führen. Zwei Schwellenwerte entscheiden das meiste davon.

Die britische Umsatzsteuer-Registrierungsgrenze

Die GOV.UK-Anleitung dazu, wann man sich für die VAT registrieren muss, setzt die Schwelle bei £90.000 steuerbarem Gesamtumsatz an. Zwei getrennte Tests lösen die Registrierung aus: ein rollierender Zwölfmonatstest, bei dem Sie sich innerhalb von 30 Tagen nach Ende des Monats registrieren müssen, in dem der Umsatz £90.000 überschritten hat, und ein vorausschauender Test, bei dem Sie sich registrieren müssen, sobald Ihnen klar wird, dass der Umsatz in den nächsten 30 Tagen £90.000 übersteigen wird.

Der vorausschauende Test ist der, der wachsende Shops erwischt, weil das Registrierungsdatum der Tag ist, an dem es Ihnen klar wurde, und nicht der Tag, an dem das Geld ankam.

EU-Umsatzsteuer und der One Stop Shop

Die Leitlinie der Europäischen Kommission zum Ort der Besteuerung setzt eine kombinierte Jahresschwelle von EUR 10.000 an, die innergemeinschaftliche Fernverkäufe von Gegenständen sowie Telekommunikations-, Rundfunk- und elektronische Dienstleistungen zusammen umfasst. Darunter liegt der Ort der Besteuerung dort, wo Versand oder Beförderung beginnen. Darüber wandert die Besteuerung dorthin, wo die Beförderung endet, also zum Satz des Kunden in dessen Land.

Der One Stop Shop erlaubt es, all das in einer einzigen Erklärung in einem Mitgliedstaat anzumelden, quartalsweise eingereicht mit Fristen Ende April, Juli, Oktober und Januar. Der Import One Stop Shop deckt aus dem Ausland eingeführte Waren in Sendungen ab, die EUR 150 nicht übersteigen.

Was Drupal Commerce nativ dagegen tut

Commerce liefert ein Steuer-Plugin für die Umsatzsteuer der Europäischen Union im Kern mit statt als Zusatz. Es führt Sätze für alle 27 Mitgliedstaaten plus Monaco, unterscheidet Normalsätze, ermäßigte, mittlere, stark ermäßigte und Nullsätze und behandelt die Sondergebiete, über die pauschale Satztabellen stolpern, darunter Korsika, die Azoren, Madeira, die griechischen Inseln und die österreichische Enklave Jungholz.

Es wendet auch die Regeln an und nicht nur die Sätze: Bestimmungslandbesteuerung für digitale Güter und innergemeinschaftliche Lieferungen zwischen Unternehmen zum Nullsatz, wenn eine gültige Steuernummer vorliegt. Auf einer gehosteten Plattform ist dieses Verhalten typischerweise eine App mit Kosten je Transaktion.

Zahlungen, PCI DSS und wie Sie die Karte entgegennehmen

Wie Sie die Kartennummer erheben, entscheidet über Ihre Compliance-Last, und die Regeln haben sich kürzlich auf eine weithin missverstandene Weise geändert.

Die Klarstellung des PCI Security Standards Council zu den Zulassungskriterien für SAQ A erläutert ein Kriterium, das am 1. April 2025 in Kraft trat. Händler müssen bestätigen, dass ihre Website nicht anfällig für Angriffe durch Skripte ist, die die E-Commerce-Systeme des Händlers beeinträchtigen könnten. Erfüllbar ist das entweder durch die Umsetzung der Techniken aus den PCI-DSS-Anforderungen 6.4.3 und 11.6.1 oder durch eine Bestätigung des Zahlungsdienstleisters, dass seine eingebettete Lösung diese Schutzmaßnahmen enthält.

Die genaue Abgrenzung ist der Teil, den man falsch versteht. Dieses Kriterium gilt nur für Händler, deren Seite das Zahlungsformular des Anbieters einbettet, typischerweise in einem Iframe. Der Council stellt fest, dass es nicht für Händler gilt, die den Kunden zum Anbieter weiterleiten, ob per HTTP-Weiterleitung, Meta-Refresh oder JavaScript, und auch nicht für Händler, die die Zahlungsfunktionen vollständig auslagern.

Eine gehostete Weiterleitung hält die Angriffsfläche also klein. Eingebettete Felder, die besser konvertieren und die fast alle in Wahrheit wollen, holen die Integrität jedes Skripts auf Ihrer Checkout-Seite in Ihr Compliance-Gespräch hinein.

Hier liegt Shopifys echter Vorteil, denn der Checkout gehört ihnen und die Skripte darauf ebenfalls. In Drupal Commerce gehört der Checkout Ihnen, also muss die Antwort konstruiert werden: eine strikte Content-Security-Policy, Subresource Integrity, ein Verzeichnis jedes Skripts, das auf der Zahlungsseite läuft, und eine Änderungserkennung, wenn eines davon sich bewegt. Diese Arbeit ist weder schwierig noch optional, und sie gehört ins Budget statt in die Entdeckungen eines Audits.

Barrierefreiheit ist ein rechtliches und ein kommerzielles Risiko

Fehler bei der Barrierefreiheit im E-Commerce ballen sich im Checkout, also genau dort, wo jeder Fehler unmittelbar Geld kostet.

Die maßgebliche Referenz ist WCAG 2.2, eine W3C-Empfehlung, veröffentlicht am 12. Dezember 2024. Die Kriterien, die in einem Shop greifen, sind konkret. 1.3.5 Identify Input Purpose auf Stufe AA deckt das Autofill von Adress- und Kartenfeldern ab. 3.3.7 Redundant Entry auf Stufe A wird jedes Mal verletzt, wenn ein Checkout den Kunden zwingt, die Lieferadresse im Zahlungsschritt erneut einzutippen. 3.3.8 Accessible Authentication auf Stufe AA regelt Kontoanlage und Anmeldung. 2.5.8 Target Size auf Stufe AA erwischt Mengenschalter und Entfernen-Schaltflächen im Warenkorb, und 1.4.3 Contrast auf Stufe AA erwischt die ausgegraute Schaltfläche, die in Wahrheit aktiv ist.

Zwei weitere liegen rund um die Bestellung selbst: 3.3.1 Error Identification auf Stufe A und 3.3.4 Error Prevention für rechtliche, finanzielle und Datentransaktionen auf Stufe AA, worunter eine Bestellung eindeutig fällt.

Die Rechtslage im Vereinigten Königreich wird oft überzeichnet. Ein privater Händler ist nicht an ein Gesetz gebunden, das eine WCAG-Konformitätsstufe nennt. Es gilt die Pflicht aus Abschnitt 20 des Equality Act 2010, angemessene Vorkehrungen zu treffen, um einen erheblichen Nachteil für behinderte Menschen zu vermeiden, einschließlich Hilfsmitteln. Die Verordnungen, die eine Konformitätsstufe benennen, die Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, gelten für öffentliche Stellen und nicht für Shops.

Der kommerzielle Punkt ist schärfer als der rechtliche. Auf einem gehosteten Theme können Sie nicht immer reparieren, was eine App in Ihren Checkout einschleust. Auf einer Plattform, die Sie kontrollieren, können Sie es.

Was drei Jahre wirklich kosten

Der Vergleich, den die meisten anstellen, ist Monatsabo gegen Monatshosting, und das ist die unbedeutendste Zeile der Tabelle. Aufbaukosten und Wartung dominieren, und bei Volumen dominieren die Transaktionsprozente.

Die Bänder unten sind Hausschätzungen von Mecanik für einen britischen Mid-Market-Shop, mit Ausnahme der Abo- und Gebührenzahlen von Shopify, die in Pfund genau so angegeben sind, wie Shopify sie veröffentlicht. Alles andere ist das, was wir erwarten würden anzubieten, und die Spanne innerhalb jeder Zeile ist breiter als der Abstand zwischen den Plattformen am unteren Ende.

Was jede Zeile dieser Tabelle wirklich kauft

In Prosa: Shopify Advanced kostet über drei Jahre zwischen £9.324 und £12.384 an Abogebühren, je nachdem, ob Sie sich jährlich binden, und enthält das Hosting, addiert aber App-Abos, die realistisch zwischen £5.400 und £14.400 im selben Zeitraum liegen. WooCommerce zahlt nichts für die Plattform und zwischen £3.600 und £14.400 für das Hosting, mit Erweiterungen bei £3.000 bis £9.000 über die drei Jahre. Drupal Commerce zahlt nichts für die Lizenz, gibt mit £5.400 bis £21.600 am meisten für Hosting aus, weil es die schwerste Anwendung der drei ist, und am wenigsten für Add-ons, zwischen nichts und etwa £3.000, weil die Gegenstücke beigetragene Module statt kommerzieller sind.

Beim Aufbau trennen sich die Plattformen. Ein Shopify-Aufbau von £8.000 bis £25.000 kauft einen gestalteten Store mit den üblichen Integrationen, gegenüber £10.000 bis £35.000 auf WooCommerce. Dasselbe Briefing kostet auf Drupal Commerce £35.000 bis £120.000, weil Checkout, Preislogik und Integrationen alle geschrieben statt konfiguriert werden. Die Wartung folgt derselben Form, mit £3.000 bis £9.000 im Jahr für Shopify, £4.000 bis £12.000 für WooCommerce und £12.000 bis £30.000 für Drupal Commerce, was britische Agentur-Tagessätze von rund £600 bis £900 widerspiegelt, die wir in unserem Leitfaden zu Tagessätzen für Drupal-Entwickler behandeln.

Wo die Dreijahressummen landen

Die Dreijahressummen landen bei rund £32.000 bis £79.000 für Shopify, £29.000 bis £94.000 für WooCommerce und £76.000 bis £235.000 für Drupal Commerce. Karten- und Gateway-Gebühren kommen bei allen dreien obendrauf und skalieren mit dem Umsatz, weshalb die Drittanbieter-Gateway-Gebühr von Shopify in Höhe von 0,6 % auf Advanced bei einem Shop mit 1 Million Pfund Umsatz über drei Jahre £18.000 wert ist.

Lesen Sie die Tabelle ehrlich, dann ist Drupal Commerce zwei- bis dreimal so teuer. Das rechtfertigt sich nur, wenn die Alternative in Wahrheit nicht verfügbar ist, was der ganze Sinn der fünf vorangegangenen Abschnitte ist.

Headless und entkoppeltes Drupal Commerce

Drupal Commerce zu entkoppeln ist in einer engen Gruppe von Fällen eine echte Anforderung und im großen Rest eine Mode. Der ehrliche Test lautet, ob etwas anderes als eine Website denselben Katalog braucht.

Es ist eine echte Anforderung, wenn eine native mobile App und eine Website ein Produkt- und Preismodell teilen müssen, wenn ein bestehendes Frontend eines anderen Teams nicht ersetzt wird, wenn Kassenterminals oder Kioske denselben Warenkorb konsumieren, oder wenn ein Designsystem außerhalb des Projekts liegt und sich nicht in Twig ausdrücken lässt. In diesen Fällen ist die API das Produkt und das CMS bewusst unsichtbar.

Es ist Mode, wenn die genannte Begründung Performance lautet. Ein gut gecachtes klassisches Drupal-Frontend liefert anonyme Produktseiten aus dem Edge, und die Rendering-Methode ist selten das, was einen langsamen Shop langsam macht.

Die Kosten konzentrieren sich an einer Stelle. Drupal-Core stellt Inhalte ohne Konfiguration über JSON:API bereit, und das Modul Commerce Cart API legt Warenkörbe hinter eine REST-Schnittstelle, sodass das Lesen eines Katalogs und das Aufbauen eines Warenkorbs nahezu umsonst sind. Der Checkout nicht. Adressbehandlung, Steueranzeige, Versandauswahl, Aktionen, Einbindung des Zahlungselements und Bestellbestätigung müssen alle im Frontend neu gebaut werden, und das sind meist 40 % oder mehr des gesamten Aufbaus.

Die Fünf-Minuten-Entscheidungsregel

Beantworten Sie sechs Fragen zu Ihrem eigenen Katalog. Jedes Ja zählt einen Punkt.

Brauchen Ihre Produkte mehr als drei Optionen oder mehr als 2.048 kaufbare Kombinationen? Zahlen zwei verschiedene Kunden jemals verschiedene Preise für dieselbe Artikelnummer? Verkaufen Sie in mehr als ein Land mit unterschiedlicher Umsatzsteuerbehandlung oder erwarten Sie, eine OSS-Erklärung abzugeben? Ist der Katalog zugleich redaktioneller Inhalt, den dasselbe Team schreibt und pflegt? Ist ein ERP oder ein PIM die Autorität für Preis und Bestand, mit dem Shop stromabwärts davon? Müssen Sie eigene Logik in den Checkout einfügen, statt ihn nur zu branden?

Bei null oder einem Punkt wählen Sie Shopify. Die in diesem Artikel beschriebenen Vorteile gelten nicht für Sie, und Sie würden dafür bezahlen, nachzubauen, was Sie derzeit mieten.

Bei zwei Punkten ist die Entscheidung wirklich offen, wobei WooCommerce oft der bessere Mittelweg ist, besonders wenn das Team ohnehin WordPress betreibt.

Bei drei oder mehr Punkten lohnt es sich, Drupal Commerce ordentlich zu kalkulieren, weil die anderswo nötigen Umwege über drei Jahre mehr kosten als die Plattform. Bei fünf oder sechs Punkten ist die gehostete Plattform keine günstigere Option, sondern ein anderes Produkt, das die Aufgabe nicht erledigt.

Wo Drupal-Commerce-Projekte meist schiefgehen

Der häufigste Fehler ist, es aus dem falschen Grund zu wählen. Wir betreiben schon Drupal ist keine Commerce-Anforderung. Eine Content-Site und eine Transaktions-Site haben unterschiedliche Verfügbarkeitsanforderungen, unterschiedliche Tests und unterschiedliche Folgen, wenn ein Deployment schiefgeht, und den Shop als weiteren Bereich der bestehenden Site zu behandeln ist der Weg, auf dem ein kleines E-Commerce-Projekt ein ungeplantes Plattformteam bekommt.

Der zweite ist zu wenig Budget für die Wartung. Mit 35.870 Installationen ist das Ökosystem klein genug, dass Sie Module mit einer Handvoll Betreuern einsetzen werden, und jemand auf Ihrer Seite muss Sicherheitsmeldungen verfolgen und die Aktualisierungen einplanen. Eine Drupal-Commerce-Site, für die dafür niemand zuständig ist, ist ein Sicherheitsvorfall mit Zeitverzögerung, was wir ausführlicher neben den Hosting-Anforderungen behandeln, die Drupal wirklich hat.

Der dritte ist die Annahme, dass ein Modul existiert. Prüfen Sie das vor der Kalkulation. Wenn es keines gibt, ist die Arbeit eine maßgeschneiderte Website-Entwicklung und braucht eine echte Schätzung statt einer Position in einer Liste.

Der vierte ist die Disziplin bei Hauptversionen. Commerce 3 verlangt Drupal 10.3 oder neuer, und eine Site, die hinter dem Core zurückfällt, stellt irgendwann fest, dass ihre Commerce-Module ohne sie weitergezogen sind. Unser Leitfaden zur Drupal-Entwicklung im Jahr 2026 und der Beitrag zu Migrationskosten und Fristen gehen beide auf diesen Zyklus ein.

Die Entscheidung richtig treffen

Die Wahl entscheidet sich an Produkt- und Preiskomplexität, nicht an Traffic, Umsatz oder Vorliebe. Modellieren Sie Ihren Katalog zuerst auf Papier, mit jeder Option, jedem ausgehandelten Preis und jeder Integration, die mit etwas anderem in Übereinstimmung bleiben muss. Wenn dieses Modell in ein Variantenraster passt, kaufen Sie die gehostete Plattform und geben Sie das gesparte Budget für Merchandising aus.

Mecanik baut und betreut beide Arten von Shop, und wir sagen Ihnen, auf welcher Seite der Linie Sie stehen, bevor wir irgendetwas anbieten. Lautet die Antwort Drupal Commerce, ist die Arbeit ein Projekt der Website-Entwicklung mit erheblichem Integrationsanteil; überwiegt die ERP-Arbeit die Storefront, gehört sie stattdessen unter Softwareentwicklung. Lautet die Antwort Shopify, sagen wir das, und wir sagen es lieber jetzt als achtzehn Monate in einen Neuaufbau hinein.

Häufig gestellte Fragen

Ist Drupal Commerce besser als Shopify? Für die meisten Shops nicht. Shopify ist über drei Jahre günstiger, übernimmt PCI-Compliance und Hosting und hat einen Checkout, der in einem Maßstab getestet ist, den keine Agentur erreicht. Drupal Commerce gewinnt in wenigen Fällen: Produkte mit mehr als drei Optionen oder 2.048 Varianten, kundenspezifisch ausgehandelte Preise, Kataloge, die zugleich redaktioneller Inhalt sind, und Shops, in denen ein ERP Preis und Bestand besitzt.

Was kostet ein Drupal-Commerce-Aufbau im Vereinigten Königreich? Rechnen Sie mit £35.000 bis £120.000 für den Erstaufbau und £12.000 bis £30.000 im Jahr für die Wartung, bei britischen Agentur-Tagessätzen von rund £600 bis £900. Über drei Jahre landet ein Drupal-Commerce-Shop inklusive Hosting typischerweise zwischen £76.000 und £235.000, gegenüber rund £32.000 bis £79.000 für Shopify Advanced. Das sind Hausschätzungen, keine Angebote.

Welche Version von Drupal Commerce sollte ich nutzen? Drupal Commerce 3, derzeit 3.3.8, veröffentlicht am 17. Juli 2026. Es arbeitet mit Drupal 10.3 oder neuer und mit Drupal 11, und seine stabilen Releases fallen unter die Sicherheitsrichtlinie von Drupal. Commerce 2 unterstützte Drupal 9 und 10 und ist der vorherige Release-Zyklus, neue Projekte sollten also auf 3.x starten.

Behandelt Drupal Commerce EU-Umsatzsteuer und OSS? Die Steuerregeln sind im Commerce-Kern eingebaut statt als Zusatz verkauft. Das Plugin für die Umsatzsteuer der Europäischen Union führt Sätze für alle 27 Mitgliedstaaten plus Monaco, unterscheidet Normalsätze, ermäßigte, mittlere, stark ermäßigte und Nullsätze, behandelt Sondergebiete, wendet Bestimmungslandbesteuerung auf digitale Güter an und stellt innergemeinschaftliche B2B-Lieferungen gegen eine gültige Steuernummer auf null. Die OSS-Erklärung bleibt eine Aufgabe der Buchhaltung.

Wann lohnt sich Headless Drupal Commerce? Wenn etwas anderes als eine Website denselben Katalog konsumiert, etwa eine native App, ein Kassenterminal oder ein Frontend, das einem anderen Team gehört. Rein für Geschwindigkeit lohnt es sich nicht, da ein gecachtes klassisches Frontend bereits schnell ist. Kalkulieren Sie den Neubau des Checkouts ein, der typischerweise 40 % oder mehr eines entkoppelten Aufbaus ausmacht.