BigCommerce Deep Dive 2026: Open SaaS, B2B und die Verantwortung für verteilte Commerce-Prozesse

1. Executive Snapshot

BigCommerce verbindet einen standardisiert betriebenen SaaS-Commerce-Kern mit umfangreichen Möglichkeiten zur Integration und individuellen Gestaltung. Dieser Open-SaaS-Ansatz erlaubt es Handelsunternehmen, zentrale Funktionen des digitalen Verkaufs von einem Plattformanbieter betreiben zu lassen und gleichzeitig bestehende Unternehmenssysteme anzubinden.

Damit entsteht ein anderes Verantwortungsmodell als bei einer vollständig selbst betriebenen Commerce-Anwendung. Der Händler muss weder die gesamte technische Plattforminfrastruktur noch sämtliche Standardfunktionen selbst entwickeln. Er bleibt jedoch für die fachliche Abstimmung der Systeme verantwortlich, aus denen seine Handelsorganisation besteht.

Das wird besonders deutlich, wenn Produktdaten aus einem PIM stammen, Preise und Kundenkonditionen im ERP gepflegt werden, ein OMS die Auftragsabwicklung steuert und mehrere Storefronts unterschiedliche Märkte bedienen. BigCommerce kann in dieser Architektur wesentliche Commerce-Aufgaben übernehmen. Die übergreifende Steuerung entsteht dadurch aber nicht automatisch.

Seit Juli 2025 werden BigCommerce, Feedonomics und Makeswift unter dem Dach des börsennotierten Unternehmens Commerce.com geführt. BigCommerce bildet den transaktionalen Commerce-Kern. Feedonomics unterstützt die Aufbereitung und Verteilung von Produktinformationen. Makeswift ergänzt die Möglichkeiten zur Gestaltung digitaler Einkaufserlebnisse.

Im Herbst 2026 hat BigCommerce außerdem seine technischen Möglichkeiten für agentische Anwendungen deutlich erweitert. Die B2C- und B2B-Storefront-MCP-Werkzeuge sind allgemein verfügbar. WebMCP ermöglicht auf unterstützten Storefronts browserbasierten Agenten den Zugriff auf strukturierte Funktionen. Catalyst stellt darüber hinaus dokumentierte Endpunkte für das Universal Commerce Protocol bereit.

Diese Entwicklungen betreffen unterschiedliche Ebenen des Einkaufsprozesses. Produktdatenzugriff, Warenkorboperationen, Checkout-Protokolle, Zahlungsautorisierung und nachgelagerte Geschäftsprozesse dürfen nicht miteinander gleichgesetzt werden.

Die allgemeine Verfügbarkeit einer Schnittstelle beweist noch nicht, dass ein externer Agent einen vollständigen Kauf rechtlich wirksam und ohne weitere technische Voraussetzungen abwickeln kann.

Einordnung für die Plattformentscheidung

BigCommerce ist insbesondere dort zu prüfen, wo eine Organisation ihre zentralen Commerce-Funktionen nicht vollständig selbst betreiben möchte, aber individuelle Anforderungen an Storefronts, B2B-Prozesse oder Systemintegrationen besitzt.

Anspruchsvoller wird die Architektur, wenn wesentliche Geschäftsregeln nicht mit dem Standardmodell vereinbar sind oder die Integration zahlreicher Anwendungen eine eigene komplexe Betriebslandschaft erzeugt.

Die eigentliche BigCommerce-Entscheidung lautet deshalb nicht, wie offen die Plattform ist. Sie lautet, welche Verantwortung BigCommerce übernimmt und welche Verantwortung dauerhaft beim Händler bleibt.

2. Commerce.com und die Stellung von BigCommerce

Vom Plattformanbieter zum Commerce-Ökosystem

Am 31. Juli 2025 stellte BigCommerce seine neue Unternehmenspositionierung vor. BigCommerce Holdings, Inc. wurde in Commerce.com, Inc. umbenannt. Im August 2025 wechselte das Nasdaq-Kürzel von BIGC zu CMRC.

Unter dem gemeinsamen Unternehmensdach werden BigCommerce, Feedonomics und Makeswift geführt.

Diese Entwicklung erweitert die strategische Positionierung über die traditionelle Commerce-Plattform hinaus. Sie verändert jedoch nicht die grundlegende Unterscheidung zwischen den einzelnen Produkten.

BigCommerce stellt zentrale Handelsfunktionen wie Katalog, Warenkorb, Checkout, Bestellungen und kundenbezogene Commerce-Prozesse bereit.

Feedonomics adressiert die Aggregation, Aufbereitung, Optimierung und Verteilung von Produktinformationen über unterschiedliche Kanäle hinweg.

Makeswift unterstützt die visuelle Erstellung und Pflege digitaler Storefront-Erlebnisse.

Die Zugehörigkeit zu derselben Unternehmensgruppe schafft Möglichkeiten einer engeren Zusammenarbeit. Sie bedeutet jedoch nicht, dass sämtliche Produkte automatisch Bestandteil einer einzigen Lizenz sind oder dieselben Datenmodelle, Berechtigungen und technischen Dienste verwenden.

Für Händler ist daher zu unterscheiden, ob eine Funktion direkt in BigCommerce enthalten ist, über eine zusätzliche Commerce.com-Komponente bereitgestellt wird oder eine weitere Integration erfordert.

Das gilt besonders für Produktdatenanreicherung, kanalübergreifende Distribution und die Gestaltung individueller Storefronts.

Ein breites Produktportfolio kann die Architektur eines Händlers vereinfachen. Es kann aber auch zusätzliche Lizenz-, Integrations- und Betriebsentscheidungen schaffen.

Unternehmensentwicklung und Anbieterrisiko

Commerce.com ist weiterhin ein börsennotiertes Unternehmen. Die gelegentlich verbreitete Darstellung, BigCommerce sei 2024 von Bain Capital übernommen und privatisiert worden, trifft nicht zu.

Damals wurde über mögliche Übernahmegespräche berichtet. Eine abgeschlossene Bain-Transaktion ist daraus nicht entstanden.

Im September 2026 stellte Commerce.com einen Restrukturierungsplan vor. Nach Unternehmensangaben sollen jährliche Einsparungen von etwa 60 bis 80 Millionen US-Dollar erreicht werden. Zugleich formulierte das Unternehmen für 2027 das Ziel einer Non-GAAP-operativen Marge von mindestens 20 Prozent.

Solche Entwicklungen gehören zur wirtschaftlichen Beurteilung eines strategischen Softwareanbieters.

Sie rechtfertigen allerdings weder die Behauptung einer unmittelbar gefährdeten Plattformkontinuität noch Prognosen über konkrete Produktkürzungen, solange entsprechende Nachweise fehlen.

Für Handelsunternehmen ist vielmehr relevant, wie sich Produktinvestitionen, technische Roadmaps, Support und die langfristige Pflege bestehender Funktionen entwickeln.

Diese Fragen sollten Bestandteil der regelmäßigen Anbieterbewertung sein, unabhängig davon, ob ein Unternehmen wirtschaftlich wächst oder Restrukturierungsmaßnahmen durchführt.

Marktposition und geeignete Organisationen

BigCommerce adressiert B2C- und D2C-Händler ebenso wie B2B-Organisationen, Großhändler und international tätige Unternehmen.

Die Plattform kann besonders dort sinnvoll sein, wo zentrale Commerce-Prozesse weitgehend standardisierbar sind und individuelle Anforderungen durch konfigurierte Funktionen, APIs oder zusätzliche Fachsysteme erfüllt werden können.

Für mittelständische Handelsunternehmen ist die Einbindung bestehender Systeme oft entscheidender als die Zahl der verfügbaren Shopfunktionen.

Ein Händler, dessen ERP die kaufmännische Verantwortung trägt und dessen PIM Produktinformationen zentral verwaltet, benötigt nicht zwangsläufig ein Commerce-System, das sämtliche Aufgaben erneut übernimmt.

Er benötigt eine klare Aufgabenteilung.

Ob BigCommerce dafür geeignet ist, hängt vom Geschäftsmodell, der bestehenden Architektur und den organisatorischen Fähigkeiten ab.

3. Open SaaS: Was die Plattform übernimmt

Standardisierter Betrieb und seine Grenzen

Open SaaS ist ein zentraler Bestandteil der technischen Positionierung von BigCommerce.

Die Plattform stellt wesentliche Commerce-Dienste in einer vom Anbieter betriebenen Umgebung bereit. Händler müssen daher zentrale Teile der zugrunde liegenden Infrastruktur nicht selbst verwalten.

Plattformupdates, wesentliche Betriebsfunktionen und standardisierte Commerce-Dienste gehören zum Leistungsmodell des Anbieters.

Gleichzeitig bleibt der Commerce-Kern eine kontrollierte SaaS-Umgebung. Händler können dokumentierte Funktionen konfigurieren und über Schnittstellen ergänzen, erhalten aber keinen uneingeschränkten Zugriff auf sämtliche internen Abläufe.

Die Offenheit liegt insbesondere in APIs, Webhooks, Erweiterungsmöglichkeiten und verschiedenen Storefront-Architekturen.

Diese Flexibilität ist relevant, darf aber nicht mit vollständiger Kontrolle über die Commerce-Engine verwechselt werden.

Für eine Architekturentscheidung muss daher geprüft werden, welche Anforderungen im Standard erfüllt werden können, welche Ergänzungen benötigen und welche tatsächlich durch strukturelle Plattformgrenzen beeinträchtigt werden.

APIs und Integrationsverantwortung

BigCommerce stellt REST APIs, eine GraphQL Storefront API und Webhooks bereit.

Damit können externe Anwendungen unter anderem Produktinformationen, Preise, Kundenkontexte und Bestellungen in geeigneten Integrationsszenarien verarbeiten.

Die technische Verfügbarkeit einer Schnittstelle bedeutet jedoch nicht, dass die fachliche Verantwortung bereits geklärt ist.

Wenn ein ERP führend für Bestände ist, muss festgelegt werden, wann Änderungen an BigCommerce übertragen werden, wie Reservierungen berücksichtigt werden und welches System bei Abweichungen entscheidet.

Bei Preisen und Kundendaten entstehen vergleichbare Fragen.

Auch die API-Kapazitäten sind zu berücksichtigen. Die Entwicklerdokumentation nennt für Core und Growth beispielsweise 150 REST-API-Requests pro 30 Sekunden, für Scale 450. Für Performance gelten abhängig von Vertrag, API und Ressource andere Regelungen.

Mehrere Anwendungen können dieselbe verfügbare Store-Quota beanspruchen.

Diese Grenzen sind kein pauschaler Beleg für mangelnde Skalierbarkeit. Sie beeinflussen jedoch das Design von Integrationen mit großen Datenmengen, hoher Aktualisierungsfrequenz oder vielen angeschlossenen Systemen.

Warteschlangen, Wiederholungsmechanismen, Monitoring und nachvollziehbare Fehlerbehandlung gehören deshalb zu einer belastbaren Integrationsarchitektur.

Stencil als standardisierte Storefront

Stencil ist die Theme-basierte Storefront-Architektur von BigCommerce.

Sie bietet ein stärker standardisiertes Frontend-Modell innerhalb der vorgesehenen Plattformumgebung.

Themes können gestaltet, angepasst und erweitert werden. Der Händler bewegt sich dabei innerhalb der dokumentierten Architektur und ihrer Möglichkeiten.

Für Unternehmen mit weitgehend standardisierten Anforderungen kann dies ein wirtschaftlich sinnvoller Ansatz sein.

Nicht jedes Commerce-Projekt profitiert davon, zusätzliche Frontend-Infrastruktur, Deployment-Prozesse und eigene Framework-Verantwortung aufzubauen.

Stencil sollte deshalb nicht allein deshalb als ungeeignet gelten, weil alternative Headless-Architekturen verfügbar sind.

Catalyst und individuelle Headless-Architekturen

Catalyst ist BigCommerce' auf Next.js basierende Headless-Storefront-Architektur.

Sie erlaubt umfangreichere individuelle Gestaltung und Entwicklung im Frontend. Unternehmen können eigene Komponenten, Integrationen und Benutzeroberflächen schaffen.

Die zusätzliche Freiheit verändert allerdings die Betriebsverantwortung.

Je nach Umsetzung müssen Händler oder Implementierungspartner Hosting, Deployment, Framework-Updates, Frontend-Sicherheit, Monitoring und die Pflege individueller Komponenten selbst sicherstellen.

Auch Marketplace-Apps, die ursprünglich für Stencil entwickelt wurden, sind nicht zwangsläufig ohne Anpassungen mit einer Headless-Storefront kompatibel.

Die Verfügbarkeitsstände einzelner Werkzeuge sind zudem zu unterscheiden. Die Catalyst CLI ist allgemein verfügbar. BigCommerce Storefront Hosting wurde zum Recherchestichtag weiterhin als Closed Beta dokumentiert.

Individuelle Headless-Architekturen können die technische Freiheit noch erweitern. Gleichzeitig wächst die Verantwortung für Integration und langfristige Wartung.

Ein Headless-Frontend macht den Commerce-Kern jedoch nicht automatisch vollständig austauschbar oder individuell veränderbar.

Die Storefront-Entscheidung sollte sich deshalb daran orientieren, welche zusätzliche Gestaltungsfreiheit das Unternehmen tatsächlich benötigt und welche Verantwortung es dafür dauerhaft übernehmen kann.

Checkout-Architektur und Erweiterungsgrenzen

Beim Checkout wird die Unterscheidung zwischen einem anpassbaren Frontend und dem vom Anbieter betriebenen Commerce-Kern besonders deutlich.

BigCommerce stellt unterschiedliche Möglichkeiten bereit, darunter Open Checkout, Checkout SDK und Checkout APIs.

Open Checkout und Checkout SDK ermöglichen Anpassungen an der Checkout-Oberfläche und die Einbindung dokumentierter Funktionen.

Sie erlauben jedoch nicht, sämtliche internen Zahlungs-, Versand- oder Bestellregeln der SaaS-Plattform beliebig zu verändern.

Die GraphQL Storefront API unterstützt ihrerseits Checkout-Prozesse, einschließlich der Verarbeitung von Checkout-Daten und der Überführung eines geeigneten Checkouts in eine Bestellung. Ihr genauer Funktionsumfang ist von den jeweiligen API-Voraussetzungen und Einschränkungen abhängig.

Dies ist für die spätere Agentic-Commerce-Bewertung wichtig.

Die allgemeine BigCommerce-Checkout-Architektur besitzt andere Fähigkeiten als die konkreten Werkzeuge des Storefront MCP.

Wenn ein MCP-Agent einen Checkout-Link erzeugt, beschreibt dies zunächst die Grenze dieses Werkzeugsets. Es ist keine Aussage darüber, dass die gesamte BigCommerce-Plattform technisch keine weitergehende Checkout-Verarbeitung unterstützt.

Die praktische Umsetzbarkeit individueller Checkout-Prozesse muss deshalb immer auf der Ebene der tatsächlich verwendeten API und Architektur geprüft werden.

4. Commerce-Funktionen und B2B-Prozesse

Der Commerce-Kern für B2C und D2C

BigCommerce stellt zentrale Funktionen für den digitalen Handel bereit.

Dazu gehören Produktkataloge, Varianten, Optionen, Kundengruppen, Preislisten, Promotions, Warenkörbe, Checkout, Zahlungsintegration und Bestellverwaltung.

Für zahlreiche B2C- und D2C-Geschäftsmodelle bilden diese Funktionen eine geeignete technische Grundlage.

Die tatsächliche Eignung hängt jedoch davon ab, wie komplex Produkte, Preise, Kundenbeziehungen und operative Prozesse sind.

Ein Händler mit standardisierten Sortimenten und Lieferprozessen stellt andere Anforderungen als ein Unternehmen mit individuell konfigurierbaren Produkten, regional unterschiedlichen Konditionen oder kundenspezifischen Vertragsregeln.

Auch internationale Storefronts müssen hinsichtlich Währungen, Steuern, Zahlungsarten, Sprachen und rechtlicher Anforderungen einzeln geprüft werden.

Eine technisch mögliche Mehrmarktarchitektur ersetzt nicht die fachliche Lokalisierung der einzelnen Märkte.

Gleiches gilt für Abonnements, spezielle Produktkonfigurationen und individuelle Fulfilment-Szenarien.

Soweit zusätzliche Apps oder individuelle Integrationen erforderlich sind, gehören diese zur Bewertung der Zielarchitektur und nicht zum ungeprüften Standardumfang der Plattform.

B2B Edition als ergänzende Produktebene

Mit B2B Edition bietet BigCommerce ein eigenständiges Angebot für organisationsbezogene Geschäftskundenprozesse.

Die Unterscheidung zum Commerce-Kern ist wesentlich.

Kundengruppen und Preislisten können eine Grundlage für B2B-Geschäftsmodelle schaffen. Sie ersetzen jedoch nicht automatisch Company Accounts, organisationsbezogene Rollen, Einkaufslisten, Angebotsprozesse und zusätzliche Beschaffungsfunktionen.

B2B Edition ergänzt BigCommerce um ein Buyer Portal sowie Funktionen für Company Accounts, Buyer Roles, Quotes, Shopping Lists und Rechnungen.

Dabei lassen sich unterschiedliche Berechtigungen innerhalb einer Einkaufsorganisation abbilden.

Ein Junior Buyer kann beispielsweise Einkaufslisten vorbereiten, ohne selbst dieselben Bestellrechte wie ein Senior Buyer zu besitzen.

Für viele B2B-Organisationen ist diese Unterscheidung grundlegender Bestandteil des tatsächlichen Beschaffungsprozesses.

Organisationshierarchien und mehrere Storefronts

Die Existenz von Company Accounts bedeutet nicht, dass jede internationale Unternehmensstruktur vollständig im Standardsystem abgebildet werden kann.

Größere Einkaufsorganisationen können aus mehreren rechtlichen Gesellschaften, zentralen Beschaffungseinheiten, lokalen Niederlassungen und unterschiedlichen Kostenstellen bestehen.

B2B Edition unterstützt entsprechende Organisationsmodelle innerhalb ihrer dokumentierten Möglichkeiten. Bestimmte Hierarchiefunktionen können allerdings von der jeweiligen B2B-Konfiguration abhängen.

Bei Multi-Storefront entsteht eine zusätzliche fachliche Grenze.

Ein Unternehmen kann über eine gemeinsame Einkaufsorganisation verfügen, während Angebote, Rechnungen, Einkaufslisten und Bestellungen weiterhin bestimmten Storefronts zugeordnet sind.

Auch Käuferberechtigungen können von der jeweiligen Storefront-Zuordnung abhängen.

Für einen international tätigen Großhändler mit zentralen Verträgen und mehreren regionalen Vertriebsgesellschaften ist dies eine entscheidende Frage.

Es reicht nicht aus, dass alle beteiligten Nutzer derselben Company zugeordnet werden können.

Es muss geprüft werden, ob die gewünschte Transparenz, Freigabelogik und kaufmännische Verarbeitung über die jeweiligen Storefront-Grenzen hinweg gewährleistet ist.

Angebote, Einkaufslisten und Beschaffung

B2B Edition stellt dokumentierte Funktionen für Angebote, Einkaufslisten und weitere Buyer-Portal-Prozesse bereit.

Diese können die Zusammenarbeit zwischen Händler und Geschäftskunde verbessern.

Die vollständige Beschaffung reicht jedoch häufig über das Buyer Portal hinaus.

Vertragskonditionen, Budgets, Genehmigungen, Wareneingang, Rechnungsabgleich und Zahlungsfreigabe können im ERP, in Procurement-Systemen oder in anderen Unternehmensanwendungen liegen.

Ein digitaler Angebotsprozess ist deshalb nicht automatisch ein vollständig integrierter Beschaffungsprozess.

Für die Architekturentscheidung muss festgelegt werden, welche Aufgaben im Commerce-System stattfinden und welche weiterhin von anderen Systemen verantwortet werden.

B2B und Headless

B2B Edition unterstützt unterschiedliche Storefront-Architekturen, darunter Stencil, Catalyst und individuelle Headless-Implementierungen.

Die B2B-Funktionen besitzen allerdings zusätzliche technische Schnittstellen und eigene Berechtigungsmodelle.

Die B2B GraphQL API ist nicht mit sämtlichen Funktionen der allgemeinen GraphQL Storefront API gleichzusetzen.

In Headless-Projekten muss daher geprüft werden, welche Buyer-Portal-Funktionen übernommen werden können und welche zusätzliche Entwicklung erfordern.

Die Existenz einer Schnittstelle ist kein Beleg dafür, dass ein vollständiger B2B-Geschäftsprozess bereits ohne weitere Implementierung verfügbar ist.

Die Eignung von B2B Edition entscheidet sich an der tatsächlichen Einkaufsorganisation, ihren Berechtigungen und ihrer Integration in die kaufmännischen Prozesse.

5. Vom Onlineshop zur verteilten Handelsarchitektur

Multi-Storefront ist nicht Unified Commerce

BigCommerce unterstützt unterschiedliche Storefronts und Verkaufskanäle.

Für Unternehmen mit mehreren Marken, Ländern oder Kundengruppen können diese Möglichkeiten relevant sein.

Ein zusätzlicher Verkaufskanal schafft zunächst einen weiteren Zugang zum Geschäft.

Er garantiert nicht, dass Bestände, Kundeninformationen, Bestellungen, Zahlungsprozesse und Retouren über sämtliche Kanäle hinweg einheitlich verarbeitet werden.

Diese Unterscheidung wird bei Click & Collect, Ship-from-Store und kanalübergreifenden Retouren besonders deutlich.

Ein Händler muss bestimmen können, welcher Bestand verfügbar ist, welche Menge reserviert wurde, wo ein Auftrag erfüllt werden soll und welches System für Änderungen verantwortlich ist.

BigCommerce kann Teil einer solchen Architektur sein.

Ob die erforderlichen Prozesse bereits durch dokumentierte Funktionen unterstützt werden oder zusätzliche Systeme benötigen, muss anhand des konkreten Szenarios geprüft werden.

Bestände, Aufträge und Systemverantwortung

In komplexeren Handelsorganisationen ist die im Shop angezeigte Verfügbarkeit nur ein Ausschnitt des tatsächlichen Bestandsmodells.

Physische Lagerbestände, Filialbestände, Reservierungen, Umlagerungen und bereits zugesagte Lieferungen müssen miteinander abgestimmt werden.

Ein OMS kann die übergreifende Verantwortung übernehmen. In anderen Unternehmen verbleiben wesentliche Aufgaben im ERP.

BigCommerce muss deshalb nicht in jedem Fall das führende System für Bestands- und Auftragssteuerung sein.

Wichtiger ist, dass Verantwortlichkeiten eindeutig festgelegt werden.

Die GraphQL Storefront API unterstützt zahlreiche Warenkorb- und Checkout-Funktionen, weist jedoch Einschränkungen für einzelne Szenarien auf, darunter bestimmte Buy-Online-Pick-Up-in-Store-Abläufe.

Das ist kein Nachweis, dass Click & Collect mit BigCommerce grundsätzlich unmöglich wäre.

Es zeigt, dass die Unterstützung konkreter Omnichannel-Prozesse auf der Ebene der tatsächlich verwendeten APIs und Integrationen geprüft werden muss.

Feedonomics und die Produktdatenebene

Feedonomics gehört innerhalb der Commerce.com-Gruppe zur Produktdaten- und Syndication-Ebene.

Das Produkt unterstützt die Aggregation, Aufbereitung, Optimierung und Verteilung von Produktinformationen für unterschiedliche Vertriebs- und Marketingkanäle.

Gerade bei großen Sortimenten unterscheiden sich die Anforderungen an Produktattribute, Taxonomien, Kategorien und Datenformate zwischen einzelnen Kanälen erheblich.

Feedonomics kann helfen, diese Informationen konsistent aufzubereiten und in geeigneter Form bereitzustellen.

Damit wird allerdings zunächst die Qualität der Datenverteilung verbessert.

Ein korrekt übermittelter Produktfeed bedeutet nicht, dass die Bestellung aus dem jeweiligen Absatzkanal vollständig in ERP, OMS und Kundenservice integriert ist.

Product Syndication und Unified Commerce lösen unterschiedliche Aufgaben.

Produktdatenanreicherung und AI-basierte Entdeckung

Am 29. September 2026 stellte Commerce.com Feedonomics Enrichment und BigCommerce Catalog Enrichment vor.

Die Angebote erweitern die Möglichkeiten, Produktinformationen aufzubereiten und für unterschiedliche digitale Entdeckungssituationen nutzbar zu machen.

Dazu gehören die Verbesserung von Attributen, Beschreibungen und Datenkonsistenz sowie die Unterstützung AI-gestützter Produktentdeckung.

Feedonomics Enrichment wird als eigenständiges Angebot positioniert. BigCommerce Catalog Enrichment führt entsprechende Fähigkeiten enger an die BigCommerce-Katalogumgebung heran.

Die ursprüngliche Produktankündigung beschränkte die Generierung von Produktinhalten auf Englisch. Weitere Sprachen wurden angekündigt.

Für Händler mit deutschen oder mehrsprachigen Produktkatalogen ist diese Einschränkung relevant.

Zudem bleibt die fachliche Verantwortung für die Korrektheit der Produktinformationen bestehen.

Automatisch erzeugte Eigenschaften und Beschreibungen müssen mit den tatsächlichen Produkteigenschaften, Markenrichtlinien und gegebenenfalls regulatorischen Vorgaben übereinstimmen.

Feedonomics unabhängig vom Commerce-Kern

Für bestehende Handelslandschaften ist außerdem wichtig, dass Produktdatenoptimierung nicht zwangsläufig mit einer Migration der transaktionalen Plattform verbunden sein muss.

Feedonomics kann auch als eigenständige Produktdaten- und Syndication-Lösung betrachtet werden.

Ein Unternehmen, das seine Produktinformationen für Marktplätze, Werbeplattformen oder AI-basierte Produktsuche verbessern möchte, muss deshalb nicht allein aus diesem Grund seinen Commerce-Kern austauschen.

Eine solche Trennung kann bestehende Investitionen schützen und Veränderungen auf die tatsächlich betroffenen Prozesse begrenzen.

Makeswift als Experience-Schicht

Makeswift unterstützt die visuelle Gestaltung digitaler Seiten und Einkaufserlebnisse.

Im Catalyst-Umfeld kann Makeswift mit individuell entwickelten React-Komponenten zusammenarbeiten.

Entwickler stellen damit technische Komponenten bereit, die von Content- und Commerce-Teams innerhalb definierter Grenzen redaktionell verwendet werden können.

Dies kann die Zusammenarbeit zwischen Entwicklung und Fachabteilungen verbessern.

Die Integration in Stencil war am Recherchestichtag noch als Beta dokumentiert und besitzt nicht denselben Funktionsumfang wie die Catalyst-Variante.

Auch hier ist deshalb zwischen gemeinsamer Produktpositionierung und tatsächlich unterstützter Architektur zu unterscheiden.

Unified Commerce als organisatorische Aufgabe

BigCommerce, Feedonomics und Makeswift können unterschiedliche Aufgaben innerhalb einer modernen Handelsarchitektur übernehmen.

Sie ersetzen jedoch nicht automatisch ERP, OMS, CRM, Filialsysteme oder Zahlungsdienstleister.

Die entscheidende Frage lautet, welches System für welchen Geschäftsprozess fachlich führend ist.

Erst wenn diese Verantwortung geklärt ist, können technische Schnittstellen eine zuverlässige kanalübergreifende Prozesssteuerung unterstützen.

Dies ist zugleich die Grundlage für agentische Anwendungen, die künftig nicht nur Produktinformationen abrufen, sondern konkrete Handelsaktionen ausführen sollen.

6. Agentic Commerce: Zugriff ist nicht Autonomie

Unterschiedliche Ebenen agentischer Handelsprozesse

Agentic Commerce bezeichnet keine einzelne technische Funktion.

Die Möglichkeiten reichen von der Bereitstellung strukturierter Produktdaten über Produktsuche und Warenkorbverwaltung bis zu Checkout-Protokollen und potenziell delegierten Transaktionen.

Diese Ebenen müssen getrennt betrachtet werden.

Ein Agent, der Produktmerkmale auswertet, erfüllt eine andere Aufgabe als eine Anwendung, die einen Warenkorb verändert.

Ein standardisiertes Checkout-Protokoll erweitert wiederum die technischen Möglichkeiten, ohne automatisch alle Fragen der Identität, Zahlung und rechtlichen Autorisierung zu lösen.

BigCommerce hat 2026 für mehrere dieser Ebenen konkrete technische Erweiterungen dokumentiert.

Produktdaten und agentische Auffindbarkeit

Agentische Einkaufsvorgänge benötigen verlässliche Informationen über Produkte, Varianten, Preise und Verfügbarkeit.

Feedonomics und die neuen Anreicherungsangebote können zur Verbesserung dieser Daten beitragen.

Auch Agentic Catalog Exports gehören in diese Ebene.

Damit können Produktinformationen für geeignete externe Systeme strukturiert bereitgestellt werden.

Die erfolgreiche Datenbereitstellung ist jedoch noch kein Nachweis, dass ein externer Agent eine Bestellung auslösen, eine Zahlung autorisieren oder spätere Änderungen bearbeiten kann.

Dafür werden weitere Commerce- und Autorisierungsfunktionen benötigt.

Storefront MCP

Am 8. Oktober 2026 erreichten die B2C- und B2B-Storefront-MCP-Werkzeuge von BigCommerce nach offizieller Dokumentation die allgemeine Verfügbarkeit.

Das Model Context Protocol ermöglicht Agentenanwendungen den strukturierten Zugriff auf dokumentierte Werkzeuge.

Der B2C Storefront MCP unterstützt unter anderem Produktrecherche, das Abrufen von Produktdetails, Warenkorboperationen und die Erzeugung von Checkout-Links.

Damit können Agenten mit tatsächlichen Commerce-Funktionen arbeiten, statt ausschließlich die sichtbare Benutzeroberfläche einer Website auszuwerten.

Die Werkzeuge können für Gäste und in geeigneten Konfigurationen für authentifizierte Käufer verwendet werden.

Ihre Nutzung setzt allerdings eine aktivierte Verbindung und einen unterstützten Client voraus.

Die allgemeine Verfügbarkeit des Servers ist nicht mit der Unterstützung jedes denkbaren Agentenclients oder jeder Storefront-Konfiguration gleichzusetzen.

Storefront Session Sync

Storefront Session Sync verbindet eine MCP-Sitzung mit dem bestehenden Browserkontext eines angemeldeten Kunden.

Die dokumentierte Implementierung betrifft Stencil.

Unter den entsprechenden Voraussetzungen können Login-Status, Warenkorb und kundenspezifische Informationen übernommen werden.

Dazu verwendet BigCommerce kurzlebige Synchronisierungstokens. Der Agent erhält nicht unmittelbar die Browser-Cookies des Kunden.

Für B2B-Anwendungen kann zusätzlich der bestehende Unternehmens- und Berechtigungskontext relevant sein.

Die Funktion ist technisch bedeutsam, weil agentische Aktionen nicht mehr ausschließlich auf anonymen Produktinformationen beruhen müssen.

Gleichzeitig müssen Änderungen zwischen Agentensitzung und Browserzustand konsistent gehalten werden.

Eine authentifizierte Sitzung erlaubt zudem nur diejenigen Handlungen, für die der zugrunde liegende Käufer tatsächlich berechtigt ist.

B2B Storefront MCP

Das B2B-Werkzeugset ergänzt die allgemeinen Storefront-Funktionen um ausgewählte Buyer-Portal-Aktionen.

Die Dokumentation nennt unter anderem Werkzeuge für Einkaufslisten und Angebote.

Diese werden abhängig von B2B Edition, authentifizierter Käuferidentität und den jeweiligen Berechtigungen bereitgestellt.

Ein Agent kann dadurch bestimmte Beschaffungsvorgänge vorbereiten oder bearbeiten.

Er kann beispielsweise eine Einkaufsliste verändern oder Informationen zu einem Angebot abrufen, sofern der Käufer die entsprechenden Rechte besitzt.

Auch die Erzeugung eines Checkout-Links aus einem geeigneten Angebotskontext ist dokumentiert.

Damit wird die vorhandene Rollenlogik in Teile der agentischen Interaktion übernommen.

Das ersetzt jedoch nicht die Prüfung, wer eine Bestellung freigeben oder eine Zahlung autorisieren darf.

WebMCP und Cloudflare

Am 21. Oktober 2026 stellte BigCommerce WebMCP für unterstützte Storefronts bereit.

WebMCP ermöglicht browserbasierten Agenten den Zugriff auf strukturierte Werkzeuge, die eine Website in der Browserumgebung anbietet.

Die Entwicklerdokumentation beschreibt eine standardmäßige Aktivierung für Stencil und für Catalyst-Storefronts, die auf Cloudflare betrieben werden. Individuelle Headless-Storefronts auf Cloudflare können unter zusätzlichen Voraussetzungen eingebunden werden.

Wenn die serverseitigen Storefront-MCP-Werkzeuge aktiviert sind, können sie automatisch für WebMCP verfügbar gemacht werden.

Die Einstellungen lassen sich im BigCommerce Control Panel kontrollieren. Händler können WebMCP deaktivieren.

Die tatsächlich nutzbaren Funktionen hängen jedoch weiterhin von der jeweiligen Browserunterstützung, der Storefront-Architektur und den verfügbaren Werkzeugen ab.

WebMCP schafft damit einen zusätzlichen Zugangsweg zu bestehenden Commerce-Funktionen.

Es ist keine pauschale Zusicherung, dass jeder browserbasierte Agent sämtliche Verkaufsprozesse vollständig ausführen kann.

UCP: Eine weitere technische Ebene

Neben MCP und WebMCP dokumentiert BigCommerce eine konkrete Unterstützung des Universal Commerce Protocol.

Mit Catalyst 1.12.0 vom 16. September 2026 werden UCP-Endpunkte auf der öffentlichen Storefront-Domain bereitgestellt.

Dazu gehören /.well-known/ucp für die Protokollentdeckung und /api/ucp/* für entsprechende Protokollanfragen.

Catalyst leitet diese Anfragen an BigCommerce weiter. Die eigentliche Protokollverarbeitung erfolgt auf der BigCommerce-Plattform und nicht innerhalb der Catalyst-Anwendung.

Die Implementierung ist deshalb mehr als eine strategische Ankündigung. Sie belegt eine konkrete technische Anbindung.

Aus diesen Endpunkten allein lässt sich allerdings nicht ableiten, welche transaktionalen Fähigkeiten für jeden Händler, jede Region und jeden externen Agenten produktiv nutzbar sind.

Insbesondere müssen die tatsächlich unterstützten UCP-Funktionen, Zahlungsintegrationen, Autorisierungsmodelle und weiteren Voraussetzungen einzeln überprüft werden.

Die technische Bereitstellung einer UCP-Schnittstelle ist deshalb weder mit einem bloßen Produktfeed noch mit einem uneingeschränkt autonomen Kaufprozess gleichzusetzen.

Checkout und Transaktionsgrenzen

Die Unterscheidung zwischen den agentischen Schnittstellen und der allgemeinen Checkout-Architektur ist zentral.

Der dokumentierte Storefront-MCP-Prozess erlaubt einem Agenten, Produkte zu finden, Warenkörbe zu bearbeiten und einen Checkout-Link zu erzeugen.

Der anschließende Kaufabschluss erfolgt im regulären Checkout durch den Käufer.

BigCommerce besitzt jedoch unabhängig von diesem MCP-Werkzeugset weitere Checkout APIs und dokumentierte UCP-Endpunkte.

Die Begrenzung des Storefront MCP darf daher nicht als allgemeine Aussage über sämtliche technisch möglichen Checkout-Abläufe der Plattform verstanden werden.

Für die Bewertung agentischer Transaktionen müssen mehrere Fragen beantwortet werden.

Welche Aktionen kann der Agent tatsächlich ausführen? Welche Voraussetzungen muss der Händler erfüllen? Wer bestätigt den verbindlichen Kauf? Welche technische und rechtliche Autorisierung liegt vor? Wie wird die Zahlung abgewickelt? Und welche Systeme übernehmen nachgelagerte Änderungen, Retouren und Kundenservice?

Die dokumentierten Produktfähigkeiten liefern auf diese Fragen noch keine einheitliche, für sämtliche Händler gültige Antwort.

Store Management MCP

Neben den kundenorientierten Schnittstellen entwickelt BigCommerce den Store Management MCP für administrative Aufgaben.

Zum Recherchestichtag befand sich dieser in einer nur auf Einladung zugänglichen Closed Beta.

Die dokumentierten Funktionen umfassen unter anderem Produktkatalog, Preise, Bestände, Promotions sowie ausgewählte Auftrags- und Erstattungsprozesse.

Der Zugriff erfolgt über OAuth 2.1 mit PKCE und nutzerbezogene Berechtigungen.

Dabei sind unterschiedliche Sicherheitsmechanismen vorgesehen.

Neu angelegte Produkte bleiben zunächst verborgen. Neu erstellte Promotions werden deaktiviert angelegt und müssen vor ihrer Verwendung gesondert aktiviert werden.

Andere Werkzeuge können unmittelbar wirksame Änderungen ausführen. Dazu gehören Preis- oder Bestandsänderungen sowie die Möglichkeit, tatsächliche Rückerstattungen auszulösen.

Die Sicherheitswirkung hängt deshalb nicht allein davon ab, ob ein Agent technisch authentifiziert ist, sondern ebenso davon, welche Aktion er ausführen darf und welche Kontrollen vor ihrer Wirksamkeit vorgesehen sind.

Die Closed Beta sollte nicht mit der allgemeinen Verfügbarkeit des Storefront MCP verwechselt werden.

Offene Protokolle und ihre unterschiedlichen Aufgaben

MCP, WebMCP und UCP adressieren unterschiedliche Ebenen agentischer Commerce-Architekturen.

MCP stellt strukturierte Werkzeuge bereit. WebMCP macht geeignete Funktionen im Browserkontext zugänglich. UCP beschäftigt sich mit standardisierten Commerce-Abläufen und ihrer technischen Interaktion.

Weitere Protokolle verfolgen ergänzende Ziele.

ACP beschreibt Commerce-Interaktionen zwischen AI-Anwendungen und Händlern. AP2 adressiert Autorisierungs- und Zahlungsnachweise. A2A betrifft die Kommunikation zwischen Agenten.

Die Existenz dieser Standards ist kein Beleg für ihre vollständige Integration in BigCommerce.

Die dokumentierte UCP-Anbindung ist konkret zu berücksichtigen. Für weitere Protokolle oder einzelne Transaktionsschritte ist die jeweilige Implementierung gesondert nachzuweisen.

Die entscheidende Frage lautet nicht, wie viele Protokolle ein Anbieter erwähnt, sondern welche Geschäftsprozesse über sie tatsächlich unterstützt werden.

Agentic Commerce als Ende-zu-Ende-Prozess

Die neuen Schnittstellen machen wesentliche Teile des digitalen Einkaufs für Agenten zugänglich.

Dazu gehören Produktentdeckung, ausgewählte Warenkorboperationen und bestimmte Checkout-Interaktionen.

Für vollständig delegierte Einkäufe sind darüber hinaus eindeutige Mandate, Berechtigungen, Preis- und Budgetgrenzen, Zahlungsautorisierung und nachvollziehbare Nachkaufprozesse erforderlich.

Eine vollständige Produktivunterstützung dieser gesamten Kette ist nicht allein durch die dokumentierten MCP-, WebMCP- und UCP-Endpunkte nachgewiesen.

Das bedeutet nicht, dass weitergehende Lösungen grundsätzlich unmöglich sind.

Es bedeutet, dass ihre tatsächliche Realisierung im jeweiligen Architektur- und Vertragskontext geprüft werden muss.

BigCommerce hat den technischen Zugang zu realen Commerce-Funktionen deutlich erweitert. Ob daraus ein durchgängig delegierter Kaufprozess entsteht, entscheidet sich an den zusätzlichen Transaktions-, Autorisierungs- und Integrationsbedingungen.

7. Identität, Berechtigungen und Governance

Technischer Zugriff und geschäftliche Handlungsvollmacht

Agentische Commerce-Prozesse verändern nicht die grundlegende Verantwortung für Handelsentscheidungen.

Sie verändern jedoch die Art, wie diese Entscheidungen technisch vorbereitet und ausgeführt werden können.

Wenn ein Agent im Auftrag eines Käufers handelt, muss zwischen technischer Authentifizierung, fachlicher Berechtigung und rechtlicher Handlungsvollmacht unterschieden werden.

Ein erfolgreicher Login belegt zunächst eine Identität.

Er beweist nicht, dass jede durch den Agenten ausgelöste Aktion vom Käufer autorisiert ist.

Bei B2B-Organisationen kommen Unternehmenszugehörigkeit, Käuferrollen, Budgetgrenzen und gegebenenfalls mehrstufige Genehmigungsprozesse hinzu.

Diese Anforderungen müssen auch dann eingehalten werden, wenn eine Anwendung den Kaufprozess über MCP oder andere Protokolle begleitet.

Käufer, Unternehmen und Agent

Ein belastbares Governance-Modell unterscheidet den menschlichen Käufer, die Einkaufsorganisation, den verwendeten Agenten, dessen Anbieter und die beteiligten Commerce- und Zahlungsdienstleister.

Jeder Beteiligte übernimmt andere Aufgaben und verfügt über unterschiedliche Informationen.

Der Händler muss nachvollziehen können, welche Aktion mit welchem Recht ausgeführt wurde und welche wirtschaftlichen Folgen entstanden sind.

Besonders relevant sind Grenzen für Warenwerte, Lieferadressen, Ersatzartikel, wiederkehrende Verpflichtungen und den Widerruf von Berechtigungen.

Wo diese Regeln nicht durch Standardfunktionen abgebildet werden, sind zusätzliche Kontrollen notwendig.

Berechtigungen bei Store Management MCP

Der administrative MCP-Zugang zeigt die Unterschiede zwischen technischen und fachlichen Kontrollen besonders deutlich.

Die Closed Beta verwendet Berechtigungen für einzelne Funktionsbereiche, darunter Produkte, Bestände, Promotions und Orders.

Allerdings sind die Berechtigungen nicht vollständig feldgenau.

Ein Nutzer mit Änderungsrechten für Produkte kann beispielsweise nicht ohne Weiteres ausschließlich für Textänderungen berechtigt werden, während Preisänderungen technisch ausgeschlossen bleiben.

Zudem gelten Berechtigungen pro Nutzer und nicht getrennt für jeden verbundenen Agenten.

Mehrere Agenten, die unter derselben Nutzeridentität verbunden werden, können daher dieselben Zugriffsrechte erhalten.

Die Dokumentation weist außerdem darauf hin, dass Aktionen im Audit Trail dem autorisierenden Nutzer zugerechnet werden. Eine unabhängige Attribution zum jeweils ausführenden Agenten ist noch nicht vorgesehen.

Das begrenzt die Nachvollziehbarkeit, wenn mehrere Agenten unter demselben Nutzerkonto arbeiten.

Unterschiedliche Risiken administrativer Aktionen

Nicht jede Agentenaktion besitzt dieselbe wirtschaftliche Tragweite.

Die Erstellung eines zunächst verborgenen Produkts oder einer deaktivierten Promotion bietet eine zusätzliche Kontrollmöglichkeit, bevor die Änderung für Kunden wirksam wird.

Eine Preisänderung kann hingegen unmittelbar Auswirkungen auf veröffentlichte Konditionen haben.

Eine tatsächliche Rückerstattung führt zu einer finanziellen Bewegung und kann nicht über denselben Werkzeugaufruf rückgängig gemacht werden.

BigCommerce sieht beim Refund-Prozess technische Prüfungen vor, darunter die vorherige Berechnung eines Erstattungsangebots und die erneute Prüfung des Betrags vor der Ausführung.

Das ersetzt jedoch keine eigenständige fachliche Freigabe, wenn die Organisation eine solche verlangt.

Gerade bei finanziell wirksamen Aktionen müssen menschliche Bestätigung, Berechtigungsgrenzen und Protokollierung Teil der tatsächlichen Implementierung sein.

Hinzu kommt, dass Änderungen oder der Entzug von Berechtigungen innerhalb einer bestehenden Beta-Sitzung nicht unter allen Umständen sofort wirksam werden.

Für den produktiven Einsatz administrativer Agenten ist dies ein relevanter Betriebs- und Sicherheitsaspekt.

Governance über Systemgrenzen hinweg

Die Verantwortung endet nicht an der BigCommerce-Schnittstelle.

Wenn ein Agent Produktinformationen aus Feedonomics nutzt, kundenbezogene Konditionen über BigCommerce abruft und anschließend eine Zahlung über einen externen Dienst vorbereitet, entstehen mehrere technische und organisatorische Verantwortungsbereiche.

Preis, Verfügbarkeit, Kundenidentität, Handlungsberechtigung und Zahlungsstatus müssen dabei konsistent bleiben.

Auch Kundenservice und Reklamationsbearbeitung benötigen nachvollziehbare Informationen über agentische Aktionen und ausdrückliche Kundenentscheidungen.

Agentic-Commerce-Governance ist damit keine isolierte AI-Aufgabe. Sie erweitert die bestehende Commerce-Governance und macht unklare Berechtigungen oder Systemverantwortlichkeiten besonders sichtbar.

8. Implementierung, Betrieb und Wirtschaftlichkeit

Die Plattformlizenz ist nur ein Teil der Kosten

BigCommerce hat seine öffentliche Tarifstruktur im Juni 2026 auf Core, Growth, Scale und Performance umgestellt.

Die aktuellen öffentlichen US-Listenpreise beginnen bei jährlicher Zahlung mit 29 US-Dollar monatlich für Core, 79 US-Dollar für Growth und 299 US-Dollar für Scale. Performance wird individuell vertraglich angeboten und beginnt laut öffentlicher Preisübersicht bei 1.499 US-Dollar monatlich bei jährlicher Abrechnung.

Diese Preise sind keine belastbaren Projektkalkulationen für einen deutschen Händler.

Sie beschreiben zunächst die öffentliche Ausgangsbasis für die Plattformlizenz. Die tatsächlichen Kosten hängen von Tarif, Umsatzvolumen, Zahlungsabwicklung, zusätzlich benötigten Produkten und vertraglichen Vereinbarungen ab.

GMV-Schwellen und Zahlungsgebühren

Seit Juni 2026 verwendet BigCommerce für seine Self-Service-Tarife eine neue Gebühren- und Umsatzlogik.

Dabei müssen zwei Mechanismen unterschieden werden.

Die Tarifzuordnung orientiert sich am von BigCommerce definierten Gross Merchandise Value. Für die Berechnung des maßgeblichen Inclusive GMV wird nach der veröffentlichten Regelung der Bruttobestellwert um zehn Prozent reduziert.

Die öffentliche Tarifübersicht nennt für Core eine Grenze von 30.000 US-Dollar über zwölf Monate und für Growth 100.000 US-Dollar. Scale verwendet eine monatliche GMV-Schwelle von 33.333 US-Dollar mit einer zusätzlichen volumenabhängigen Regelung oberhalb dieser Grenze.

Daneben erhebt BigCommerce für bestimmte Tarife eine Open Payment Provider Fee.

Die Gebühr wird auf das maßgebliche Bestellvolumen angewendet, das tatsächlich einem Open Payment Provider zugeordnet ist.

Bestellungen, die über einen entsprechend anerkannten Embedded Payment Provider abgewickelt werden, unterliegen dieser zusätzlichen Gebühr nicht.

Wenn ein Händler verschiedene Zahlungsanbieter verwendet, können deshalb nur bestimmte Teile seines Bestellvolumens gebührenpflichtig sein.

Die bloße Anzeige eines Embedded Payment Providers im Checkout reicht nicht aus. Entscheidend ist, welcher Anbieter die jeweilige Transaktion tatsächlich verarbeitet.

Auch Bestellungen aus anderen Vertriebskanälen oder über individuelle Integrationen können unter die Gebührenregelung fallen, abhängig von ihrer tatsächlichen Zahlungsabwicklung und den veröffentlichten Vertragsbedingungen.

Die normalen Gebühren des Zahlungsdienstleisters sind davon unabhängig.

Für eine wirtschaftliche Bewertung müssen deshalb mindestens Plattformtarif, maßgebliches GMV, Zahlungsanbietermix und individuelle Vertragsbedingungen betrachtet werden.

Eine allgemeine Aussage, BigCommerce erhebe keine zusätzlichen transaktionsbezogenen Gebühren, ist seit dieser Änderung nicht mehr zutreffend.

Zusatzprodukte und Vertragsgrenzen

B2B Edition, Feedonomics, Makeswift und weitere ergänzende Produkte müssen jeweils hinsichtlich Lizenzierung und Leistungsumfang betrachtet werden.

Ihre Zugehörigkeit zur Commerce.com-Gruppe bedeutet nicht, dass sie automatisch mit einer BigCommerce-Lizenz erworben werden.

Auch Multi-Storefront-Konfigurationen, zusätzliche Apps und spezielle Integrationen können laufende Kosten verursachen.

Die wirtschaftliche Bewertung muss sich deshalb auf die tatsächlich benötigte Zielarchitektur beziehen.

Eine Gegenüberstellung öffentlicher Einstiegspreise würde dem nicht gerecht.

Entwicklung und langfristiger Betrieb

Die Storefront-Architektur beeinflusst die Kosten ebenso wie die Plattformlizenz.

Eine stärker standardisierte Stencil-Implementierung kann bestimmte Aufgaben der Frontend-Entwicklung und des Betriebs begrenzen.

Catalyst und individuelle Headless-Architekturen eröffnen mehr Gestaltungsfreiheit, verlangen aber zusätzliche technische Fähigkeiten.

Dazu gehören je nach Implementierung Hosting, Deployment, Framework-Updates, Monitoring, Sicherheit und die Pflege individueller Komponenten.

Auch die Kompatibilität vorhandener Apps und die Integration ergänzender Anwendungen sind zu berücksichtigen.

Eine Headless-Storefront ist deshalb nicht ausschließlich ein einmaliges Entwicklungsprojekt. Sie wird Teil einer langfristig zu betreibenden Systemlandschaft.

Integrationen und Datenqualität

ERP-, PIM-, OMS- und CRM-Integrationen können einen erheblichen Anteil des Gesamtaufwands verursachen.

Ihr Umfang hängt weniger von der bloßen Existenz technischer Schnittstellen ab als von Datenqualität, Prozesslogik und der Verteilung fachlicher Verantwortung.

Ein Händler mit eindeutig definierten Datenverantwortlichkeiten und stabilen Schnittstellen besitzt andere Voraussetzungen als eine Organisation mit zahlreichen individuellen Anwendungen, widersprüchlichen Stammdaten und unklaren Prozesszuständigkeiten.

Auch Monitoring, Fehlerbehandlung und Wiederherstellung nach fehlgeschlagenen Datentransfers sind laufende Betriebsaufgaben.

Ein Integrationsfehler kann falsche Preise, fehlerhafte Bestände oder verzögerte Bestellungen verursachen.

Diese Risiken müssen wirtschaftlich berücksichtigt werden.

Total Cost of Ownership und Total Cost of Change

Der Total Cost of Ownership umfasst die Kosten für Einführung, Lizenzen, Zahlungsabwicklung, Integrationen, Entwicklung und laufenden Betrieb über einen definierten Zeitraum.

Bei BigCommerce gehören dazu die Plattform selbst, ergänzende Produkte, Apps, Storefront-Betrieb und die Integration bestehender Unternehmenssysteme.

Daneben ist der Total Cost of Change relevant.

Er beschreibt die wirtschaftlichen Folgen zukünftiger Veränderungen.

Ein Unternehmen kann neue Länder erschließen, B2B-Beschaffungsprozesse verändern, weitere Marktplätze anbinden oder agentische Anwendungen in den Kaufprozess integrieren wollen.

Eine anfangs günstige Architektur kann teuer werden, wenn solche Veränderungen regelmäßig umfangreiche individuelle Anpassungen verlangen.

Umgekehrt kann eine anfänglich aufwendigere Integrationsarchitektur wirtschaftlich sinnvoll sein, wenn sie wiederkehrende Veränderungen erleichtert.

Daraus folgt kein allgemeiner Kostenvorteil oder Kostennachteil von BigCommerce.

Die Wirtschaftlichkeit entsteht aus der Übereinstimmung zwischen Plattformfähigkeiten, bestehender Systemlandschaft und organisatorischen Kompetenzen.

Wirtschaftlichkeit agentischer Funktionen

Die neuen MCP-, WebMCP- und UCP-Anbindungen eröffnen zusätzliche technische Möglichkeiten.

Ihr wirtschaftlicher Nutzen lässt sich allerdings nicht allein aus ihrer Verfügbarkeit ableiten.

Für Händler ist relevant, ob diese Funktionen tatsächlich genutzt werden, welche zusätzlichen Geschäftsvorgänge sie unterstützen und welcher Aufwand für Produktdatenqualität, Integration, Berechtigungen, Monitoring und Kundenservice entsteht.

Auch die Überwachung agentischer Aktionen und die Behandlung von Fehlentscheidungen können dauerhafte Kosten verursachen.

Ohne entsprechende Praxisergebnisse sind pauschale Aussagen über höhere Conversion Rates, geringere Servicekosten oder autonome Umsatzsteigerungen nicht belastbar.

9. Strukturelle Grenzen und Wechselkriterien

Fehlende Standardfunktionen sind nicht automatisch Plattformgrenzen

In bestehenden Commerce-Landschaften wird ein Plattformwechsel häufig diskutiert, wenn neue Anforderungen nur mit zusätzlichem Aufwand umgesetzt werden können.

Das allein rechtfertigt noch keine Migration.

Zunächst sollte geklärt werden, ob eine Anforderung tatsächlich außerhalb der technischen Möglichkeiten von BigCommerce liegt.

Möglicherweise ist eine Funktion in einer anderen Edition enthalten, über eine ergänzende Anwendung verfügbar oder durch eine überschaubare Integration realisierbar.

In anderen Fällen entstehen die Schwierigkeiten aus fehlender Datenqualität, unklaren Geschäftsprozessen oder organisatorischen Defiziten.

Ein Wechsel der Commerce-Plattform würde diese Probleme nicht automatisch lösen.

Wo strukturelle Grenzen entstehen können

Strukturelle Grenzen werden dort relevant, wo geschäftskritische Anforderungen Eingriffe in den Commerce-Kern verlangen, die das SaaS-Modell nicht vorsieht.

Auch umfangreiche individuelle Integrationen können zu einer Architektur führen, deren langfristiger Betrieb unverhältnismäßig aufwendig wird.

Dies kann bei komplexen B2B-Vertragsmodellen, ungewöhnlichen Preisbildungsmechanismen, stark individualisierten Checkout-Prozessen oder anspruchsvollen Omnichannel-Abläufen auftreten.

Entscheidend ist jedoch nicht allein, ob eine Anforderung technisch mit zusätzlichem Entwicklungsaufwand umgesetzt werden kann.

Die eigentliche Frage lautet, ob die resultierende Lösung stabil, wartbar und wirtschaftlich tragfähig bleibt.

Erweiterung vor Migration

Bevor ein Unternehmen eine Migration verfolgt, sollten die bestehenden Erweiterungsmöglichkeiten geprüft werden.

Dazu gehören BigCommerce-Funktionen, andere Lizenzmodelle, B2B Edition, spezialisierte Apps, ergänzende Commerce.com-Produkte und individuelle Integrationen.

Feedonomics ist ein gutes Beispiel dafür, dass die Verbesserung von Produktdatenprozessen nicht zwangsläufig den Austausch des Commerce-Kerns erfordert.

Ähnliches gilt für neue agentische Schnittstellen.

Die Unterstützung neuer Protokolle kann für die zukünftige Architektur wichtig sein. Die Einführung eines solchen Standards ist für sich genommen jedoch kein ausreichender Grund, eine bestehende Plattform zu ersetzen.

Wann eine Migration sachlich gerechtfertigt ist

Ein Plattformwechsel wird erst dann zu einer belastbaren Option, wenn wesentliche geschäftliche Anforderungen nachweislich nicht oder nur mit unverhältnismäßigem Aufwand erfüllt werden können.

Dafür müssen sowohl die strukturellen Grenzen der bestehenden Lösung als auch die wirtschaftlichen und organisatorischen Konsequenzen eines Wechsels untersucht werden.

Bestehende Integrationen, Datenmodelle, individuelle Funktionen und interne Kompetenzen besitzen einen Wert.

Eine Migration schafft neue technische Möglichkeiten, verändert aber auch Verantwortlichkeiten und erzeugt eigene Projektrisiken.

Gerade für mittelständische Handelsorganisationen kann die Fähigkeit, eine komplexe Veränderung organisatorisch zu bewältigen, ebenso entscheidend sein wie die technischen Eigenschaften einer alternativen Plattform.

Die Entscheidung sollte deshalb aus konkreten Geschäftsanforderungen hervorgehen, nicht aus neuen Produktankündigungen oder einer abstrakten Vorstellung moderner Architektur.

10. Management-Fazit

BigCommerce verbindet einen standardisierten SaaS-Commerce-Kern mit umfangreichen Schnittstellen und unterschiedlichen Storefront-Architekturen.

Für B2C-, D2C- und bestimmte B2B-Organisationen kann daraus eine tragfähige technische Grundlage entstehen.

Besonders relevant ist der Ansatz für Unternehmen, die zentrale Commerce-Funktionen nicht vollständig selbst entwickeln und betreiben möchten, gleichzeitig aber bestehende Unternehmenssysteme und individuelle Geschäftsanforderungen berücksichtigen müssen.

Mit B2B Edition erweitert BigCommerce den Commerce-Kern um organisationsbezogene Einkaufsfunktionen. Feedonomics unterstützt Produktdatenaufbereitung und Syndication. Makeswift ergänzt die Möglichkeiten zur Gestaltung digitaler Einkaufserlebnisse.

Die Entwicklungen im Agentic Commerce zeigen, dass BigCommerce zunehmend strukturierte Zugriffe auf konkrete Handelsfunktionen ermöglicht.

Storefront MCP unterstützt dokumentierte Einkaufsaktionen. WebMCP erweitert den Zugang für geeignete browserbasierte Agenten. Die UCP-Anbindung schafft eine weitere technische Grundlage für standardisierte Commerce-Interaktionen.

Diese Entwicklungen sind relevant, müssen aber nach ihrer tatsächlichen Funktion unterschieden werden.

Ein produktiver Werkzeugzugriff ist nicht automatisch eine rechtsverbindliche Transaktion. Eine authentifizierte Kundensitzung ist keine uneingeschränkte Handlungsvollmacht. Und eine dokumentierte Checkout-Schnittstelle beweist noch keine vollständig autonome Zahlungs- und Nachkaufabwicklung.

Die eigentliche Stärke des BigCommerce-Ansatzes liegt deshalb nicht in einer unbegrenzten technischen Offenheit.

Sie liegt in der Möglichkeit, standardisierte Commerce-Funktionen mit ergänzenden Systemen zu verbinden, ohne sämtliche Grundlagen des Shopbetriebs selbst verantworten zu müssen.

Ob daraus eine wirtschaftlich überzeugende Architektur entsteht, hängt von Geschäftsmodell, Integrationsbedarf, organisatorischen Fähigkeiten und den Anforderungen an durchgängige Prozesse ab.

Unternehmen mit klaren Datenverantwortlichkeiten, weitgehend standardisierbaren Kernprozessen und einer beherrschbaren Integrationslandschaft können von diesem Modell profitieren.

Organisationen mit außergewöhnlich komplexen Geschäftsregeln, tiefgreifenden Anforderungen an den Commerce-Kern oder unzureichend gesteuerten Systemlandschaften müssen genauer prüfen, welche zusätzliche Verantwortung entsteht und ob diese langfristig tragbar bleibt.

BigCommerce nimmt Händlern einen wesentlichen Teil des technischen Commerce-Betriebs ab. Die Verantwortung für das gesamte Handelsgeschäft jedoch nicht.

Daran sollte sich die Plattformentscheidung orientieren.

---

Quellen und Recherchestand

Die Analyse berücksichtigt öffentlich dokumentierte Informationen bis zum 28. Oktober 2026. Herstellerdokumentationen dienen als Nachweis für veröffentlichte Produktfunktionen und Verfügbarkeitsstände, nicht als unabhängiger Beleg für Wirtschaftlichkeit oder Implementierungserfolg.

Die Quellen wurden thematisch zugeordnet, damit zentrale Aussagen unmittelbar überprüft werden können.

Unternehmensstruktur und Produktstrategie

1. Commerce.com: Neue Unternehmensstruktur, 31. Juli 2025
2. SEC: Commerce.com, Inc., Unternehmens- und Kapitalmarktunterlagen
3. Commerce.com: Unternehmensmitteilungen und Restrukturierung 2026
4. Commerce.com: Data Enrichment, 29. September 2026

Plattformarchitektur, B2B und Wirtschaftlichkeit

5. BigCommerce: Aktuelle Tarife, GMV und Zahlungsgebühren
6. BigCommerce: Änderungen des Preismodells 2026
7. BigCommerce: REST API Rate Limits
8. BigCommerce: Custom Checkout und Checkout SDK
9. BigCommerce: GraphQL Storefront Cart und Checkout
10. BigCommerce: Makeswift
11. BigCommerce: B2B Storefront und Buyer-Portal-Werkzeuge

Agentic Commerce, MCP und UCP

12. BigCommerce: Catalyst 1.12.0, UCP und Storefront Session Sync
13. BigCommerce Developer Changelog, 8. Oktober 2026
14. BigCommerce: MCP Server Overview
15. BigCommerce: B2C Storefront MCP
16. BigCommerce: B2B Storefront MCP
17. BigCommerce: WebMCP, 21. Oktober 2026
18. BigCommerce: WebMCP-Dokumentation
19. BigCommerce: Store Management MCP, Closed Beta

Hinweis zur Aktualität: Insbesondere Agentic Commerce, MCP, WebMCP und UCP entwickeln sich schnell. Dokumentierte technische Endpunkte, Produktverfügbarkeit und die tatsächliche Unterstützung vollständiger Geschäftsprozesse müssen getrennt bewertet werden. Individuelle Lizenzbedingungen, regionale Einschränkungen und produktive Integrationsmöglichkeiten sind im konkreten Auswahlprojekt erneut zu überprüfen.