commercetools Deep Dive: Architektur, Verantwortung und wirtschaftlicher Nutzen von Composable Commerce
Eine unabhängige Analyse für Geschäftsführungen, E-Commerce-Verantwortliche und Technologieentscheider
Andreas RiegerExecutive Snapshot
commercetools gehört zu den Commerce-Plattformen, deren Architektur besonders weitreichende Gestaltungsmöglichkeiten eröffnet. Unternehmen können Commerce-Funktionen über APIs in unterschiedliche Vertriebskanäle, Anwendungen und Geschäftsprozesse integrieren, ohne sämtliche Komponenten einer Handelslandschaft aus einem einzigen System beziehen zu müssen.
Diese Freiheit ist allerdings keine eigenständige geschäftliche Qualität. Sie schafft dort Wert, wo unterschiedliche Marken, Märkte, Organisationsstrukturen oder komplexe Prozesse tatsächlich individuelle Lösungen verlangen. Wo solche Anforderungen fehlen, kann dieselbe Freiheit zusätzlichen Entwicklungs-, Integrations- und Koordinationsaufwand verursachen.
Das Produktangebot von commercetools hat sich deutlich erweitert. Neben den Commerce APIs stehen eigene Lösungen für Frontend, Checkout, Integrationen und stationäre Handelsprozesse zur Verfügung. Mit der Commerce Integration Layer übernimmt der Anbieter seit Oktober 2026 außerdem Aufgaben, die früher häufig eine selbst betriebene Integrationsschicht erforderten.
Auch im Agentic Commerce verfügt commercetools über konkrete Produkte und Schnittstellen. Managed MCP Servers ermöglichen den strukturierten Zugriff durch AI-Systeme. AI Hub verbindet Commerce-Funktionen mit ausgewählten agentischen Handelskanälen. Welche Schritte von der Produktentdeckung bis zum Checkout tatsächlich unterstützt werden, hängt jedoch von der jeweiligen Integration ab. Ein technischer Zugang für einen AI-Agenten ist noch keine vollständige Lösung für delegierte Käufe.
Für B2B-Unternehmen bietet commercetools dokumentierte Funktionen für Organisationshierarchien, Käuferrollen, Angebote und mehrstufige Bestellfreigaben. Diese erweiterten Fähigkeiten müssen im jeweiligen Vertragsumfang berücksichtigt werden. Im Unified Commerce gehören inzwischen auch Filialtransaktionen und Bestandsreservierungen zum verfügbaren Funktionsumfang. Die durchgängige Steuerung von ERP, OMS, Fulfilment, CRM und Service bleibt dennoch eine Aufgabe der Gesamtarchitektur.
Die entscheidende Frage lautet deshalb nicht, ob commercetools ausreichend flexibel oder technologisch modern ist. Sie lautet, ob eine Handelsorganisation die zusätzlichen Freiheitsgrade benötigt, die damit verbundenen Verantwortlichkeiten beherrschen kann und aus dieser Architektur einen nachvollziehbaren wirtschaftlichen Nutzen erzielt.
1. Von der Commerce API zur breiteren Commerce-Plattform
Composable Commerce als Architekturentscheidung
commercetools ist eng mit dem Begriff Composable Commerce verbunden. Gemeint ist eine Handelsarchitektur, in der einzelne Funktionen über definierte Schnittstellen miteinander kombiniert werden, statt sämtliche Anforderungen innerhalb einer weitgehend geschlossenen Anwendung abzubilden.
Die Commerce-Funktionen der Plattform stehen über APIs zur Verfügung. Frontends, mobile Anwendungen, Filialsysteme und weitere Vertriebskanäle können auf diese Funktionen zugreifen. Produktdaten, Preise, Warenkörbe und Bestellungen lassen sich dadurch in unterschiedliche Kundenerlebnisse integrieren.
Das ist insbesondere für Unternehmen interessant, deren Geschäftsmodell nicht vollständig durch die Abläufe einer standardisierten Shopanwendung beschrieben werden kann.
Ein Hersteller mit Direktvertrieb, internationalen Händlern und einem komplexen Ersatzteilgeschäft benötigt möglicherweise unterschiedliche Kaufprozesse auf einer gemeinsamen Commerce-Grundlage. Ein Multimarken-Händler kann separate Kundenerlebnisse betreiben und dennoch bestimmte fachliche Funktionen gemeinsam nutzen.
Die technische Möglichkeit allein rechtfertigt jedoch noch keine solche Architektur. Sie muss einen konkreten betrieblichen oder wirtschaftlichen Vorteil erzeugen.
MACH, Headless und API-first beschreiben dabei wichtige Architekturprinzipien. Sie liefern aber keinen unabhängigen Nachweis für die Qualität einer Implementierung. Auch eine API-basierte Landschaft kann schwer wartbar sein, und auch eine modular aufgebaute Anwendung kann erhebliche Abhängigkeiten zwischen ihren Komponenten aufweisen.
Entscheidend ist nicht die Terminologie, sondern wie gut sich die Architektur unter realen Geschäftsbedingungen verändern, betreiben und kontrollieren lässt.
Ein Produktportfolio mit mehreren Verantwortungsmodellen
Die historische Einordnung von commercetools als Commerce-Kern, um den Händler sämtliche weiteren Anwendungen selbst entwickeln müssen, ist inzwischen zu einfach.
Mit commercetools Frontend besteht ein eigenes Angebot für die Gestaltung und Bereitstellung von Storefronts. Checkout ergänzt den Kaufabschluss. Connect und das zugehörige Ökosystem unterstützen die Bereitstellung und den Betrieb von Integrationen. InStore erweitert die Plattform um Funktionen für den stationären Handel. [1][2]
Diese Angebote sind nicht automatisch Bestandteil jedes Commerce-Vertrags. Der tatsächliche Funktionsumfang hängt von den gewählten Produkten, den vertraglichen Bedingungen und den technischen Voraussetzungen ab.
Besonders relevant ist die seit dem 14. Oktober 2026 allgemein verfügbare Commerce Integration Layer. Sie stellt eine von commercetools betriebene Experience API auf GraphQL-Basis bereit, in die sich eigene Logik und externe Services integrieren lassen. Die Plattform übernimmt dabei unter anderem die Bereitstellung der Integrationslaufzeit und Teile der Verwaltung von Shopper Sessions. [3][4]
Damit wird eine Aufgabe adressiert, für die Unternehmen bislang häufig eine eigene Backend-for-Frontend-Schicht entwickelt und betrieben haben. Der Zugriff auf die Commerce APIs lässt sich mit Informationen anderer Systeme kombinieren, ohne zwingend eine vollständig selbst betriebene Anwendung dazwischenzuschalten.
Die Commerce Integration Layer benötigt allerdings eine projektspezifische Freischaltung und Aktivierung. Allgemeine Produktverfügbarkeit bedeutet deshalb nicht, dass die Funktion ohne weitere Voraussetzungen in jedem bestehenden Projekt unmittelbar nutzbar ist.
Der gemanagte Ansatz kann Infrastruktur- und Betriebsaufwand reduzieren. Gleichzeitig verlagert er bestimmte technische Abhängigkeiten auf das Produktangebot, die Einsatzbedingungen und das Betriebsmodell von commercetools. Diese Abhängigkeiten gehören ebenso in die Architektur- und Wirtschaftlichkeitsbewertung wie die dadurch entfallenden Eigenentwicklungen.
Das erweiterte Portfolio verändert somit die Verteilung technischer Verantwortung. Die Entscheidung, wie daraus eine dauerhaft tragfähige Handelsarchitektur entsteht, bleibt jedoch eine Aufgabe des Unternehmens.
2. Architektur und Betriebsmodell: Wo die Verantwortung tatsächlich liegt
Der Commerce-Kern als gemeinsame Geschäftsgrundlage
Die Commerce APIs bilden den fachlichen Kern der Plattform. Sie stellen Ressourcen für Produkte, Preise, Bestände, Kunden, Warenkörbe und Bestellungen bereit. [1]
Das Produktmodell unterstützt Varianten, Attribute und unterschiedliche Strukturen für Sortimente. Stores und Channels erlauben eine Differenzierung nach Vertriebskontext, Preislogik und Bestandszuordnung. Die Plattform kann damit mehrere Marken, Märkte und Verkaufskanäle innerhalb einer abgestimmten Architektur unterstützen.
Die entscheidende Architekturfrage lautet, welche Daten und Geschäftsregeln commercetools tatsächlich führen soll.
In vielen Handelsunternehmen bleiben ERP oder PIM die maßgeblichen Systeme für bestimmte Stammdaten. Ein ERP kann Vertragskonditionen verwalten, während ein PIM Produktinformationen anreichert. Ein OMS koordiniert Lieferwege und ein separates Loyalty-System verwaltet Kundenansprüche.
commercetools kann diese Informationen für den Verkauf nutzbar machen. Die Existenz entsprechender APIs beantwortet aber nicht, welche Anwendung bei widersprüchlichen Daten entscheidet.
Diese Verantwortlichkeiten sollten bereits vor einer Implementierung geklärt werden.
Erweiterbarkeit ohne vollständige Eigenentwicklung
Die Plattform verfügt über mehrere Mechanismen für Erweiterungen und Integrationen.
API Extensions ermöglichen es, bestimmte Änderungen synchron durch externe Logik prüfen oder beeinflussen zu lassen. Subscriptions informieren angebundene Systeme über definierte Änderungen und Nachrichten. Connect stellt eine verwaltete Laufzeit für Erweiterungen und Integrationskomponenten bereit. [2][5]
Solche Mechanismen reduzieren den Aufwand für den technischen Anschluss zusätzlicher Systeme. Die fachliche Integrationsarchitektur muss dennoch bewusst gestaltet werden.
Ein Ereignis aus einem Bestellprozess kann beispielsweise eine Aktualisierung im ERP anstoßen. Kommt diese Nachricht verspätet an, schlägt die Verarbeitung fehl oder lässt sich eine Änderung nicht mehr rückgängig machen, muss die Gesamtarchitektur damit umgehen können.
Die Dokumentation von commercetools unterscheidet bei Subscriptions zwischen Messages, Changes und bestimmten als Beta gekennzeichneten Events. Daraus lässt sich keine allgemeine Event-Sourcing-Architektur ableiten, in der sämtliche Geschäftszustände vollständig und dauerhaft als Ereignisfolge rekonstruiert werden könnten. [5]
Für Unternehmen ist die Unterscheidung erheblich. Eine ereignisbasierte Integration gewährleistet nicht automatisch konsistente Ende-zu-Ende-Prozesse.
Cloud-Betrieb und technische Governance
commercetools wird als Cloud-Service in unterschiedlichen Regionen betrieben, darunter europäische Umgebungen auf Google Cloud und AWS. Die dokumentierten Regionen sind voneinander isoliert. [1]
Damit können Unternehmen die regionale Bereitstellung des Commerce-Kerns gezielt berücksichtigen.
Für eine vollständige Datenschutz- und Datenresidenzbewertung müssen jedoch auch die Datenflüsse zusätzlicher Suchdienste, Zahlungsanbieter, Analysewerkzeuge, Integrationsplattformen und AI-Systeme untersucht werden.
Die betriebliche Verantwortung verteilt sich auf mehrere Ebenen.
commercetools betreibt die eigenen Plattformdienste. Unternehmen beziehungsweise ihre Implementierungspartner verantworten weiterhin das fachliche Datenmodell, kundenspezifische Erweiterungen und die Integration mit anderen Anwendungen.
Die Qualität der Gesamtlandschaft hängt deshalb nicht allein von der Verfügbarkeit der Commerce APIs ab. Ebenso relevant sind Monitoring, Fehlerbehandlung, Release-Kompatibilität, Sicherheitskonzepte und die Fähigkeit, Probleme über mehrere Systeme hinweg zu erkennen.
Composable Commerce verteilt Verantwortung auf mehrere Beteiligte. Diese Verteilung muss bewusst gestaltet und dauerhaft gesteuert werden.
3. B2C und B2B: Zwischen Plattformfunktion und Geschäftsprozess
Der B2C-Kern ist umfangreicher als ein API-Baukasten
Für klassische B2C-Prozesse stellt commercetools wesentliche Handelsfunktionen bereit. Dazu gehören Produktkataloge, Varianten, Preis- und Rabattmechanismen, Warenkörbe, Bestellungen sowie Kundenkonten.
Mit Checkout existiert darüber hinaus ein eigenes Produkt für die Gestaltung des Kaufabschlusses. Unternehmen müssen deshalb nicht grundsätzlich jeden Checkout vollständig selbst entwickeln. [2]
Für die Produktsuche bietet commercetools ebenfalls native Funktionen. Product Search unterstützt unter anderem Volltextsuche, Filter und Facetten. [6]
Die tatsächlichen Eigenschaften hängen jedoch vom verwendeten Katalogmodell und den konkreten Anforderungen ab.
Modular Catalog und die Grenzen der Produktsuche
Der am 29. September 2026 allgemein verfügbar gewordene Modular Catalog erlaubt die eigenständige Verwaltung von Produktvarianten und unterstützt bis zu 10.000 Varianten pro Produkt. Die Product Search für dieses neue Katalogmodell befindet sich zum Recherchestichtag allerdings noch in einer öffentlichen Beta. [7]
Hinzu kommt eine technisch relevante Begrenzung. Bei Modular Catalog teilen sich die indexierten Varianten und die indexierten Standalone Prices eines Produkts ein gemeinsames Limit von 10.000 Einträgen. Varianten werden bei der Indexierung bevorzugt. Die verbleibende Kapazität steht für Preise zur Verfügung.
Ein Produkt mit 9.500 indexierten Varianten und 1.200 Standalone Prices kann deshalb innerhalb dieses Limits nur 500 der Preise indexieren. Die Auswahl der berücksichtigten Preise folgt den dokumentierten Indexierungsregeln.
Auch Product Tailoring wird von Product Search nicht als individuell zugeschnittene Produktdarstellung zurückgegeben. Entsprechende Daten müssen über dafür geeignete Produkt- beziehungsweise Projektion-APIs abgerufen werden. [6][8]
Diese Besonderheiten sind für internationale Händler, umfangreiche Variantenmodelle und komplexe kundenspezifische Preisstrukturen relevant.
Sie bedeuten nicht, dass entsprechende Kataloge mit commercetools grundsätzlich ungeeignet wären. Sie zeigen vielmehr, dass Datenmodell, Sucharchitektur und Preisermittlung gemeinsam geplant und unter realistischen Last- und Datenbedingungen getestet werden müssen.
Die Existenz einer nativen Suchfunktion ersetzt diese Prüfung nicht.
B2B beginnt nicht erst mit individueller Entwicklung
Im B2B-Bereich bietet commercetools dokumentierte Funktionen, die über eine einfache Erweiterung des B2C-Kundenmodells hinausgehen.
Business Units bilden Unternehmen und organisatorische Einheiten ab. Über Associates und Associate Roles können unterschiedliche Käuferrollen und Berechtigungen verwaltet werden.
Business Units unterstützen hierarchische Strukturen. Die standardmäßige Grenze liegt bei fünf Hierarchieebenen, wobei unter bestimmten Voraussetzungen eine Erweiterung möglich ist.
Warenkörbe, Bestellungen, wiederkehrende Bestellungen, Einkaufslisten, Angebotsanfragen und Angebote können mit Business Units verknüpft werden. [9]
Mit Approval Rules lassen sich außerdem mehrstufige Bestellfreigaben definieren. Die Regeln können an Rollen und Bedingungen gekoppelt werden und innerhalb der Organisationshierarchie gelten. [10]
Diese Funktionen sind eine relevante Grundlage für komplexere B2B-Prozesse.
Bei der kommerziellen Bewertung ist allerdings zwischen dokumentierter technischer Funktionalität und vertraglich enthaltenem Leistungsumfang zu unterscheiden. commercetools führt die Advanced B2B APIs als ergänzendes Angebot auf. Ihre Verfügbarkeit darf deshalb nicht für jede Produktkonfiguration oder jeden Vertrag automatisch vorausgesetzt werden. [11]
Ebenso wenig bedeutet die technische Verfügbarkeit dieser Funktionen, dass sämtliche Anforderungen aus dem industriellen Einkauf bereits vollständig als Standardprozess vorliegen.
Ein Unternehmen kann beispielsweise kundenspezifische Vertragskonditionen, Rahmenbestellungen, projektbezogene Budgets, Kostenstellenlogik oder eine mehrstufige Freigabe über externe Beschaffungssysteme benötigen.
Ein Teil dieser Anforderungen lässt sich möglicherweise über vorhandene Funktionen modellieren. Andere erfordern zusätzliche Fachlogik oder die Integration eines führenden ERP- beziehungsweise Procurement-Systems.
Die relevante Frage lautet daher, ob die konkrete Kombination aus Organisationsstruktur, Konditionsmodell, Bestellprozess und bestehenden Unternehmenssystemen mit vertretbarem Aufwand umgesetzt werden kann.
Geschäftslogik entscheidet über den tatsächlichen Nutzen
B2C und B2B sollten nicht ausschließlich über die Zahl verfügbarer Funktionen unterschieden werden.
Ein B2C-Händler mit internationalem Sortiment, komplexer Verfügbarkeit und mehreren Fulfilment-Partnern kann anspruchsvollere Architekturprobleme haben als ein B2B-Unternehmen mit standardisierten Bestellprozessen.
Umgekehrt kann ein Industriezulieferer mit relativ überschaubarem Katalog eine sehr komplexe Preis- und Vertragslogik besitzen.
Die fachliche Eignung von commercetools ergibt sich deshalb aus dem Verhältnis zwischen vorhandenen Plattformfunktionen und tatsächlich benötigten Prozessen.
Individuelle Lösungen können sinnvoll sein, wenn sie einen realen Wettbewerbsvorteil ermöglichen. Sie werden wirtschaftlich problematisch, wenn der damit verbundene Aufwand keinen angemessenen zusätzlichen Nutzen erzeugt.
4. Unified Commerce: Die Plattform als Teil einer größeren Handelsarchitektur
Kanalübergreifender Handel benötigt mehr als gemeinsame APIs
Unified Commerce beschreibt nicht nur die technische Verbindung mehrerer Vertriebskanäle.
Eine durchgängige Handelsarchitektur soll ermöglichen, dass Kunden, Mitarbeitende und angebundene Systeme auf konsistente Informationen und abgestimmte Prozesse zugreifen können.
Ein Kunde möchte beispielsweise online die Verfügbarkeit eines Produkts in einer Filiale prüfen, es dort abholen und später an einem anderen Standort zurückgeben. Der Kundenservice muss die ursprüngliche Bestellung nachvollziehen können, während Bestands-, Zahlungs- und Retourensysteme ihre jeweiligen Informationen korrekt verarbeiten.
Eine Commerce API kann wichtige Bestandteile dieses Prozesses bereitstellen. Die tatsächliche Ausführung hängt aber vom Zusammenspiel der gesamten Systemlandschaft ab.
InStore verändert die bisherige Einordnung
Mit commercetools InStore steht inzwischen eine eigene Lösung für stationäre Handelsprozesse zur Verfügung. Das Produkt ist seit Januar 2025 allgemein verfügbar. [12]
InStore unterstützt unter anderem Verkäufe in Filialen, unterschiedliche Zahlungsarten, Rückerstattungen, kanalübergreifende Retouren und Umtauschvorgänge. Auch Funktionen für Kassenarbeitsplätze und die Einbindung verschiedener Geräte sind dokumentiert.
Damit ist die frühere Aussage, commercetools könne stationäre Verkaufsprozesse ausschließlich über externe POS-Systeme abbilden, nicht mehr zutreffend.
InStore erweitert den möglichen Einsatzbereich der Plattform deutlich.
Es ersetzt jedoch nicht automatisch sämtliche bestehenden Filial- und Unternehmenssysteme. Steuerliche und fiskalische Anforderungen, regionale Zahlungsprozesse, Hardwarelandschaften, ERP-Integration und die Koordination des Fulfilments müssen weiterhin konkret geprüft werden.
Die Verfügbarkeit einer Filialanwendung ist deshalb von einer vollständig integrierten Unified-Commerce-Implementierung zu unterscheiden.
Bestände und Reservierungen als Beispiel für reale Prozesskomplexität
Besonders deutlich wird die Bedeutung einer präzisen Architekturbetrachtung beim Bestandsmanagement.
commercetools unterstützt Inventory Entries mit Zuordnung zu Supply Channels. Für Warenkörbe stehen unterschiedliche Inventory Modes zur Verfügung, die festlegen, wann Bestände geprüft oder reserviert werden.
Mit ReserveOnCart können Artikel bereits während des Warenkorbprozesses reserviert werden. Die Funktion ist seit dem 4. Juni 2026 allgemein verfügbar. [13][14]
Eine wichtige technische Besonderheit ist die Unterscheidung zwischen Reservierungsprüfung und angezeigtem Bestandswert.
Während direkte Änderungen an Inventory Entries stark konsistent verarbeitet werden, können bestimmte Bestandsanzeigen nach reservierungs- oder bestellbedingten Änderungen zeitverzögert aktualisiert werden. Die dokumentierte Verzögerung beträgt unter bestimmten Bedingungen bis zu zehn Sekunden.
Die Reservierungslogik verwendet dafür eine interne Echtzeit-Verfügbarkeitsprüfung. Eine verzögerte Aktualisierung sichtbarer Bestandsfelder bedeutet somit nicht automatisch, dass die Reservierung selbst unzuverlässig ist. [13]
Für eine Handelsorganisation bleibt dennoch entscheidend, wie Bestände aus Lager-, Filial- und Fulfilment-Systemen zusammengeführt werden.
Ein technisch korrekt reservierter Bestand in commercetools garantiert nicht, dass eine physische Ware im Lager tatsächlich auffindbar ist oder rechtzeitig zugestellt werden kann.
Diese Unterscheidung zwischen Plattformfunktion und operativer Prozessqualität ist für Unified Commerce wesentlich.
Die Frage nach der führenden Instanz
Die größte Herausforderung liegt häufig nicht im technischen Datenaustausch, sondern in der Verantwortung für Entscheidungen.
Welches System bestimmt den tatsächlich verfügbaren Bestand? Wo wird eine Retoure endgültig freigegeben? Welche Anwendung berechnet verbindliche Kundenvorteile? Und wer entscheidet, welcher Auftrag bei konkurrierenden Fulfilment-Möglichkeiten Vorrang erhält?
Solche Regeln können nicht durch die bloße Existenz von Integrationen ersetzt werden.
commercetools bietet Commerce-Funktionen, Filialanwendungen und Integrationsmechanismen, die wichtige Teile einer Unified-Commerce-Landschaft abdecken können.
Ob daraus verlässliche kanalübergreifende Handelsprozesse entstehen, entscheidet sich an den fachlichen Verantwortlichkeiten, Datenmodellen und der Fähigkeit, Fehler über Systemgrenzen hinweg zu beherrschen.
5. Agentic Commerce: Vom Produktzugang zur verbindlichen Bestellung
Eine neue Schnittstelle ist noch kein neuer Vertriebskanal
Agentic Commerce erweitert die Möglichkeiten, wie Kunden mit Handelsunternehmen interagieren.
Statt ausschließlich über Suchmasken und Produktlisten zu navigieren, können Kunden natürliche Sprache verwenden, um Produkte zu finden, Alternativen zu vergleichen oder einen Kauf vorzubereiten.
Fortgeschrittene Anwendungen können außerdem Aktionen in Commerce-Systemen auslösen. Dazu gehören die Zusammenstellung eines Warenkorbs, die Prüfung von Preisen und Verfügbarkeiten oder die Vorbereitung eines Checkouts.
Damit verändern sich die Anforderungen an die technische Bereitstellung von Handelsfunktionen.
Produktdaten müssen nicht nur für Menschen verständlich, sondern auch für maschinelle Systeme zuverlässig interpretierbar sein. Preis- und Bestandsinformationen müssen im richtigen Kontext abgerufen werden. Und ein Agent muss unterscheiden können, ob er eine Information liefern, eine Bestellung vorbereiten oder tatsächlich eine verbindliche Handlung ausführen darf.
commercetools verfügt hierfür inzwischen über konkrete technische Angebote.
Commerce MCP und AI Hub erfüllen unterschiedliche Aufgaben
Mit Commerce MCP können AI-Systeme über das Model Context Protocol auf ausgewählte Commerce-Funktionen zugreifen.
Managed MCP Servers sind seit dem 16. Juli 2026 allgemein verfügbar. Unternehmen können konfigurieren, welche Werkzeuge bereitgestellt werden und wie AI-Anwendungen technisch auf ein commercetools-Projekt zugreifen. [15][16]
Damit existiert ein standardisierter technischer Weg, Commerce-Ressourcen für AI-basierte Anwendungen zugänglich zu machen.
Die Begrenzung verfügbarer Werkzeuge ist ein Bestandteil technischer Zugriffskontrolle. Eine vollständige Prüfung, ob ein Agent für einen bestimmten Kunden eine wirtschaftlich verbindliche Entscheidung treffen darf, muss gesondert erfolgen.
AI Hub verfolgt einen ergänzenden Ansatz. Das Produkt verbindet die bestehende Commerce-Plattform mit ausgewählten agentischen Handelskanälen.
Dazu gehören Integrationen für Google, OpenAI und Stripe Agentic Commerce Suite. AI Hub stellt dabei Funktionen zur Synchronisierung von Produktdaten und, je nach Anbieter, zur Integration von Checkout- oder Bestellprozessen bereit. [17][18]
Drei Integrationswege mit unterschiedlichem Funktionsumfang
Die direkte Google-Anbindung innerhalb von AI Hub unterstützt Product Discovery und einen UCP-basierten Checkout. Dafür müssen die vorgesehenen technischen Voraussetzungen erfüllt und geeignete Zahlungsdienstleister eingebunden werden.
Die direkte OpenAI-Anbindung innerhalb von AI Hub unterstützt zum Recherchestichtag die Produktsynchronisierung und Product Discovery. Ein eigener Checkout ist in diesem spezifischen Integrationsmodul nicht verfügbar.
Stripe Agentic Commerce Suite bildet einen dritten Ansatz. Über diese Integration können agentische Transaktionen durch Stripe verarbeitet und die daraus entstandenen Bestellungen nach commercetools zurückgeführt werden. Das Modell kann verschiedene AI-Kanäle einbeziehen, abhängig von deren technischer Unterstützung und den Voraussetzungen des Zahlungsdienstleisters. [17][18]
Der fehlende Checkout im direkten OpenAI-Modul bedeutet daher nicht, dass ein Kaufabschluss unter Beteiligung von ChatGPT grundsätzlich ausgeschlossen wäre. Die Stripe-Anbindung verfolgt einen anderen technischen Weg.
Ebenso ist die dokumentierte Checkout-Funktionalität der Google-Anbindung nicht mit einer uneingeschränkten Verfügbarkeit für jeden Händler und jedes Land gleichzusetzen. Anbieterzulassung, regionale Voraussetzungen, aktivierte Produkte und unterstützte Zahlungsdienstleister müssen berücksichtigt werden.
Die drei Integrationsmodelle dürfen deshalb nicht zu einer einzigen pauschalen Aussage über die Agentic-Commerce-Fähigkeit von commercetools zusammengeführt werden.
Der vollständige Kaufprozess als Prüfmaßstab
Der Begriff Agentic Commerce wird häufig bereits verwendet, wenn eine Anwendung Produkte über natürliche Sprache auffindbar macht.
Für eine Architekturentscheidung ist diese Definition zu ungenau.
Zwischen Produktsuche und eigenständig ausgeführtem Kauf liegen mehrere unterschiedliche Prozessschritte.
Zunächst muss ein Agent Produkte und deren Eigenschaften zuverlässig erfassen können. Anschließend benötigt er Zugriff auf relevante Informationen zu Varianten, Preisen und Verfügbarkeiten.
Bei einer konkreten Kaufabsicht muss die gewünschte Produktauswahl in einen überprüfbaren Warenkorb überführt werden. Dabei können Steuern, Versandkosten, Rabatte und kundenspezifische Konditionen die Entscheidung verändern.
Ein Checkout mit ausdrücklicher Kundenbestätigung stellt wiederum andere Anforderungen als ein Kauf, den ein Agent innerhalb einer vorher erteilten Vollmacht selbstständig ausführen soll.
Spätestens bei der Zahlungsautorisierung werden weitere Beteiligte relevant. Zahlungsdienstleister müssen die Transaktion sicher und entsprechend ihrem jeweiligen Verfahren verarbeiten.
Nach dem Kauf endet die Verantwortung nicht. Änderungen, Stornierungen, Retouren und Serviceanfragen können ebenfalls über agentische Kanäle entstehen.
commercetools bietet für mehrere dieser Schritte native Commerce-Funktionen oder dokumentierte Integrationen.
Eine allgemein verfügbare, vollständige Lösung für sämtliche Formen autonomer Kaufentscheidung einschließlich delegierter Handlungsvollmacht, Zahlungsautorisierung und nachgelagerter Serviceprozesse lässt sich daraus jedoch nicht ableiten.
Standards schaffen Verbindung, aber noch keine vollständige Prozesskontrolle
Mehrere technische Ansätze sind für diese Entwicklung relevant.
Das Universal Commerce Protocol, kurz UCP, adressiert standardisierte Commerce-Prozesse über agentische Kanäle.
Das Agentic Commerce Protocol, ACP, ist insbesondere im Umfeld von OpenAI und Stripe für agentische Kauf- und Checkout-Prozesse relevant.
Das Agent Payments Protocol, AP2, beschäftigt sich mit der Autorisierung und Nachweisbarkeit agentisch veranlasster Zahlungen.
MCP ermöglicht den strukturierten Zugriff auf Werkzeuge und Datenquellen. WebMCP verfolgt einen browserbezogenen Ansatz zur Bereitstellung solcher Werkzeuge und befindet sich zum Recherchestichtag noch im Stadium eines Community-Group-Entwurfs. [19][20][21]
Diese Standards erfüllen unterschiedliche Aufgaben. Sie sind nicht austauschbar und bilden gemeinsam auch noch keine automatisch funktionsfähige Handelsarchitektur.
Für commercetools sind konkrete MCP- und UCP-Fähigkeiten dokumentiert. Bei ACP bestehen nachweisbare Ökosystem- und Integrationsbezüge.
Eine eigenständige native AP2- oder WebMCP-Implementierung konnte zum Recherchestichtag nicht ausreichend belegt werden.
Die Konsequenz ist eine präzise Prüfung der gewünschten Prozesse und der tatsächlich verfügbaren Integrationsmöglichkeiten, nicht die Annahme, dass sämtliche Standards bereits produktiv unterstützt werden müssen.
6. Identität, Delegation und Governance: Wenn Software im Auftrag des Kunden handelt
Der Unterschied zwischen Zugang und Handlungsvollmacht
Die zentrale Herausforderung agentischer Commerce-Prozesse liegt nicht allein in der technischen Erreichbarkeit einer Commerce API.
Ein AI-Agent kann möglicherweise einen Warenkorb verändern oder eine Bestellung auslösen. Daraus folgt noch nicht, dass er berechtigt ist, diese Handlung im Namen eines bestimmten Kunden vorzunehmen.
Technische Authentifizierung beantwortet zunächst die Frage, welches System oder welcher Benutzer auf eine Schnittstelle zugreifen darf.
Eine Handlungsvollmacht muss zusätzlich definieren, welche wirtschaftlich oder rechtlich relevanten Entscheidungen der Agent im konkreten Auftrag treffen darf.
Diese Unterscheidung ist insbesondere bei wiederkehrenden Einkäufen, Ersatzartikeln, Preisgrenzen und automatisierten Bestellungen entscheidend.
Ein einfaches Beispiel mit komplexen Folgen
Ein Geschäftskunde könnte einem AI-Agenten den Auftrag erteilen, regelmäßig Verbrauchsmaterial nachzubestellen, solange die monatlichen Gesamtkosten einen bestimmten Betrag nicht überschreiten.
Die Produktsuche wäre technisch vergleichsweise einfach. Schwieriger wird die Frage, wie aus dieser Anweisung eine überprüfbare Berechtigung entsteht.
Darf der Agent andere Marken auswählen? Sind Lieferkosten im Budget enthalten? Was geschieht, wenn sich ein Preis verändert? Darf er ein Abonnement abschließen oder lediglich Einzelbestellungen ausführen? Wie lange gilt die Berechtigung? Und was passiert, wenn der Kunde den Auftrag widerruft, während ein Kauf bereits vorbereitet wird?
Eine natürlichsprachliche Anweisung allein bildet noch keine verlässlich durchsetzbare Kontrollregel.
Ein belastbares System muss die relevanten Grenzen in strukturierte Bedingungen übertragen und vor der Ausführung prüfen können.
Dazu gehören die Identität des Auftraggebers, der ausführende Agent, die zulässigen Aktionen, wirtschaftliche Grenzen und die Gültigkeit der erteilten Berechtigung.
Ebenso wichtig ist die nachvollziehbare Dokumentation, welche Entscheidung auf welcher Grundlage getroffen wurde.
Mehrere Beteiligte, unterschiedliche Verantwortung
Bei agentischen Käufen treten zusätzliche Akteure in den Handelsprozess ein.
Der Kunde formuliert seine Absicht. Der AI-Agent interpretiert diese Absicht und wählt mögliche Aktionen. Der Agentenanbieter betreibt einen Teil der technischen Infrastruktur.
Der Händler muss sicherstellen, dass angebotene Produkte, Preise und Geschäftsregeln korrekt angewendet werden. Die Commerce-Plattform stellt dafür Funktionen bereit.
Eine Integrations- oder Orchestrierungsschicht kann zusätzliche Regeln durchsetzen. Der Zahlungsdienstleister verantwortet seine jeweiligen Zahlungs- und Autorisierungsprozesse. Nachgelagerte Systeme bearbeiten Lieferung, Änderung und Retoure.
Commerce MCP erlaubt die kontrollierte Bereitstellung ausgewählter Werkzeuge. AI Hub unterstützt bestimmte agentische Prozesse und Zahlungsintegrationen.
Diese Fähigkeiten ersetzen jedoch nicht automatisch ein vollständiges System zur Verwaltung delegierter Kaufmandate.
Auch die Verwendung sicherer Zahlungstoken löst nicht sämtliche Fragen der wirtschaftlichen Berechtigung. Ein Zahlungsvorgang kann technisch korrekt autorisiert sein, obwohl die Auswahlentscheidung eines Agenten außerhalb des ursprünglich beabsichtigten Kundenauftrags liegt.
Für Unternehmen entsteht damit eine Governance-Aufgabe, die über klassische API-Berechtigungen hinausgeht. Sie betrifft die Reichweite automatisierter Entscheidungen, die Durchsetzung von Mandatsgrenzen, deren Widerrufbarkeit und die Nachvollziehbarkeit von Transaktionen.
Warum bestehende Commerce-Investitionen relevant bleiben
Die Entwicklung agentischer Vertriebskanäle verändert nicht sämtliche Handelsfunktionen.
Ein Agent benötigt weiterhin verlässliche Produktinformationen, Preisregeln, Bestände, Warenkörbe, Bestellungen und Zahlungsprozesse.
Diese Funktionen bestehen bereits in etablierten Commerce-Landschaften.
Die technische Aufgabe liegt deshalb häufig darin, vorhandene Systeme kontrolliert für zusätzliche Interaktions- und Transaktionskanäle zugänglich zu machen.
Ein fehlender Protokollanschluss ist zunächst eine Integrationsanforderung. Erst wenn eine konkrete geschäftliche Anforderung durch nachgewiesene strukturelle Grenzen verhindert wird, stellt sich die Frage nach einer anderen Plattform.
7. Implementierung und Wirtschaftlichkeit: Der tatsächliche Preis der Gestaltungsfreiheit
Lizenzkosten beschreiben nur einen Teil der Investition
Die Wirtschaftlichkeit von commercetools lässt sich nicht allein aus dem Preis des Commerce-Kerns ableiten.
Das öffentlich beschriebene kommerzielle Modell ist order-based. commercetools grenzt diesen Ansatz ausdrücklich von GMV-basierten Preismodellen ab. [11]
Die individuellen Vertragsbedingungen, Nutzungskontingente und ergänzenden Produktkosten hängen jedoch vom gewählten Leistungsumfang ab.
Mehrere Funktionen stehen als zusätzliche Produkte oder Services zur Verfügung. Dazu zählen unter anderem Advanced B2B APIs sowie, abhängig von der jeweiligen Vertragskonfiguration, weitere Produkte für Frontend, Filialbetrieb, Integrationen und agentische Handelskanäle. [2][11]
Ohne ein konkretes Angebot lässt sich daraus kein belastbarer allgemeiner Lizenzbetrag berechnen.
Ebenso wenig sind pauschale Aussagen über typische Implementierungsbudgets oder feste Projektlaufzeiten seriös, wenn die zugrunde liegenden Geschäftsprozesse und die bestehende Systemlandschaft unbekannt sind.
Für eine wirtschaftliche Entscheidung müssen die tatsächlichen Kostentreiber untersucht werden.
Implementierungskosten entstehen an den Systemgrenzen
Ein wichtiger Teil des Aufwands liegt in der fachlichen Integration.
Produkte und Varianten müssen gegebenenfalls aus dem PIM übernommen werden. Preise können aus mehreren Quellen stammen. Bestände müssen mit ERP, Lagerverwaltung oder Filialen abgestimmt werden.
Dazu kommen der Aufbau oder die Anpassung von Frontends, der Checkout, die Anbindung von Zahlungsdienstleistern sowie die Verarbeitung von Bestellungen und Retouren.
Ein Unternehmen, das bereits über eine belastbare Integrationsarchitektur und klare Datenverantwortung verfügt, kann Teile dieser Aufgaben effizienter lösen als eine Organisation, die ihre Systemlandschaft zunächst grundlegend ordnen muss.
Neue Angebote wie die Commerce Integration Layer können bestimmte technische Infrastrukturaufgaben reduzieren. Dem stehen die Produktkosten, die Einsatzbedingungen und gegebenenfalls zusätzliche Herstellerabhängigkeiten gegenüber.
Die Auswahl geeigneter Komponenten und die dauerhafte Steuerung ihrer Zusammenarbeit bleiben wirtschaftlich relevante Aufgaben.
Total Cost of Ownership und Total Cost of Change
Bei Composable Commerce ist es sinnvoll, nicht nur die Gesamtkosten des Betriebs zu betrachten.
Ebenso relevant ist, wie viel zukünftige Änderungen kosten.
Ein Unternehmen kann beispielsweise mehrere Marken auf einer gemeinsamen Commerce-Grundlage betreiben und dennoch unterschiedliche Frontends einsetzen.
Wenn sich diese Frontends verändern lassen, ohne Kernprozesse und andere Marken erheblich zu beeinträchtigen, kann das langfristig einen Vorteil schaffen.
Andererseits kann jede zusätzliche Integration eigenen Wartungsbedarf, unterschiedliche Release-Zyklen und Abstimmungsaufwand zwischen Anbietern verursachen.
Eine vermeintlich besonders flexible Architektur wird wirtschaftlich fragwürdig, wenn selbst einfache Änderungen umfangreiche Koordination auslösen.
Der Total Cost of Ownership umfasst deshalb Lizenzen, Implementierung, Hosting ergänzender Komponenten, Personal, Support und Betrieb.
Der Total Cost of Change betrachtet darüber hinaus, wie aufwendig zukünftige Anpassungen an Sortimente, Märkte, Prozesse und Vertriebskanäle werden.
Gerade dieser zweite Aspekt kann für international tätige oder organisatorisch komplexe Handelsunternehmen entscheidend sein.
Architekturkompetenz ist keine optionale Nebensache
Eine Composable-Commerce-Landschaft benötigt nicht zwingend ein großes internes Entwicklerteam.
Sie benötigt aber eine Organisation, die Architekturentscheidungen treffen, Anforderungen priorisieren und externe Dienstleister wirksam steuern kann.
Dazu gehört ein Verständnis der führenden Systeme, der kritischen Geschäftsprozesse, der Integrationsabhängigkeiten und der langfristigen Betriebskosten.
Fehlt diese Verantwortung, entsteht schnell eine Landschaft, in der einzelne Komponenten technisch funktionieren, das Zusammenspiel jedoch von wenigen Dienstleistern oder Spezialisten abhängt.
Die Abhängigkeit von einem einzelnen Softwarehersteller kann dann durch eine schwerer zu steuernde Abhängigkeit von mehreren Anbietern ersetzt werden.
Für Unternehmen ist deshalb nicht nur die technische Leistungsfähigkeit der Plattform zu prüfen. Ebenso wichtig ist die eigene Fähigkeit, die entstehende Architektur langfristig verantwortlich zu führen.
8. Strukturelle Grenzen und die Frage eines Plattformwechsels
Nicht jedes Problem ist eine Plattformgrenze
Wenn ein Handelsunternehmen an funktionale oder wirtschaftliche Grenzen stößt, liegt die Ursache nicht zwangsläufig in der gewählten Commerce-Plattform.
Eine fehlende native Funktion kann möglicherweise über eine vorhandene Erweiterung abgedeckt werden. Ein ineffizienter Geschäftsprozess kann aus einer unklaren Datenverantwortung entstehen. Hohe Betriebskosten können die Folge einer historisch gewachsenen Integrationsarchitektur sein.
Auch organisatorische Defizite können technische Probleme verursachen.
Deshalb sollten Plattformgrenzen, Integrationsmängel, unvollständige Architekturen und organisatorische Ursachen ausdrücklich unterschieden werden.
Bei commercetools ist diese Differenzierung besonders wichtig, weil die Plattform viele Möglichkeiten für individuelle Architekturentscheidungen eröffnet.
Nicht jede aufwendige Implementierung ist durch die Plattform vorgegeben. Manche Komplexität entsteht aus fachlichen Anforderungen, andere aus technischen Entscheidungen und wieder andere aus vermeidbaren organisatorischen Strukturen.
Wann Weiterentwicklung die bessere Option sein kann
Bestehende commercetools-Kunden sollten bei neuen Anforderungen zunächst prüfen, ob die vorhandene Architektur gezielt erweitert werden kann.
Das gilt beispielsweise für zusätzliche B2B-Prozesse, neue Vertriebskanäle, Filialintegration oder agentische Produktzugänge.
Die jüngsten Produktentwicklungen verändern dabei den verfügbaren Lösungsraum.
Aufgaben, für die zuvor eigene Anwendungen erforderlich waren, können heute möglicherweise durch zusätzliche commercetools-Produkte oder verwaltete Integrationsdienste abgedeckt werden.
Auch neue Agentic-Commerce-Protokolle begründen für sich genommen keinen Plattformwechsel.
Die Integration eines neuen Kanals ist zunächst eine technische und wirtschaftliche Prüfaufgabe.
Wann eine strukturelle Neubewertung gerechtfertigt ist
Ein Plattformwechsel kann sinnvoll zu prüfen sein, wenn konkrete geschäftliche Anforderungen durch nachweisbare Grenzen erheblich behindert werden.
Dazu gehört beispielsweise eine Situation, in der notwendige Funktionen dauerhaft nur durch unverhältnismäßig aufwendige Sonderentwicklungen realisierbar sind.
Ebenso kann eine Architektur wirtschaftlich ungeeignet sein, wenn ihre laufenden Betriebs- und Änderungskosten in keinem angemessenen Verhältnis zum geschäftlichen Nutzen stehen.
Dabei müssen jedoch auch die Kosten eines Wechsels berücksichtigt werden.
Migration, Datenübernahme, Prozessanpassung, Integration, Tests, Betriebsrisiken und organisatorische Umstellung können erhebliche Investitionen erfordern. Bereits geschaffene Lösungen und vorhandene Kompetenzen besitzen ebenfalls wirtschaftlichen Wert.
Ein Plattformwechsel ist deshalb keine automatische Antwort auf technische Unzufriedenheit oder neue Marktstandards.
Er ist eine Investitionsentscheidung, die anhand realer Anforderungen, belastbarer Alternativen und der vollständigen wirtschaftlichen Konsequenzen getroffen werden muss.
9. Management-Fazit: Für welche Handelsorganisationen ist commercetools sinnvoll?
Hohe Individualität kann architektonische Freiheit rechtfertigen
commercetools ist besonders dort prüfenswert, wo Geschäftsmodelle über mehrere Marken, Märkte oder Vertriebskanäle hinweg unterschiedliche Anforderungen erzeugen.
Ein internationaler Händler kann verschiedene Kundenerlebnisse betreiben und zugleich gemeinsame Commerce-Funktionen verwenden.
Ein Hersteller mit komplexen B2B-Beziehungen kann Organisationsstrukturen und Einkaufsprozesse modellieren, ohne sämtliche Interaktionen an ein einziges standardisiertes Frontend binden zu müssen.
Ein Unternehmen mit bestehender technischer Integrationslandschaft kann Commerce-Funktionen gezielt in vorhandene Systeme einfügen.
In solchen Konstellationen kann die Architektur einen realen wirtschaftlichen Vorteil schaffen, sofern die notwendigen Fähigkeiten, Produkte und Integrationen tatsächlich verfügbar sind.
Die Unternehmensgröße allein ist dafür kein ausreichendes Kriterium.
Auch ein mittelständisches Unternehmen kann komplexe Prozesse besitzen, die eine flexible Architektur sinnvoll machen. Umgekehrt benötigt nicht jedes große Handelsunternehmen ein umfangreiches Composable-Modell.
Standardisierte Anforderungen brauchen nicht automatisch maximale Freiheit
Anders kann die Bewertung ausfallen, wenn ein Handelsunternehmen überwiegend standardisierte Prozesse betreibt und nur begrenzte technische Ressourcen zur Verfügung hat.
Hier muss besonders sorgfältig geprüft werden, welchen Nutzen zusätzliche Freiheitsgrade tatsächlich schaffen.
Eine Architektur, die laufend individuelle Entscheidungen über Frontend, Integrationen, Datenmodelle und Betrieb verlangt, kann mehr organisatorische Verantwortung erzeugen, als das Geschäftsmodell rechtfertigt.
Das erweiterte Produktportfolio von commercetools kann den notwendigen Eigenbau reduzieren. Trotzdem müssen Unternehmen den gewählten Leistungsumfang, die entstehenden Abhängigkeiten und ihre Gesamtverantwortung realistisch bewerten.
Die Entscheidung sollte daher nicht von einer allgemeinen Präferenz für integrierte oder modulare Plattformen abhängen.
Sie sollte aus den tatsächlichen Geschäftsprozessen, den vorhandenen Kompetenzen und der langfristigen Wirtschaftlichkeit abgeleitet werden.
Die entscheidende Frage ist nicht die maximale Freiheit
commercetools verfügt über einen umfangreichen Commerce-Kern und inzwischen über zusätzliche Produkte für Frontend, Checkout, Integrationen, Filialprozesse und agentische Handelskanäle.
Die frühere Beschreibung als reine API-Plattform, um die sämtliche weiteren Komponenten eigenständig aufgebaut werden müssen, wird dem heutigen Angebot nicht mehr gerecht.
Gleichzeitig bleibt die zentrale Besonderheit erhalten.
commercetools ermöglicht Unternehmen, ihre Handelsarchitektur entlang individueller Anforderungen zu gestalten. Diese Freiheit kann wirtschaftlich wertvoll sein, wenn Geschäftsmodell und Organisation sie tatsächlich benötigen.
Sie kann jedoch auch zusätzliche Verantwortung erzeugen, insbesondere wenn zahlreiche Anbieter, Integrationen und kundenspezifische Prozesse dauerhaft koordiniert werden müssen.
Unified Commerce zeigt, dass native Funktionen und Integrationsfähigkeit noch keine vollständige Ende-zu-Ende-Prozesssteuerung garantieren.
Agentic Commerce erweitert diese Herausforderung um neue Fragen der Identität, Autorisierung und kontrollierten Ausführung wirtschaftlich relevanter Handlungen.
Die neuen technischen Möglichkeiten sind deshalb weder ein allgemeiner Beleg für die Überlegenheit von commercetools noch ein Grund, bestehende Plattformen vorschnell infrage zu stellen.
Für eine verantwortbare Entscheidung müssen Unternehmen verstehen, welche Funktionen sie tatsächlich erwerben, welche Komponenten zusätzlich benötigt werden und welche Verantwortung dauerhaft bei ihnen selbst verbleibt.
Die entscheidende Frage ist am Ende nicht, wie viel architektonische Freiheit eine Plattform bietet.
Entscheidend ist, wie viel davon die eigene Handelsorganisation benötigt, beherrscht und wirtschaftlich sinnvoll nutzen kann.
Quellen und Recherchemethodik
Recherchestichtag: 27. Oktober 2026
Die Analyse beruht auf der offiziellen technischen Dokumentation von commercetools, Release Notes und öffentlich zugänglichen technischen Spezifikationen.
Die Quellen belegen dokumentierte Funktionen, Produktverfügbarkeit und technische Einschränkungen. Sie sind nicht automatisch unabhängige Nachweise für Wirtschaftlichkeit, Performance oder erfolgreiche produktive Implementierungen.
Die Aussagen zu organisatorischer Verantwortung, Architekturentscheidungen und wirtschaftlicher Eignung sind unabhängige analytische Einordnungen. Pauschale Implementierungsbudgets, numerische Plattformbewertungen und unbelegte Performanceversprechen werden bewusst vermieden.
Architektur und Produktportfolio
[1] commercetools API – General Concepts
[2] Add-on Products and Services
[3] Commerce Integration Layer – Overview
[4] Commerce Integration Layer – General Availability, 14. Oktober 2026
Commerce-Kern und B2B
[7] Modular Catalog General Availability und Product Search Public Beta, 29. September 2026
[10] Approval Rules API
[11] commercetools – Pricing and Plans einschließlich Advanced B2B APIs
Unified Commerce
[12] InStore General Availability, 13. Januar 2025
[13] Inventory Overview
[14] Inventory Reservations General Availability, 4. Juni 2026
Agentic Commerce und Governance
[16] Managed MCP Servers General Availability, 16. Juli 2026
[17] AI Hub – Overview
[18] AI Hub – Agentic Channels
[19] Universal Commerce Protocol
[20] Agent Payments Protocol – Specification
[21] WebMCP – Community Group Draft
Die Bewertung berücksichtigt den dokumentierten Stand zum Recherchestichtag. Funktionen in Beta, produktspezifische Zusatzleistungen und nicht nachgewiesene Implementierungen werden ausdrücklich von allgemein verfügbaren Plattformfähigkeiten unterschieden.