Shopware 6 Deep Dive: Zwischen Commerce-Kern und Gesamtarchitektur

Executive Snapshot

Shopware 6 ist eine offene, API-orientierte Commerce-Plattform mit besonderer Relevanz für den europäischen Mittelstand. Ihre Stärke liegt in der Verbindung eines anpassbaren Commerce-Kerns mit einer ausgeprägten Erweiterungsarchitektur. Händler können B2C-Geschäftsmodelle, komplexere B2B-Prozesse und unterschiedliche digitale Verkaufskanäle auf einer gemeinsamen technischen Grundlage betreiben.

Mit den B2B Components, Shopware Nexus und neuen agentenorientierten Schnittstellen erweitert der Hersteller das Einsatzspektrum der Plattform. Diese Entwicklungen sind relevant, machen Shopware aber nicht automatisch zu einer vollständigen Unified-Commerce-Plattform oder zu einem System für autonom autorisierte Einkaufsprozesse.

Die entscheidende Unterscheidung liegt zwischen Plattformfunktion und Gesamtarchitektur.

Shopware kann Produktdaten bereitstellen, Warenkörbe verwalten, Bestellungen abwickeln und externe Anwendungen integrieren. Ob daraus konsistente kanalübergreifende Geschäftsprozesse entstehen, hängt auch von ERP, PIM, OMS, CRM und der organisatorischen Verantwortung für deren Zusammenspiel ab.

Ähnliches gilt für Agentic Commerce. Die offizielle, derzeit als Beta angebotene Erweiterung dokumentiert bereits transaktionale Schnittstellen bis zur Bestellaufgabe. Ein technisch möglicher Checkout ist allerdings nicht gleichbedeutend mit einem vollständig autorisierten, eigenständigen Einkauf durch einen AI-Agenten.

Für Unternehmen ist Shopware insbesondere dann eine prüfenswerte Option, wenn ein erweiterbarer Commerce-Kern benötigt wird und die Organisation bereit ist, ihre Integrations- und Betriebsarchitektur bewusst zu gestalten.

Kritisch wird die Entscheidung dort, wo individuelle Erweiterungen, komplexe Prozessabhängigkeiten und unklare Verantwortlichkeiten dauerhaft mehr Aufwand verursachen, als die gewonnene Flexibilität rechtfertigt.

Die entscheidende Frage lautet deshalb nicht, wie viele Funktionen Shopware besitzt. Sondern welche Aufgaben die Plattform im jeweiligen Unternehmen zuverlässig übernehmen soll.

1. Marktposition und tatsächliches Einsatzprofil

Shopware hat seine Marktposition vor allem im deutschsprachigen und europäischen E-Commerce aufgebaut. Die Plattform adressiert Unternehmen, die ihre digitalen Handelsprozesse differenzierter gestalten möchten, als es ein weitgehend standardisiertes Shopmodell erlaubt, ohne dafür sämtliche Commerce-Funktionen selbst entwickeln zu müssen.

Der modulare Aufbau bietet Spielraum für unterschiedliche Produktmodelle, Verkaufskanäle, internationale Storefronts und branchenspezifische Anforderungen. Hinzu kommt ein Ökosystem aus Implementierungspartnern, Technologieanbietern und Erweiterungen.

Diese Flexibilität ist ein wesentlicher Vorteil, verlangt aber Entscheidungen.

Ein Händler mit überschaubarem Sortiment, wenigen Integrationen und standardisiertem Checkout benötigt eine andere Architektur als ein B2B-Unternehmen mit individuellen Kundenkonditionen, mehrstufigen Einkaufsfreigaben und einer tiefen ERP-Anbindung.

Beide können Shopware einsetzen. Daraus folgt nicht, dass beide eine vergleichbar komplexe Implementierung benötigen.

Die Unternehmensgröße allein ist deshalb kein ausreichendes Eignungskriterium.

Wesentlich aussagekräftiger sind Produkt- und Preiskomplexität, internationale Anforderungen, die Zahl der Vertriebskanäle, die bestehende Systemlandschaft und der notwendige Grad an Individualisierung.

Auch die verfügbaren technischen und organisatorischen Fähigkeiten spielen eine Rolle.

Ein stark erweitertes Shopware-System verlangt entweder eigene technische Kompetenz oder eine langfristig belastbare Zusammenarbeit mit spezialisierten Partnern. Die Plattform eröffnet Gestaltungsmöglichkeiten, übernimmt aber nicht automatisch die Verantwortung für deren wirtschaftliche Nutzung.

Gerade im Mittelstand ist deshalb entscheidend, ob die technische Flexibilität tatsächlich benötigt wird und ob das Unternehmen dauerhaft in der Lage ist, sie zu beherrschen.

2. Plattformarchitektur, Editionen und Betriebsmodelle

Ein erweiterbarer Commerce-Kern

Shopware 6 basiert auf einer modularen Architektur mit einem Commerce-Kern, APIs und unterschiedlichen Erweiterungsmechanismen.

Die Admin API ermöglicht administrative Operationen und die Integration angebundener Anwendungen. Die Store API stellt verkaufskanalbezogene Funktionen bereit, darunter Produktinformationen, Kundenkontext, Warenkorb und Checkout.

Über Sales Channels lassen sich unterschiedliche digitale Verkaufskontexte konfigurieren. Shopware kann mit seiner klassischen Storefront eingesetzt oder über die Store API mit einer individuell entwickelten Frontend-Anwendung verbunden werden.

Damit unterstützt die Plattform Headless-Architekturen.

Headless ist allerdings kein Selbstzweck. Eine individuell entwickelte Storefront erhöht die Freiheit bei Benutzerführung und Frontend-Technologie, verlagert aber zusätzliche Verantwortung auf das Projekt. Dazu gehören Rendering, Suchmaschinenoptimierung, Performance, Barrierefreiheit, Tracking und die korrekte Integration der Commerce-Prozesse.

Für viele Unternehmen kann die vorhandene Storefront deshalb wirtschaftlich sinnvoller sein als eine vollständig individualisierte Frontend-Architektur.

Apps und Plugins erfüllen unterschiedliche Aufgaben

Shopware unterscheidet zwischen Apps und Plugins.

Apps arbeiten über definierte Schnittstellen, Ereignisse und externe Dienste. Sie sind dadurch in unterschiedlichen Betriebsmodellen einsetzbar und reduzieren die Notwendigkeit direkter Eingriffe in den Anwendungskern.

Plugins können dagegen tiefer in die PHP-basierte Anwendung eingreifen und zusätzliche Funktionalität innerhalb der Shopware-Laufzeit bereitstellen.

Das eröffnet weitergehende technische Möglichkeiten, erhöht aber gleichzeitig die Bedeutung von Versionskompatibilität, Tests und langfristiger Wartung.

In stark individualisierten Installationen sollte deshalb regelmäßig geprüft werden, welche Erweiterungen tatsächlich notwendig sind, ob sie aktiv gepflegt werden und welche Abhängigkeiten sie innerhalb der Gesamtarchitektur erzeugen.

Die Anzahl installierter Erweiterungen ist dabei weniger entscheidend als deren Bedeutung für geschäftskritische Prozesse.

Ein einzelnes tief integriertes Plugin kann langfristig mehr Aufwand verursachen als mehrere sauber gekapselte Anwendungen.

Edition und Betriebsmodell sind unterschiedliche Entscheidungen

Shopware bietet eine kostenfreie Community Edition sowie die kommerziellen Pläne Rise, Evolve und Beyond.

Rise ergänzt den Commerce-Kern um kommerzielle Funktionen und Herstellersupport. Evolve adressiert weitergehende B2C- und B2B-Anforderungen. Beyond stellt zusätzliche Fähigkeiten für komplexere Handelsmodelle bereit, darunter Multi-Inventory und weitere kommerzielle Funktionen.

Die öffentlich ausgewiesenen Einstiegspreise liegen zum Recherchestichtag bei 600 Euro monatlich für Rise und 2.400 Euro monatlich für Evolve, jeweils zuzüglich Mehrwertsteuer. Beyond wird individuell angeboten.

Diese Preise beschreiben weder einen vollständigen Funktionsumfang unter allen Vertragsbedingungen noch die Gesamtkosten einer Implementierung.

Quelle: Shopware, Pläne und Preise

Unabhängig von der gewählten Edition ist über das Betriebsmodell zu entscheiden.

Bei SaaS übernimmt der Anbieter wesentliche technische Betriebsaufgaben. Die Erweiterbarkeit erfolgt über unterstützte Schnittstellen und appbasierte Mechanismen. PHP-basierte Plugins sind in diesem Modell nicht vorgesehen.

PaaS bietet eine stärker gemanagte Infrastruktur und ermöglicht zugleich tiefere Anpassungen einschließlich Plugins.

Self-Hosted eröffnet die weitreichendste Kontrolle über Anwendung und Infrastruktur, verlagert aber entsprechend mehr Verantwortung für Sicherheit, Updates, Verfügbarkeit und Betrieb auf Händler und Dienstleister.

Diese Unterschiede sind keine bloßen Hostingdetails.

Ein Unternehmen, dessen Geschäftsmodell tiefgreifende Backend-Anpassungen voraussetzt, benötigt ein Betriebsmodell, das diese Erweiterungen tatsächlich zulässt. Ein Unternehmen mit überwiegend standardisierten Prozessen kann dagegen von einer stärker gemanagten Umgebung profitieren.

Die richtige Kombination ergibt sich aus dem benötigten Funktionsumfang, den technischen Anpassungen und der verfügbaren Betriebsorganisation.

3. Commerce-Kern und B2B-Fähigkeiten

B2C: Ein breiter funktionaler Ausgangspunkt

Shopware stellt die wesentlichen Bausteine für klassische digitale Handelsprozesse bereit.

Dazu gehören Produktkataloge, Varianten, Kategorien, Preise, Promotions, Kundenkonten, Warenkörbe, Checkout, Bestellungen sowie die Anbindung von Zahlungs- und Versanddienstleistern.

Über den Rule Builder lassen sich zahlreiche Bedingungen für Preise, Versandmethoden, Aktionen und andere Geschäftsregeln konfigurieren. Unterschiedliche Sales Channels unterstützen länderspezifische, sprachliche und vertriebliche Anforderungen.

Für viele B2C-Geschäftsmodelle entsteht daraus ein leistungsfähiger Ausgangspunkt.

Die entscheidenden Grenzen zeigen sich meist nicht bei der Existenz einzelner Basisfunktionen, sondern bei deren Zusammenspiel.

Komplexe Produktkonfigurationen, individuelle Preislogiken, internationale steuerliche Anforderungen oder anspruchsvolle Fulfillment-Prozesse können zusätzliche kommerzielle Funktionen, Erweiterungen und externe Systeme erfordern.

Auch die Leistungsfähigkeit lässt sich nicht zuverlässig anhand einer pauschalen maximalen Produktzahl bewerten.

Variantenstruktur, Suchtechnologie, Indizierung, Infrastruktur, Erweiterungen und Zugriffsmuster beeinflussen das Verhalten einer konkreten Installation.

Für umfangreiche oder besonders komplexe Kataloge sind deshalb realistische Tests mit den tatsächlichen Daten und Prozessen aussagekräftiger als allgemeine Größenangaben.

B2B: Mehr als ein Geschäftskunden-Login

Im B2B-Bereich hat Shopware sein Funktionsangebot deutlich weiterentwickelt.

Die B2B Components ermöglichen unter anderem Mitarbeiterkonten, Rollen, Organisationseinheiten, Einkaufslisten, Schnellbestellungen, Angebotsprozesse und Bestellfreigaben.

Sie stehen über Shopware Commercial ab dem Evolve-Plan zur Verfügung, wobei einzelne Funktionen von der eingesetzten Shopware-Version abhängen.

Besonders relevant sind die inzwischen dokumentierten Organisations- und Budgetfunktionen.

Hierarchische Organisationseinheiten erlauben es, Standorte, Abteilungen oder Kostenstellen innerhalb einer Kundenorganisation abzubilden. Mitarbeiter können mehreren Einheiten zugeordnet werden und zwischen deren Kontexten wechseln.

Organisationseinheiten können eigene Budgets erhalten. Unter definierten Bedingungen lässt sich auch der Zugriff auf Budgets übergeordneter Einheiten ermöglichen.

Die Budgetverwaltung ist ab Shopware 6.7.4.0 im Evolve-Plan dokumentiert. Ausgabenlimits können innerhalb bestimmter Zeiträume festgelegt werden. Bei Überschreitungen lassen sich Genehmigungsprozesse vorsehen.

Damit bietet Shopware bereits wesentliche Grundlagen für komplexere Beschaffungsorganisationen.

Auch individuelle Preise und Konditionen lassen sich über entsprechende kommerzielle Funktionen abbilden. Der konkrete Umfang hängt von Version, Konfiguration und Vertragsmodell ab.

Quelle: Shopware, B2B Components

Diese Fähigkeiten reduzieren den Bedarf an individuellen Lösungen, ersetzen jedoch nicht zwangsläufig sämtliche Prozesse eines bestehenden ERP- oder Procurement-Systems.

Komplexe Rahmenverträge, Kreditlimits, unternehmensweite Einkaufsrichtlinien und organisationsübergreifende Freigaben können weiterhin von externen Anwendungen abhängen.

Die entscheidende Architekturfrage lautet deshalb, welches System die maßgebliche Quelle für Konditionen, Budgets, Berechtigungen und verbindliche Bestellungen ist.

Gerade bei B2B-Projekten sollte diese Verantwortung vor der Implementierung eindeutig geklärt werden.

Der Übergang von der bisherigen B2B Suite

Für Bestandskunden entsteht eine zusätzliche technische und wirtschaftliche Herausforderung.

Die frühere B2B Suite wird von Shopware nicht mehr weiterentwickelt. Laut Herstellerdokumentation wird sie ab Shopware 6.8 nicht mehr unterstützt. Die weitere Produktentwicklung konzentriert sich auf die B2B Components.

Für neue Evolve-Verträge seit dem 24. Mai 2025 sind ausschließlich die B2B Components vorgesehen.

Quelle: Shopware, B2B Suite und Supportstatus

Eine bestehende B2B-Installation muss deshalb vor einem entsprechenden Versionswechsel auf ihre Migrationsfähigkeit geprüft werden.

Dabei geht es nicht allein um Daten. Individuelle Erweiterungen, Prozesslogik, Berechtigungsstrukturen und Integrationen können ebenfalls betroffen sein.

Die Migration ist somit keine reine Versionsaktualisierung, sondern unter Umständen ein eigenständiges Architekturprojekt.

Für Unternehmen mit bestehenden B2B-Investitionen gehört dieser Übergang in die langfristige Plattformplanung.

4. Unified Commerce und Systemintegration

Mehrere Verkaufskanäle ergeben noch keinen gemeinsamen Handelsprozess

Unified Commerce beschreibt mehr als die parallele Nutzung unterschiedlicher Verkaufskanäle.

Ein Kunde sollte idealerweise über verschiedene Kontaktpunkte hinweg auf konsistente Informationen, Verfügbarkeiten, Konditionen und Serviceprozesse zugreifen können.

Dazu gehören die Verfügbarkeit eines Produkts in einer Filiale, eine online ausgelöste Reservierung, die Abholung vor Ort, eine spätere Retoure über einen anderen Kanal oder ein einheitlicher Zugriff des Kundenservice auf relevante Bestelldaten.

Solche Prozesse betreffen regelmäßig mehrere Systeme.

Shopware kann in einer entsprechenden Architektur die kundenseitige Commerce-Schicht bereitstellen. Sales Channels, APIs, Erweiterungen und kommerzielle Funktionen schaffen dafür wichtige technische Voraussetzungen.

Mit Multi-Inventory bietet der Beyond-Plan zudem Möglichkeiten, Bestände an verschiedenen Standorten zu verwalten.

Das ist eine relevante Fähigkeit, ersetzt aber nicht automatisch sämtliche Aufgaben eines Warehouse-Management- oder Order-Management-Systems.

Ein verlässlich verfügbarer Bestand ist schließlich nicht nur ein gespeicherter Zahlenwert.

Er kann Reservierungen, laufende Aufträge, Lieferwege, Filialbestände und zeitkritische Rückmeldungen unterschiedlicher Anwendungen berücksichtigen müssen.

Die Systemverantwortung entscheidet

Ein PIM kann die führende Quelle für Produktinformationen sein. Ein ERP übernimmt möglicherweise Preis- und Auftragslogik. Ein OMS entscheidet über Fulfillment-Wege, während ein CRM Kundenbeziehungen und ein POS die Vorgänge in der Filiale abbildet.

Shopware muss diese Aufgaben nicht sämtlich selbst übernehmen, um Bestandteil einer funktionierenden Unified-Commerce-Architektur zu sein.

Wesentlich ist, dass die Verantwortlichkeiten eindeutig definiert werden.

Wenn zwei Systeme unabhängig voneinander Bestände verändern dürfen, ohne eine zuverlässige Synchronisation sicherzustellen, entsteht kein Unified Commerce. Es entsteht lediglich ein zusätzlicher Integrationskonflikt.

Gleiches gilt für Kundenidentitäten, Preise und Bestellstatus.

Die Fähigkeit, Daten über APIs auszutauschen, ist eine wichtige Voraussetzung. Sie ist noch kein Nachweis einer konsistenten Geschäftsprozesssteuerung.

Shopware Nexus erweitert die Integrationsmöglichkeiten

Mit Shopware Nexus bietet der Hersteller eine zusätzliche Integrations- und Workflow-Schicht.

Nexus soll ermöglichen, Shopware-Ereignisse mit Workflows, Datenumwandlungen und Aufrufen externer Systeme zu verbinden. Konnektoren und Monitoring-Funktionen unterstützen die Entwicklung und Betreuung solcher Integrationen.

Shopware positioniert Nexus inzwischen als regulär verfügbares Integrationsangebot.

Damit erweitert sich das Spektrum zwischen einer direkten API-Anbindung und einer vollständig individuell entwickelten Integrationslösung.

Quelle: Shopware, Nexus und Produktangebot

Die allgemeine Produktverfügbarkeit beantwortet allerdings noch nicht, ob Nexus sämtliche Anforderungen einer konkreten Enterprise-Integration erfüllt.

Hierzu gehören beispielsweise Transaktionssicherheit, Wiederanlaufverhalten, Fehlerbehandlung, Durchsatz, Monitoring und vertragliche Servicevereinbarungen.

Diese Eigenschaften müssen für den vorgesehenen Einsatzfall überprüft werden.

Auch wirtschaftlich sollte Nexus nicht allein anhand der Nutzungsgebühren bewertet werden.

Das öffentlich dokumentierte Modell berechnet erfolgreich ausgeführte Workflow-Schritte, sogenannte Executions. Die Shopware-Pläne enthalten unterschiedliche monatliche Kontingente. Zusätzliche Nutzung wird separat berechnet.

Die veröffentlichten Preisangaben sind jedoch nicht auf allen Produktseiten vollständig konsistent. Deshalb sollten konkrete Nutzungsgebühren vor einer Projektentscheidung anhand des jeweils gültigen Angebots bestätigt werden.

Die eigentliche Kostenfrage liegt ohnehin häufig in Entwicklung, Datenmapping, Monitoring, Fehlerbehandlung und langfristiger Verantwortung für die verbundenen Prozesse.

Nexus kann diese Aufgaben unterstützen. Es beseitigt nicht die Notwendigkeit einer belastbaren Integrationsarchitektur.

Die praktische Konsequenz

Shopware kann eine zentrale Commerce-Komponente innerhalb einer Unified-Commerce-Architektur sein.

Ob die Plattform selbst wesentliche Prozesse orchestriert oder primär als kundenseitige Commerce-Schicht dient, hängt von der bestehenden Systemlandschaft ab.

Ein vorhandenes leistungsfähiges OMS oder ERP muss kein Nachteil sein. Es kann die wirtschaftlich und organisatorisch sinnvollere Stelle für bestimmte Geschäftsprozesse darstellen.

Problematisch wird es dort, wo fehlende Architekturentscheidungen durch immer neue Schnittstellen kompensiert werden sollen.

Unified Commerce entsteht durch konsistente Prozesse und Verantwortlichkeiten. Die technische Plattform muss diese ermöglichen, kann sie aber nicht allein herstellen.

5. Agentic Commerce entlang des Kaufprozesses

Von der Produktsuche zur ausführbaren Handlung

Agentic Commerce verändert die Art, wie digitale Handelssysteme genutzt werden können.

Bislang bedient ein Kunde die Oberfläche eines Shops überwiegend selbst. Ein AI-Agent kann dagegen Informationen auswerten, Produkte vergleichen, einen Warenkorb vorbereiten und bei entsprechender Berechtigung konkrete Aktionen auslösen.

Damit entstehen zusätzliche Anforderungen an Commerce-Plattformen.

Sie müssen nicht nur Informationen für menschliche Benutzeroberflächen bereitstellen, sondern auch kontrollierbare Zugriffe für externe Softwareakteure ermöglichen.

Shopware hat hierfür inzwischen konkrete technische Funktionen entwickelt.

Die offizielle Agentic-Commerce-Erweiterung

Die offizielle Agentic-Commerce-Erweiterung stellt zwei wesentliche Komponenten bereit.

Ein dedizierter Product Feed Sales Channel dient der maschinenlesbaren Produktbereitstellung für externe AI-Plattformen.

Die Integration des Universal Commerce Protocol, kurz UCP, ermöglicht darüber hinaus standardisierte Commerce-Operationen für kompatible Agenten.

Shopware dokumentiert für die Erweiterung ab Version 1.1.0 unter anderem Katalogzugriff, Warenkorboperationen, Rabatte, Checkout und Bestellstatus.

Die Schnittstelle reicht damit bis zur technischen Aufgabe einer Bestellung.

UCP lässt sich für geeignete Storefront- und Headless-Verkaufskanäle konfigurieren, unabhängig von einem dedizierten Produktfeed-Verkaufskanal.

Als technische Transportmöglichkeiten sind unter anderem REST, A2A, Embedded und abhängig von der technischen Version MCP dokumentiert.

Das sind konkrete transaktionale Fähigkeiten, nicht lediglich experimentelle Produktabfragen.

Gleichzeitig kennzeichnet Shopware die Erweiterung weiterhin als Beta. Funktionsumfang und Verhalten können sich verändern. Außerdem muss der tatsächlich verfügbare Umfang anhand der installierten Extension-Version und der verwendeten Shopware-Version überprüft werden.

Quelle: Shopware, Agentic Commerce Extension

Europäische Verfügbarkeit und konkrete Vertriebskanäle

Bei der praktischen Nutzung muss zwischen den Komponenten der Erweiterung unterschieden werden.

Der Product Feed kann Produktinformationen für externe Systeme bereitstellen. Die Registrierung beim von Shopware dokumentierten ChatGPT-Merchant-Angebot ist zum Recherchestichtag allerdings auf die USA beschränkt.

Für europäische Händler bedeutet die Existenz des entsprechenden Feeds daher noch keine unmittelbar verfügbare Anbindung an diesen konkreten Vertriebskanal.

Davon getrennt ist die UCP-Integration zu betrachten.

Sie ermöglicht kompatiblen Agenten definierte Commerce-Operationen über entsprechend konfigurierte Shopware-Verkaufskanäle. Ihre technische Verfügbarkeit ist nicht automatisch mit der geografischen Beschränkung eines bestimmten Merchant-Angebots gleichzusetzen.

Ebenso darf aus einer funktionierenden UCP-Schnittstelle nicht geschlossen werden, dass jede große AI-Plattform diese bereits produktiv unterstützt.

Für Händler sind deshalb drei Fragen getrennt zu beantworten.

Welche Fähigkeiten stellt Shopware bereit? Welche davon unterstützt die gewünschte Agentenplattform tatsächlich? Und in welchen Regionen sowie unter welchen kommerziellen Bedingungen ist der jeweilige Vertriebskanal nutzbar?

Erst die Verbindung dieser drei Ebenen ergibt eine belastbare Einsatzbewertung.

Die einzelnen Schritte des Kaufprozesses

Bei der Produktbereitstellung geht es zunächst um Datenzugang und Auffindbarkeit.

Entscheidend bleiben Produktdatenqualität, Varianteninformationen, Preise, Verfügbarkeit und Aktualität. Ein maschinenlesbarer Feed verbessert den technischen Zugang, garantiert aber keine korrekte Interpretation durch ein externes AI-System.

Bei der Beratung verlagert sich ein Teil der Verantwortung auf den Agentenanbieter.

Shopware stellt Produkt- und Commerce-Informationen bereit, ist aber nicht automatisch für die Qualität sämtlicher Empfehlungen eines externen Agenten verantwortlich.

Bei Produktauswahl und Warenkorbvorbereitung werden aus Informationen konkrete Commerce-Operationen.

Dabei müssen Varianten, Lieferbedingungen, Mengen und kundenspezifische Konditionen korrekt berücksichtigt werden.

Der Checkout erhöht die Anforderungen nochmals.

Die dokumentierte UCP-Integration kann eine Bestellung technisch auslösen. Ob ein Agent diese Bestellung im konkreten Fall eigenständig ausführen darf, ist eine zusätzliche Frage.

Dafür müssen Kundenidentität, Handlungsvollmacht, Zahlungsautorisierung und die Durchsetzung vereinbarter Grenzen nachgewiesen werden.

Ein Checkout mit ausdrücklicher Bestätigung durch den Kunden stellt andere Anforderungen als ein eigenständiger Einkauf innerhalb eines zuvor erteilten Mandats.

Diese beiden Szenarien dürfen nicht miteinander verwechselt werden.

Protokolle und technische Standards

Im Agentic Commerce begegnen Händlern inzwischen mehrere Standards.

UCP beschreibt standardisierte Commerce-Interaktionen. Das Agentic Commerce Protocol, ACP, adressiert ebenfalls die Verbindung von AI-basierten Einkaufsoberflächen und transaktionalen Handelssystemen.

Das Model Context Protocol, MCP, ermöglicht den strukturierten Aufruf von Werkzeugen und Funktionen durch AI-Systeme.

Das Agent Payments Protocol, AP2, beschäftigt sich mit überprüfbaren Mandaten und Zahlungsautorisierung.

WebMCP verfolgt einen anderen Ansatz, indem Webseiten strukturierte Interaktionsmöglichkeiten für Agenten bereitstellen können.

Diese Standards übernehmen unterschiedliche Aufgaben und sind nicht ohne Weiteres austauschbar.

Für Shopware ist derzeit insbesondere die offiziell dokumentierte UCP-Erweiterung relevant. Weitere agentische Integrationsmöglichkeiten entstehen unter anderem durch MCP und individuelle oder vom Hersteller bereitgestellte Referenzimplementierungen.

Solche Referenzprojekte sind allerdings nicht automatisch Bestandteil eines allgemein verfügbaren kommerziellen Produktumfangs.

Für die praktische Bewertung zählt deshalb weniger der Name eines unterstützten Protokolls als die Frage, welche konkreten Prozesse damit zuverlässig und sicher ausgeführt werden können.

Ein MCP-Endpunkt ist noch kein vollständig delegierter Kaufprozess. Und eine Checkout-Schnittstelle belegt für sich genommen keine Autorisierung autonomer Zahlungen.

Nachkaufprozesse und Service

Agentic Commerce endet nicht mit der Bestellbestätigung.

Auch Stornierungen, Adressänderungen, Ersatzlieferungen, Retouren und Erstattungen können Gegenstand agentischer Handlungen werden.

Shopware verfügt bereits über allgemeine Bestell- und Retourenfunktionen. Über UCP sind zudem Bestellinformationen und entsprechende Statusfunktionen dokumentiert.

Das bedeutet jedoch nicht, dass ein externer Agent sämtliche nachgelagerten Vorgänge ohne weitere Integration ausführen kann.

Eine Retoure im Kundenkonto anzulegen ist etwas anderes, als einem externen Agenten das Recht einzuräumen, diese Retoure im Namen des Kunden auszulösen, Ausnahmen zu behandeln und eine Erstattung nachzuverfolgen.

Für solche Vorgänge müssen Berechtigungen, Prozesszuständigkeiten und gegebenenfalls externe Service- und Logistiksysteme berücksichtigt werden.

Ein vollständig agentenspezifischer Nachkaufprozess über die gesamte Servicekette ist in der geprüften öffentlichen Dokumentation bislang nicht umfassend nachgewiesen.

Was europäische Händler bereits zeigen

Europäische Händler entwickeln unterschiedliche Formen AI-gestützter Einkaufsprozesse.

OTTO, Carrefour und Knuspr zeigen, wie Produktsuche, Beratung oder Warenkorbvorbereitung mit externen AI-Oberflächen verbunden werden können.

In den dokumentierten Angeboten verbleibt der finale Kaufabschluss zumindest in wesentlichen Szenarien beim Händler.

Diese Beispiele belegen keine native Shopware-Funktionalität. Sie verdeutlichen jedoch eine wichtige Architekturentscheidung.

Ein Händler muss nicht sofort den gesamten Kaufprozess an einen externen Agenten delegieren, um AI-basierte Verkaufskanäle zu erschließen.

Für bestehende Shopware-Installationen können bereits eine zuverlässig angebundene Produktsuche und eine kontrollierte Warenkorbvorbereitung sinnvolle Integrationsschritte darstellen.

Weitergehende Transaktionsrechte sollten sich aus konkreten geschäftlichen Anforderungen ergeben, nicht aus der bloßen technischen Möglichkeit.

6. Identität, Autorisierung und Governance

Technischer Zugriff ist keine Handlungsvollmacht

Die zentrale Governance-Frage im Agentic Commerce lautet nicht allein, auf welche Daten und Funktionen ein Agent zugreifen kann.

Entscheidend ist, in wessen Auftrag er handelt, welche Entscheidungen er treffen darf und wie seine Berechtigung überprüft werden kann.

Das unterscheidet einen Einkaufsagenten von einer gewöhnlichen Schnittstellenintegration.

Ein ERP-System kann aufgrund einer dauerhaft eingerichteten Systemberechtigung Bestelldaten übertragen. Ein Einkaufsagent trifft möglicherweise situative Entscheidungen über Produkte, Lieferbedingungen oder den Einsatz finanzieller Mittel.

Diese Entscheidungen müssen sich auf ein nachvollziehbares Mandat zurückführen lassen.

Die Anmeldung an einem Kundenkonto genügt dafür nicht zwangsläufig.

Shopwares dokumentierte Sicherheitsmechanismen

Das öffentliche Repository der offiziellen Agentic-Commerce-Erweiterung dokumentiert verschiedene Sicherheitsmechanismen.

Dazu gehören signierte Kommunikation, Plattformbeschränkungen, Allowlisting, OAuth-basiertes Identity Linking und die Verarbeitung tokenisierter Zahlungen.

Kundenbezogene Operationen werden über die Store API angebunden und sollen damit den vorgesehenen Verkaufskanal- und Kundenkontext berücksichtigen.

Diese Architekturbausteine sind relevant.

Allerdings muss zwischen dokumentierten Entwicklungs- und Implementierungsmechanismen einerseits und dem tatsächlich veröffentlichten, installierten Funktionsumfang andererseits unterschieden werden.

Das Repository beschreibt auch versionsabhängige Funktionen und besondere Entwicklungs- beziehungsweise Testkonfigurationen.

So können für lokale Tests weniger strenge Signaturregeln verwendet werden, während produktive Konfigurationen eine entsprechende Absicherung vorsehen.

Für den produktiven Einsatz müssen deshalb die konkrete Extension-Version, die unterstützte Shopware-Version, die konfigurierte Plattformidentität, Signaturprüfungen und Zugriffsregeln gemeinsam überprüft werden.

Quelle: Shopware, öffentliches Agentic-Commerce-Repository

Diese Mechanismen beweisen nicht automatisch, dass beliebige autonome Einkaufsmandate bereits vollständig abgesichert werden können.

Die Sicherheit einer Schnittstelle und die Berechtigung zu einer konkreten Kaufentscheidung sind unterschiedliche Sachverhalte.

Begrenzte Mandate in der B2B-Beschaffung

Ein Unternehmen könnte einem Einkaufsagenten erlauben, regelmäßig Verbrauchsmaterial zu bestellen.

Ein solches Mandat könnte auf bestimmte Produktgruppen, Lieferadressen, monatliche Budgets und maximale Einzelbestellwerte beschränkt sein.

Ersatzartikel wären möglicherweise nur innerhalb einer vorher festgelegten Auswahl zulässig. Bei Preisüberschreitungen müsste eine menschliche Freigabe erfolgen.

Shopware besitzt mit den B2B Components bereits dokumentierte Möglichkeiten zur Verwaltung von Organisationsstrukturen, Budgets und Genehmigungen.

Das ist eine wertvolle Grundlage.

Daraus folgt allerdings nicht automatisch, dass ein externer Einkaufsagent sämtliche dieser Regeln unverändert übernehmen kann oder dass seine Handlungen bereits über ein vollständiges, eigenständiges Delegationsmodell abgesichert werden.

Die Verbindung zwischen organisatorischer Einkaufsberechtigung und technischer Agentenautorisierung muss konkret hergestellt werden.

Dabei genügt keine natürlichsprachliche Anweisung wie „Bestelle höchstens für 500 Euro“.

Die Grenzen müssen außerhalb des Sprachmodells technisch überprüft und durchgesetzt werden.

Dazu gehören eine verlässliche Identität, gespeicherte Berechtigungen, transaktionsbezogene Prüfungen und die Möglichkeit, ein Mandat jederzeit zu widerrufen.

Gerade im B2B-Bereich muss außerdem geklärt werden, wie die Agentenberechtigung mit bestehenden ERP-, Procurement- und Genehmigungsprozessen zusammenwirkt.

Interne und externe Agenten unterscheiden

Auch innerhalb der Shopware-Produktentwicklung sind zwei unterschiedliche Anwendungsfälle zu betrachten.

Copilot Agentic unterstützt Händler bei administrativen Aufgaben.

Mit Shopware 6.7.15.0 hat der Hersteller diese Funktion im Oktober 2026 als stabil eingestuft. Gleichzeitig wurde die Unterstützung auf weitere kommerzielle Funktionen ausgeweitet, darunter B2B Budget Management, Multi-Warehouse, Abonnements und Product Bundles.

Shopware beschreibt außerdem die Prüfung von Benutzerberechtigungen und die Möglichkeit, Copilot individuellen ACL-Gruppen und Rollen zuzuweisen.

Quelle: Shopware, Release News Oktober 2026

Das ist ein anderer Sicherheitskontext als der Einkauf durch einen externen Agenten im Namen eines Kunden.

Die administrative Berechtigung eines Händlermitarbeiters ersetzt weder die Kundenidentität noch die Autorisierung einer Zahlung.

Der stabile Produktstatus von Copilot Agentic darf deshalb nicht mit dem Beta-Status der separaten Agentic-Commerce-Erweiterung gleichgesetzt werden.

Verantwortung über den Kauf hinaus

Für den produktiven Betrieb müssen außerdem Datenschutz, Protokollierung, Ausnahmesteuerung und die Übergabe an den Kundenservice geregelt werden.

Wenn ein Agent einen ungeeigneten Ersatzartikel bestellt, ein Budget überschreitet oder eine Änderung nach dem Kauf auslöst, muss nachvollziehbar sein, welche Information, Regel und Berechtigung seiner Handlung zugrunde lagen.

Dabei verteilen sich die Verantwortlichkeiten auf Kunde, Agentenanbieter, Händler, Commerce-Plattform, Integrationspartner und Zahlungsdienstleister.

Welche rechtlichen und vertraglichen Pflichten daraus im Einzelfall entstehen, hängt von den tatsächlichen Geschäfts- und Vertragsbeziehungen ab.

Technisch sinnvoll ist deshalb eine begrenzte, überprüfbare und widerrufbare Delegation.

Eine solche Agentenidentität muss nicht zwingend bedeuten, dass jeder Agent ein vollständig separates Kundenkonto erhält. Entscheidend ist, dass sein Handlungsrahmen vom eigentlichen Kunden unterscheidbar bleibt.

Eine ausführlichere Betrachtung dieses Grundsatzes bietet der Essay Der Agent braucht ein eigenes Konto.

7. Implementierung, Betrieb und Wirtschaftlichkeit

Die Lizenz ist nur ein Teil der Rechnung

Shopware veröffentlicht Einstiegspreise für seine kommerziellen Pläne. Daraus lässt sich jedoch kein verlässlicher allgemeiner Projektpreis ableiten.

Der wirtschaftliche Aufwand hängt wesentlich davon ab, welche Systeme integriert, welche Erweiterungen benötigt und welche Prozesse individuell entwickelt werden müssen.

Ein weitgehend standardisierter B2C-Shop kann mit einer überschaubaren Systemlandschaft betrieben werden.

Eine internationale B2B-Installation mit komplexen Konditionen, tiefem ERP-Zugriff und mehreren Verkaufskanälen benötigt dagegen möglicherweise eine deutlich umfassendere Architektur.

Pauschale Aussagen über typische Projektkosten oder Implementierungszeiten würden diesen Unterschied eher verdecken als erklären.

Für die wirtschaftliche Bewertung sind insbesondere Plattformgebühren, Infrastruktur, Erweiterungen, Integrationsaufwand, Datenmigration, Qualitätssicherung und laufender Betrieb relevant.

Hinzu kommen interne Kapazitäten für Produktmanagement, Datenpflege, Architekturentscheidungen und Partnersteuerung.

Diese Kosten entstehen unabhängig davon, ob sie unmittelbar als externe Rechnung sichtbar werden.

Erweiterbarkeit erzeugt dauerhafte Verpflichtungen

Die Möglichkeit, Shopware durch Plugins, Apps und individuelle Entwicklung anzupassen, gehört zu den wesentlichen Stärken der Plattform.

Sie kann aber zu erheblichem Wartungsaufwand führen, wenn Erweiterungen ohne übergreifende Architekturplanung eingeführt werden.

Jede zusätzliche Komponente kann eigene Release-Zyklen, technische Abhängigkeiten, Sicherheitsanforderungen und Supportzuständigkeiten mitbringen.

Besonders kritisch sind Erweiterungen, die zentrale Geschäftslogik verändern oder dieselben Prozesse beeinflussen wie andere Komponenten.

Eine zunächst schnelle Lösung kann langfristig teuer werden, wenn sie spätere Updates erschwert oder geschäftskritische Prozesse von einer unzureichend gepflegten Erweiterung abhängig macht.

Unternehmen sollten deshalb nicht nur dokumentieren, welche Erweiterungen vorhanden sind, sondern auch, warum sie benötigt werden und wer ihre langfristige Funktionsfähigkeit verantwortet.

Datenqualität als betriebliche Voraussetzung

Viele Commerce-Probleme entstehen nicht aus dem Shopsystem selbst.

Unvollständige Produktdaten, widersprüchliche Preise, verzögerte Bestandsmeldungen oder uneinheitliche Kundenidentitäten lassen sich nicht dauerhaft durch zusätzliche Frontend-Funktionen lösen.

Gerade Unified Commerce und Agentic Commerce erhöhen die Bedeutung dieser Grundlagen.

Ein Einkaufsagent kann nur dann zuverlässig mit Produkten, Konditionen und Verfügbarkeiten arbeiten, wenn die entsprechenden Informationen konsistent und aktuell sind.

Ein neuer Verkaufskanal erhöht deshalb häufig den Druck, bestehende Daten- und Prozessprobleme zu beheben. Er beseitigt sie nicht.

Die Verantwortung für die Gesamtarchitektur

Für den langfristigen Betrieb braucht eine Shopware-Installation mehr als einen technischen Dienstleister.

Es muss klar sein, wer geschäftliche Prioritäten festlegt, Änderungen genehmigt, Integrationsrisiken bewertet, Releases koordiniert und bei Fehlern Entscheidungen trifft.

Diese Verantwortung lässt sich operativ unterstützen, aber nicht vollständig an einzelne Erweiterungsanbieter delegieren.

Je stärker Shopware mit anderen Systemen verbunden wird, desto wichtiger wird eine übergreifende Architektur- und Governance-Verantwortung.

Die wirtschaftliche Tragfähigkeit einer Installation hängt damit auch von den organisatorischen Fähigkeiten des Unternehmens ab.

8. Strukturelle Grenzen und die Plattformwechselfrage

Fehlende Standardfunktionen und tatsächliche Architekturgrenzen

Bei der Bewertung einer bestehenden Shopware-Installation sollte zunächst geklärt werden, ob neue Anforderungen innerhalb der vorhandenen Architektur sinnvoll umgesetzt werden können.

Dazu gehören Konfiguration, kommerzielle Funktionen, verfügbare Erweiterungen, externe Services und individuelle Entwicklung.

Eine fehlende native Funktion kann eine relevante Einschränkung sein. Sie ist aber nicht automatisch eine strukturelle Plattformgrenze.

Wenn ein Unternehmen bereits ein leistungsfähiges OMS besitzt, kann dessen Anbindung sinnvoller sein als die Suche nach einer Commerce-Plattform, die sämtliche OMS-Funktionen selbst bereitstellt.

Ebenso kann eine externe Lösung für AI-basierte Beratung oder agentische Produktentdeckung angemessener sein als die Ablösung eines ansonsten funktionierenden Shopsystems.

Entscheidend sind Integrationsaufwand, Sicherheit, Betriebssicherheit und langfristige Wirtschaftlichkeit.

Wo Grenzen tatsächlich beginnen

Eine strukturelle Grenze entsteht dort, wo zentrale Anforderungen dauerhaft gegen die Architektur der Plattform arbeiten.

Das kann der Fall sein, wenn geschäftskritische Prozesse nur durch tiefgreifende und schwer wartbare Eingriffe umsetzbar sind.

Ebenso kann eine Grenze erreicht sein, wenn die notwendige Daten- und Prozesskonsistenz nicht zuverlässig hergestellt werden kann oder das gewünschte Betriebsmodell unverzichtbare Erweiterungsmechanismen ausschließt.

Auch eine dauerhaft schwer beherrschbare Extension-Landschaft kann zu einer strukturellen Belastung werden.

Solche Probleme müssen allerdings konkret nachgewiesen werden.

Die pauschale Behauptung, Shopware sei für eine bestimmte Unternehmensgröße ungeeignet oder für Agentic Commerce nicht ausreichend vorbereitet, bietet dafür keine belastbare Grundlage.

Zu prüfen sind die tatsächlichen Anforderungen, die verfügbare Architektur und die Kosten einer dauerhaft tragfähigen Lösung.

Wann ein Plattformwechsel gerechtfertigt sein kann

Ein Plattformwechsel ist eine ernsthafte Option, wenn notwendige Geschäftsprozesse mit Shopware nur unter unverhältnismäßigem Anpassungsaufwand, unvertretbaren Betriebsrisiken oder dauerhaft ungünstiger Wirtschaftlichkeit realisiert werden können.

Dabei müssen die Kosten eines Wechsels vollständig berücksichtigt werden.

Datenmigration, Integrationsumbau, Prozessanpassungen, organisatorische Umstellung, Suchmaschinenrisiken und die erneute Einarbeitung interner Teams können erhebliche Aufwände verursachen.

Auch eine andere Plattform wird die Probleme einer unklaren Systemarchitektur nicht automatisch lösen.

Wenn die eigentliche Ursache in widersprüchlichen Bestandsdaten, einer unzureichenden ERP-Integration oder fehlender fachlicher Verantwortung liegt, besteht das Risiko, dieselben Probleme auf einer neuen technischen Grundlage erneut aufzubauen.

Eine seriöse Plattformentscheidung beginnt deshalb nicht mit der Suche nach dem neuesten System.

Sie beginnt mit einer belastbaren Analyse der Anforderungen, der tatsächlichen Einschränkungen und der wirtschaftlich tragfähigen Handlungsoptionen.

9. Management-Fazit: Shopware als bewusste Architekturentscheidung

Shopware 6 bietet einen breiten Commerce-Kern, eine flexible Erweiterungsarchitektur und relevante Funktionen für B2C- und B2B-Geschäftsmodelle.

Mit den B2B Components, Shopware Nexus und den agentenorientierten Erweiterungen entwickelt der Hersteller das Einsatzspektrum der Plattform weiter.

Diese Entwicklungen sind für strategische Plattformentscheidungen relevant. Sie machen die zugrunde liegenden Architekturfragen jedoch nicht überflüssig.

Je mehr Commerce-Prozesse über Systemgrenzen hinweg funktionieren müssen, desto weniger genügt die Frage nach einzelnen Features.

Unified Commerce entsteht nicht allein durch mehrere Sales Channels. Agentic Commerce entsteht nicht allein durch eine API für externe Agenten.

Beides verlangt verlässliche Daten, klar geregelte Systemverantwortlichkeiten und kontrollierbare Geschäftsprozesse.

Für Unternehmen mit einer bestehenden Shopware-Installation lautet die erste Frage deshalb nicht, ob eine andere Plattform inzwischen mehr Funktionen verspricht.

Zunächst sollte untersucht werden, welche Anforderungen sich mit dem vorhandenen Commerce-Kern, geeigneten Erweiterungen und einer verbesserten Integrationsarchitektur erreichen lassen.

Bei einer Neuentscheidung ist dagegen zu klären, ob die gewünschte Freiheit bei Architektur und Anpassung tatsächlich benötigt wird und ob die Organisation langfristig in der Lage ist, diese Freiheit zu beherrschen.

Dafür sind insbesondere die folgenden Fragen entscheidend.

Welche Geschäftsprozesse müssen innerhalb von Shopware abgebildet werden und welche liegen bewusst in anderen Systemen?

Wo benötigt das Unternehmen tatsächliche Individualisierung und wo wäre der Standard wirtschaftlich sinnvoller?

Welche Daten, Berechtigungen und Prozessentscheidungen müssen über Systemgrenzen hinweg konsistent bleiben?

Welche zusätzlichen Anforderungen entstehen durch Unified Commerce und agentengestützte Kaufprozesse?

Und welche technischen sowie organisatorischen Verpflichtungen übernimmt das Unternehmen mit der gewählten Architektur langfristig?

Shopware kann unter diesen Voraussetzungen eine tragfähige Lösung sein.

Ob es die richtige ist, entscheidet sich nicht in einer numerischen Bewertungsmatrix, sondern an der Passung zwischen Geschäftsmodell, Systemarchitektur und organisatorischer Realität.

Eine Plattform ist schließlich nicht deshalb gut gewählt, weil sie möglichst viele Dinge kann. Sondern weil sie diejenigen Aufgaben zuverlässig erfüllt, für die sie im Unternehmen tatsächlich verantwortlich sein soll.

---

Quellen und Recherchegrundlage

Recherchestichtag: 27. Oktober 2026

Die Analyse beruht auf öffentlich zugänglicher Hersteller- und Entwicklerdokumentation, Release-Veröffentlichungen, technischen Implementierungsinformationen sowie einer unabhängigen architektonischen und betriebswirtschaftlichen Einordnung.

Wesentliche verwendete Quellen:

Plattform, Editionen und Architektur

Shopware, Pläne und Preise

Shopware Developer Documentation

Shopware Documentation

B2B

Shopware, B2B Components

Shopware, B2B Suite und Supportstatus

Agentic Commerce und Governance

Shopware, Agentic Commerce Extension

Shopware, Agentic Commerce Repository

Shopware, Release News Oktober 2026

Unified Commerce und Integration

Shopware, Nexus-Produktangebot und Preise

Weiterführende redaktionelle Vertiefung

Der Agent braucht ein eigenes Konto

Die Analyse unterscheidet dokumentierte Plattformfunktionen, kommerzielle Erweiterungen, Beta-Funktionen und unabhängige Schlussfolgerungen. Produktumfang, regionale Verfügbarkeit, technische Voraussetzungen und Vertragsbedingungen können sich verändern. Für konkrete Plattformentscheidungen ist deshalb eine Prüfung der tatsächlich benötigten Versionen, Betriebsmodelle und Integrationen erforderlich.