Ein Shopify-B2B-Portal auf Kundenkonten bauen: was vorher zu wissen ist

Ein Shopify-B2B-Käuferportal wird für die Käuferinnen, die eines haben, auf Shopifys Kundenkonten gebaut – und für die, die keines haben, auf einer eigenen Oberfläche. Das ist die ganze Entscheidung. Die Frage, die Agenturen noch stellen – neue Kundenkonten oder Legacy? –, hat am 26. Februar 2026 aufgehört, eine Frage zu sein, als Shopify die Legacy-Konten als veraltet erklärt hat; und eine B2B-Frage war sie nie, weil B2B auf ihnen nie lief. Zu entscheiden bleibt, welche der vier Oberflächen welchen Teil des Portals trägt, und die Antwort hängt an zwei Tatsachen über die Käuferin: ob sie ein Kundenkonto hat und ob dieses Konto einem Unternehmensstandort zugeordnet ist.

Diese Seite ist für die Agentur, die die Käuferseite eines B2B-Projekts scoped: was Kundenkonten heute sind und was eine angemeldete B2B-Käuferin ohne jede App schon bekommt; die vier Oberflächen, die ein Portal nutzen kann, und was jede davon trägt, mit den Plattformgrenzen, die das entscheiden; was eine Kundenkonto-Erweiterung kann und nicht kann; wo Gastkäuferinnen hingehören; was Headless ändert; ob eine Käuferin einen Bestellentwurf sehen kann; und die Fehlerfälle, die entstehen, wenn das Kontomodell falsch verstanden wird. Wo sie beschreibt, wie QuotWay Angebote ins Konto bringt, ist das eine Implementierung und als solche gekennzeichnet.

Alles über Shopify wurde am 22. September 2026 gegen Shopifys eigene Seiten in API-Version 2026-07 geprüft; die Quellen stehen am Ende.

Was Kundenkonten heute sind

Shopify hat ein Kundenkontosystem für neue Shops und ein veraltetes. Die aktuellen Konten melden eine Käuferin mit einer E-Mail-Adresse und einem einmaligen Code an, der dorthin geschickt wird – „ein Passwort ist nicht erforderlich“ –, und im B2B ist die E-Mail die eines Unternehmensstandorts, sodass die Anmeldung zugleich die Unternehmensprüfung ist. Eine Käuferin, die mehreren Standorten zugeordnet ist, wählt den Standort, für den sie kauft, bevor etwas in den Warenkorb geht. Das Konto kann auf einer Subdomain der eigenen Shop-Domain liegen, etwa account.ihrshop.de, und ein Shop kann seinen eigenen Identitätsanbieter über OAuth 2.0 oder OpenID Connect anbinden; die Spring-’26-Edition ergänzte Profil- und Tag-Synchronisation aus Auth0, Ping Identity und Azure ID sowie Sitzungen von bis zu 365 Tagen.

Legacy-Kundenkonten sind seit dem 26. Februar 2026 veraltet – für neue Shops nicht mehr verfügbar, keine weiteren Updates, ein Abschaltdatum „wird später 2026 bekannt gegeben“ –, und Shopifys B2B-Dokumentation ist eindeutig: „Legacy-Kundenkonten können nicht für B2B-Kunden und -Bestellungen verwendet werden.“ Jeder Bauplan, der noch einen Legacy-Zweig führt, plant für einen Shop, den es nicht geben kann.

Was eine angemeldete B2B-Käuferin ohne installierte App aus dem Konto bekommt, ist mehr, als ein Projekt manchmal annimmt:

Heute im Konto	Details
Bestellungen	Bestellhistorie über die Standorte der Käuferin, Sendungsverfolgung, Nachbestellung durch Duplizieren einer früheren Bestellung, Rücksendeanfragen
Zahlungsziele	Bei einer Bestellung mit Zahlungsziel ein „Jetzt bezahlen“-Button, das Fälligkeitsdatum und die Kennzeichnung „Überfällig“, sobald das Ziel verstrichen ist; die Käuferin kann jederzeit vor der Fälligkeit zahlen
Anzahlungen	Der Anzahlungsbetrag und das Fälligkeitsdatum des Restbetrags, angezeigt im Checkout, auf der Dankeseite und im Konto (Anzahlungen sind eine Plus-Fähigkeit)
Unternehmen	Unternehmens- und Standortinformationen, gespeicherte Zahlungsmethoden; Adressänderungen brauchen die Berechtigung Standort-Admin
Berechtigungen	„Nur Bestellen“ sieht die eigenen Bestellungen; „Standort-Admin“ sieht jede Bestellung des Standorts und bearbeitet Adressen

Was es nicht hat, ist irgendetwas zu einem Angebot: keine Anfrage, keinen Vorschlag, keine Versionen, kein Gegenangebot, keine Freigabe. Diese Lücke füllt ein Portal, und die vier Oberflächen unten sind die Orte, an denen es das tun kann.

Die vier Oberflächen

Die Matrix, jeweils mit der Grenze, die die Zeile entscheidet:

	Standard-Kundenkonto	Kundenkonto-UI-Erweiterung	Gehostetes Portal (App)	Headless-Storefront
Wer es nutzen kann	Angemeldete Kundinnen; B2B-Verhalten nur bei Zuordnung zu einem Unternehmensstandort	Dasselbe – Erweiterungen rendern im Konto	Jede mit dem Link: Gäste, Käuferinnen ohne Konto, Shops ohne aktuelle Konten	Käuferinnen, die der Storefront über die Customer Account API anmeldet
Anmeldung	E-Mail + Einmalcode; optional OIDC-Anbieter	Shopifys, bereits erledigt	Die der App: ein Magic Link, ein Code an dasselbe Postfach	Autorisierungsablauf der Customer Account API
Wo es lebt	Von Shopify gehostet oder account.ihrshop.de	Im Konto; eine Vollseite bekommt einen Menüeintrag und eine eigene Route	Domain der App	Ihre Domain
UI-Kontrolle	Keine über den Editor hinaus	Nur Shopifys Web-Komponenten; läuft in einem abgeschotteten Worker; 64 KB je Erweiterung, 128 KB für eine Vollseite	Voll	Voll
Branding	Konto-Theme des Shops	Konto-Theme des Shops; die Erweiterung erbt es	Das der App, mit Logo und Farben des Shops, wenn sie das unterstützt	Ihres
Daten, die eine App erreicht	–	Storefront-API-Lesezugriffe (Produkte, Kollektionen, Metaobjekte) mit api_access; das eigene Backend der App mit network_access + Session-Token; purchasingCompany am authentifizierten Konto	Was das Backend der App hält	Customer Account API + Storefront API mit Käuferkontext
Was die Käuferin nativ sieht	Bestellungen, Zahlungsziele, Anzahlungen, Nachbestellung, Retouren, Unternehmensdaten	All das plus das, was die Erweiterung ergänzt	Nur, was die App rendert	Nur, was Sie rendern
Bestellentwürfe / Rechnungen	Über den Rechnungslink; Bestellungen mit Zahlungsziel haben „Jetzt bezahlen“	Die Customer Account API stellt draftOrders mit invoiceUrl bereit, eine Seite kann sie also auflisten	Worauf die App verlinkt	Dieselbe API wie die Erweiterung
Angebote	Nein	Ja, aus dem Backend der App	Ja	Ja, wenn Sie es bauen
Fehlerfläche	Shopifys	Das Bundle-Limit, die Target-Regeln, CORS und Token-Prüfung	E-Mail-Zustellbarkeit, eine zweite Domain	Alles, einschließlich der Anmeldung

Lesen Sie die Spalten als Arbeitsteilung, nicht als Konkurrenz. Ein Projekt, das Unternehmenskäuferinnen bedient, legt die Angebotsseiten ins Konto, weil diese Käuferinnen dort bereits ihre Rechnungen bezahlen; dasselbe Projekt behält eine gehostete Oberfläche, weil ein Gast, eine Käuferin, deren Konto noch keinem Unternehmen zugeordnet ist, und ein Shop, der noch nicht auf aktuelle Konten umgestellt hat, außerhalb der Reichweite der Erweiterung liegen. Headless ersetzt die ersten beiden Spalten für Shops, die ihre Storefront selbst besitzen, und nichts an der dritten.

Was eine Kundenkonto-Erweiterung kann und nicht kann

Die Erweiterung ist die Oberfläche, die die meisten Projekte in beide Richtungen unterschätzen: Sie kann mehr als ein Link im Menü und weniger als eine Seite.

Wo sie rendern kann. Eine Vollseite (customer-account.page.render, „nicht an eine bestimmte Bestellung gebunden“), die Händler in die Kontonavigation aufnehmen; eine bestellungsgebundene Seite für Abläufe wie Retouren; Blöcke und Hinweise auf der Bestellübersicht und der Bestellstatusseite; eine Bestellaktion, die sich in einem Modal öffnet; Profilblöcke, darunter B2B-spezifische, die nach den Unternehmensdetails, den Standortadressen, den Zahlungsmethoden des Standorts und der Mitarbeiterliste des Standorts rendern; ein Footer-Slot. Shopifys eigene Regel: „Vollseiten-Targets können nicht mit anderen Erweiterungs-Targets in einer einzigen Erweiterung kombiniert werden.“ Eine Angebotsseite plus ein „Meine Angebote“-Link auf der Bestellseite sind deshalb zwei Erweiterungen, und wenn der Shop sie gemeinsam aus dem Editor hinzufügen soll, fasst eine Editor-Erweiterungssammlung – die mindestens zwei Erweiterungen braucht – sie zusammen.

Worin sie läuft. „In einer isolierten Sandbox, getrennt von der Kundenkontoseite und anderen UI-Erweiterungen“ – einem Web Worker –, und sie rendert Shopifys Web-Komponenten, „native UI-Elemente, die Shopifys Designsystem folgen“, kein eigenes HTML und CSS. Das kompilierte Bundle „darf 64 KB nicht überschreiten, beziehungsweise 128 KB für Vollseiten-Erweiterungen“. Die Erweiterung hat keinen Zugriff auf „sensible Zahlungsinformationen oder die Kundenkontoseite selbst“. Diese drei Grenzen zusammen bedeuten: Die Erweiterung ist ein dünner Client; Zustand, Regeln und Dokumente des Angebots leben im Backend, die Seite holt und rendert.

Was sie erreichen kann. Mit api_access die Storefront API für „unauthentifizierten Lesezugriff auf Produkte, Kollektionen, Produkt-Tags, Verkaufspläne und Metaobjekte“ – genug, um Produktdaten und jedes app-eigene Metaobjekt zu lesen, etwa Texte je Shop oder einen Routen-Slug. Mit network_access das eigene Backend der App, unter zwei Bedingungen, die Shopify klar benennt: Antworten müssen Access-Control-Allow-Origin: * tragen, und „Anfragen könnten von überall im Internet stammen“ – das Session-Token belegt die Identität der Kundin, nicht, dass der Aufruf von Shopify kam, also prüft das Backend das Token bei jeder Anfrage und behandelt den Ursprung als nicht vertrauenswürdig. Vom authentifizierten Konto bekommt die Erweiterung die Kundin und, bei einer Geschäftskäuferin, purchasingCompany; für alle anderen ist dieser Wert undefined, und genau das ist die Prüfung „ist das überhaupt eine Unternehmenskäuferin“.

Was sie nicht kann. Für einen Gast rendern. Sich außerhalb von Shopifys Tokens gestalten. Einen großen Client halten. Das DOM der Kontoseite lesen. Auf Legacy-Konten existieren. Jeder dieser Punkte ist ein Grund, warum die gehostete Spalte in der Matrix bleibt.

Gastangebote und Käuferinnen außerhalb des Unternehmens

Zwei Arten von Käuferinnen sind für die Erweiterung unsichtbar, und ein Portalplan muss sagen, wohin sie gehen.

Die erste ist der Gast: eine Käuferin, die von einer Produktseite aus ein Angebot anfragt, ohne sich anzumelden. Shopify hat kein Objekt für diese Anfrage und keine Kontoseite, auf der sie zu zeigen wäre. Der native Einstieg, um aus einer solchen Käuferin ein Unternehmen zu machen, ist die Unternehmenskonto-Anfrage: ein Shopify-Forms-Formular, inline oder als Popup, dessen Absenden „automatisch“ ein Unternehmen, einen Unternehmensstandort und eine Kundin im Admin anlegt, geparkt unter „Bestellen nicht freigegeben“, bis der Händler sie freigibt – und bis dahin „können sie keine Bestellungen aufgeben oder B2B-Preise sehen“. Das ist der richtige Weg für eine Käuferin, die ein Konto will. Es ist der falsche Weg, ihn einer Käuferin aufzuzwingen, die bis Freitag einen Preis will – und genau deshalb braucht die Angebotsebene eine Oberfläche, die mit einer E-Mail-Adresse allein funktioniert.

Die zweite ist die Käuferin, die angemeldet, aber keinem Unternehmensstandort zugeordnet ist. Shopifys Hilfe ist direkt: Eine solche Kundin wird auch angemeldet wie eine Endkundin behandelt. purchasingCompany ist undefined, Kataloge greifen nicht, und die B2B-Profilblöcke rendern nicht. Eine Erweiterung kann die Angebote dieser Käuferin trotzdem über die Kunden-ID auflisten, aber nichts an Unternehmenspreisen oder Zahlungszielen existiert für sie, bis ein Admin sie einem Standort zuordnet.

QuotWays Antwort auf beides, als eine Implementierung gekennzeichnet: Der Vorschlag an einen Gast geht an ein gehostetes Portal über einen Magic Link, der standardmäßig sieben Tage gültig ist, abgesichert durch einen Einmalcode an dasselbe Postfach, der nach einer Stunde abläuft; ein Gast, der später ein Konto hat, kann das Angebot mit einem Einmalpasscode ins Konto übernehmen; und die E-Mail, die einen Vorschlag ankündigt, verlinkt nur dann in die Kontoseite, wenn der Shop aktuelle Kundenkonten betreibt und die Käuferin eine angemeldete Kundin ist – andernfalls ins Portal. Beide Oberflächen tragen dieselben Aktionen – annehmen, erwidern, ablehnen, Nachricht, käuferseitige Freigaben – auf jedem Tarif.

Headless ändert die Anmeldung, nicht das Modell

Auf Hydrogen oder einer eigenen Storefront authentifiziert sich die Käuferin über die Customer Account API, und der B2B-Kontext ist etwas, das die Storefront explizit trägt: Sie fragt die Unternehmenskontakte der Kundin ab, um die Standorte zu finden, für die sie kaufen darf, bietet bei mehreren eine Auswahl an und schickt dann companyLocationId zusammen mit dem Kunden-Zugriffstoken in @inContext(buyer: …) auf Storefront-API-Abfragen – so kommen kontextbezogene Preise, Mengenregeln und Mengenpreise für diesen Standort zurück – und in cartCreate oder cartBuyerIdentityUpdate als buyerIdentity des Warenkorbs. Zwei Vorbehalte von Shopifys eigener Seite: Das Ändern der Käuferidentität an einem bestehenden Warenkorb kann Produkte entfernen, die für diese Käuferin nicht veröffentlicht sind, und das Customer-Account-Zugriffstoken „kann nur verwendet werden, um die Käuferidentität eines Warenkorbs zu aktualisieren“, nicht um die Kundin über die Storefront API abzufragen.

Für das Portal heißt das: Die Spalte Kundenkonto-Erweiterung verschwindet – es gibt kein von Shopify gerendertes Konto, das zu erweitern wäre –, und die Angebots-UI ist Ihre, mit demselben Backend-Vertrag, den eine Erweiterung nutzen würde, und derselben Identitätsprüfung: Der Standort, den die Käuferin gewählt hat, ist der Standort, für den das Angebot gilt, und der Ausgangspreis ist der, den der Käuferkontext zurückgibt.

Kann eine Käuferin einen Bestellentwurf sehen?

Ein umgewandeltes Angebot ist ein Bestellentwurf, bis die Käuferin bezahlt, also kommt die Frage in jedem Scoping-Gespräch. Das Standardkonto zeigt Bestellungen; ein Bestellentwurf erreicht die Käuferin als der Rechnungslink, den Shopify sendet, und sobald er eine Bestellung mit Zahlungsziel ist, erscheint er mit „Jetzt bezahlen“ und Fälligkeitsdatum. Darunter stellt die Customer Account API customer.draftOrders bereit – jeweils mit status, der invoiceUrl, „die der Kundin in der Rechnungs-E-Mail gesendet wird“, der purchasingEntity, der deposit und den Positionen –, sodass eine Erweiterungsseite oder eine Headless-Storefront die offenen Entwürfe einer Käuferin neben ihren Angeboten auflisten und direkt zum Checkout verlinken kann. Ob Shopifys eigene Konto-UI Entwürfe als Abschnitt auflistet, sagen die Hilfeseiten nicht, also sollte ein Projekt, das die Liste braucht, sie aus der API rendern, statt anzunehmen, die Standardseite hätte sie.

Die Oberfläche entscheiden

Wenn	Dann
Käuferinnen sind Unternehmenskontakte, die ihre Rechnungen bereits im Konto bezahlen	Angebote gehören ins Konto: eine Vollseiten-Erweiterung im Menü, ein Block auf der Bestellübersicht, der dorthin zeigt
Manche Käuferinnen fragen Angebote an, bevor sie ein Konto haben oder bevor das Unternehmen freigegeben ist	Eine gehostete Oberfläche per E-Mail und ein Übernahmeschritt, sobald das Konto existiert
Der Shop hat noch nicht auf aktuelle Kundenkonten umgestellt	Die gehostete Oberfläche ist die einzige; die Umstellung ist eine Shopify-Einstellung, kein Projekt
Die Storefront ist headless	Die Customer Account API für die Anmeldung, companyLocationId auf jeder Abfrage und im Warenkorb, Ihre eigene Angebots-UI auf demselben Backend
Das Portal muss wie die Marke aussehen, nicht wie Shopify	Die gehostete oder die Headless-Oberfläche; die Erweiterung erbt das Konto-Theme
Eine reiche, zustandsbehaftete Käufer-UI ist gefordert	Aus der Erweiterung heraushalten (64 / 128 KB, nur Shopify-Komponenten); die Erweiterung ist der Einstieg, das Backend der Zustand
Käuferinnen sollen sich ein Unternehmenskonto selbst anlegen	Shopify Forms’ Unternehmenskonto-Anfrage, mit dem Freigabeschritt im Onboarding eingeplant

Fehlerfälle

Fehlerfall	Was passiert	Entwurf
Ein Legacy-Zweig im Plan	Aufwand für eine Oberfläche, die B2B nicht nutzen kann und die Shopify abschaltet	Zweig streichen; „keine aktuellen Konten“ als „nur gehostete Oberfläche“ behandeln
Gäste als „erst registrieren“ geplant	Die Anfrage geht an der Registrierungsmauer verloren	Eine Oberfläche, die mit einer E-Mail-Adresse funktioniert; Übernahme später
Angemeldete, aber nicht zugeordnete Käuferin als B2B behandelt	purchasingCompany ist undefined, Katalogpreise greifen nicht, Zahlungsziele existieren nicht	purchasingCompany prüfen und leiten; die Zuordnung zu einem Standort zur Onboarding-Aufgabe machen
Vollseite und Block in einer Erweiterung	Von der Plattformregel abgelehnt	Geschwister-Erweiterungen plus Editor-Erweiterungssammlung
Reicher Client in der Erweiterung	Über dem 64/128-KB-Limit oder im Kampf mit dem Komponentensatz	Dünner Client; Zustand im Backend
Backend vertraut dem Ursprung	Jeder kann den Endpunkt aufrufen; Shopify sagt, die Anfrage kann von überall kommen	Session-Token bei jedem Aufruf prüfen; CORS * ist Pflicht, also ist die Autorisierung das Token, nie der Ursprung
Käuferin mit mehreren Standorten fragt für den falschen Standort an	Der Vorschlag wird gegen einen Katalog bepreist, unter dem die Käuferin nicht auschecken wird	Den gewählten Standort zum Anfragezeitpunkt aus dem Konto (oder der Headless-Auswahl) übernehmen und am Angebot führen
Magic-Link-E-Mail im Spam	Der Gast erreicht das Portal nie	SPF und DKIM auf der Versanddomain; Code-Neuversand aus dem Portal selbst
Portal auf einer zweiten Domain überrascht die Käuferin	Vertrauen sinkt; der Support fragt „ist das von Ihnen?“	Logo und Farben des Shops im Portal; E-Mails nur mit Namen, nie mit Preisen

Wie QuotWay es macht

Eine Implementierung, damit sich die Grenzen oben an etwas Gebautem prüfen lassen. QuotWay liefert drei Kundenkonto-Erweiterungen: eine Vollseite „Meine Angebote“ auf customer-account.page.render, einen Block „Meine Angebote ansehen“ auf der Bestellübersicht, der auf die shop-eigene Route /account/pages/… verweist (der Slug wird über api_access aus einem app-eigenen Metaobjekt gelesen), und eine Editor-Erweiterungssammlung, mit der ein Händler beide in einem Schritt hinzufügt – die Aufteilung ist die Plattformregel oben, keine Vorliebe. Die Seite ruft das Backend der App mit dem Session-Token im Authorization-Header unter network_access auf; darin listet eine angemeldete Käuferin Angebote, liest einen Vorschlag, nimmt an, erwidert, lehnt ab, schreibt Nachrichten, bearbeitet einen käuferseitigen Freigabeschritt, übernimmt Gastangebote und gibt eine Schnellbestellung auf. Gäste, Käuferinnen in Shops ohne aktuelle Konten und alle, die die Routing-Regel ausschließt, bekommen das gehostete Portal per Magic Link mit denselben Aktionen, auf jedem Tarif. Die Händlersicht steht auf der Funktionsseite zum Käuferportal und in der Dokumentation zu Gastangeboten und Kontoübernahme; die Tarife auf der Preisseite; die Starttests für Konten, Standorte und Anmeldung im 50-Tests-Startplan.

Die Shopify-Fakten in diesem Beitrag werden in der Shopify-B2B-Referenz aktuell gehalten.

Häufige Fragen

Funktioniert Shopify B2B mit Legacy-Kundenkonten?

Nein, und das hat es nie: Shopifys B2B-Dokumentation sagt, dass Legacy-Kundenkonten nicht für B2B-Kunden und -Bestellungen verwendet werden können. Legacy-Konten sind seit dem 26. Februar 2026 veraltet, ein Abschaltdatum wird später 2026 bekannt gegeben. Ein B2B-Projekt zielt auf die aktuellen Kundenkonten; ein Shop, der noch auf Legacy-Konten läuft, stellt in den Einstellungen um, bevor B2B überhaupt nutzbar ist.

Können sich B2B-Käuferinnen mit einem Passwort anmelden?

Nicht in Shopifys Kundenkonten. Eine Käuferin meldet sich mit der E-Mail-Adresse ihres Unternehmensstandorts und einem einmaligen Code an, der dorthin geschickt wird; ein Passwort gibt es nicht. Ein Shop mit eigenem Identitätsanbieter kann ihn über OAuth 2.0 oder OpenID Connect anbinden, und Sitzungen können bis zu 365 Tage dauern.

Kann eine App eine Seite zu Shopify-Kundenkonten hinzufügen?

Ja. Eine Kundenkonto-UI-Erweiterung mit dem Vollseiten-Target erzeugt eine Seite, die der Händler ins Kontomenü aufnimmt, und andere Targets ergänzen Blöcke auf den Seiten Bestellungen, Bestellstatus und Profil. Die Erweiterung läuft in einer Sandbox, rendert Shopifys Komponenten, ist auf 64 KB begrenzt (128 KB für eine Vollseite) und erreicht das Backend der App über ein Session-Token. Eine Vollseite kann sich keine Erweiterung mit anderen Targets teilen.

Kann eine Käuferin ohne Shopify-Konto ein Angebot anfragen?

Shopify hat kein Anfrageobjekt, das ist also ganz Sache der Angebotsebene. Ein Gast kann über eine gehostete Seite bedient werden, die per E-Mail erreicht wird – Magic Link plus Einmalcode – und das Angebot später einem Konto zuordnen. Der native Weg, aus einem Gast eine Unternehmenskäuferin zu machen, ist das Formular für Unternehmenskonto-Anfragen, das Unternehmen, Standort und Kundin anlegt, damit der Händler sie freigibt.

Kann eine Käuferin einen Bestellentwurf in ihrem Konto sehen?

Über den Rechnungslink und über die API. Die Customer Account API stellt die Bestellentwürfe der Kundin mit Status, Rechnungs-URL, Einkaufsentität, Anzahlung und Positionen bereit, sodass eine Erweiterung oder eine Headless-Storefront sie auflisten kann. Bestellungen mit Zahlungsziel erscheinen im Konto mit „Jetzt bezahlen“ und Fälligkeitsdatum.

Brauche ich Shopify Plus für ein B2B-Käuferportal?

Nein. B2B gibt es auf jedem Shopify-Tarif, aktuelle Kundenkonten auf jedem Tarif, und Kundenkonto-UI-Erweiterungen laufen in jedem Shop, der sie hat. Plus ergänzt Anzahlungen, unbegrenzt viele aktive Kataloge und die direkte Katalogzuweisung – nichts davon braucht das Portal selbst.

Quellen

Shopify-Seiten, alle am 22. September 2026 in API-Version 2026-07 gelesen, sofern nicht anders datiert:

• Anmeldung und Kundenkonten im B2B und Zahlungsziele im B2B einrichten
• Unternehmenskonto-Anfragen und Unternehmenskontakte und Berechtigungen
• Kundenkonten einrichten und verwalten
• Kundenkonto-UI-Erweiterungen, ihre Targets und Capabilities; die Authenticated Account API und die Session Token API
• Customer Account API: Customer und DraftOrder
• Headless mit B2B und die Customer Account API mit Hydrogen
• Ablösung der Legacy-Konten und die Identitätsergänzungen aus Spring ’26: die Shopify-B2B-Referenz, geprüft am 20. September 2026

QuotWays Erweiterungen, Routing und Portalverhalten sind aus ihrem Quellcode beschrieben (Erweiterungskonfiguration, der API-Client der Erweiterung und der Käufer-Link-Resolver) sowie aus der oben verlinkten Dokumentation.