Von commercetools zu einem eigenen Solidus Shop wechseln

Was commercetools ist und wer es überwächst

commercetools ist Enterprise Software für den Onlinehandel, und sie ist gut in dem, wofür sie gemacht ist. Sie ist API first und cloud native, wird von der commercetools GmbH aus München betrieben und verkauft, was die Branche Composable Commerce nennt: statt einer Anwendung, die alles kann, bekommst du einen Satz Commerce APIs (Produkte, Warenkörbe, Bestellungen, Kunden, Zahlungen) und baust den Rest des Shops rundherum zusammen.¹ Das Unternehmen war Gründungsmitglied der MACH Alliance, jener Gruppe, die Architekturen aus Microservices, API first Diensten, cloud nativem Hosting und einem headless Frontend propagiert.² Wenn du wirklich im großen Maßstab fährst, mit mehreren Marken, Regionen und Verkaufskanälen an einem gemeinsamen Commerce Kern, und das Team dazu hast, dann verdient commercetools seinen Platz. Für dieses Unternehmen ist der Artikel nicht gedacht.

Er ist für das andere. Für die mittelgroße Händlerin oder Marke, der Composable Commerce verkauft wurde, die einen Stapel einzelner Dienste rund um die commercetools APIs gebaut hat, die Spezialisten angestellt oder gemietet hat, damit alles miteinander redet, und die jetzt die Jahreskosten dem gegenüberstellt, was der Shop tatsächlich tut, und die Rechnung nicht aufgeht. Für dieses Unternehmen ist die ehrliche Frage nicht, ob commercetools gute Software ist. Das ist sie. Die Frage ist die Passung: Brauchst du eine Composable Plattform und das Team, das sie voraussetzt, oder würde eine einzige eigene Anwendung, die du von vorn bis hinten lesen kannst, dem Shop dienen, den du wirklich betreibst?

Diese eigene Anwendung baue ich auf Solidus, einem quelloffenen Commerce Framework auf Ruby on Rails unter der freizügigen BSD 3 clause Lizenz.³ Ich führe den Umzug durch, und das Ergebnis gehört dir. Dieser Text ist spezifisch für commercetools: wie die APIs und der Import und Export wirklich funktionieren, was das Composable Modell bindet, und welche ehrliche Form ein Umzug auf einen einzigen Rails Shop hat. Für die tiefen Details, wie jede Datenart wandert, verlinke ich die Artikel, die das behandeln, statt sie zu wiederholen. Beginne mit dem Überblick dazu, was sich überträgt und was nicht.

Das Problem ist hier nicht der Besitz. Es sind Passung und Kosten

Bei einem gehosteten Shop wie Shopify ist der ehrliche Hebel oft der Besitz: deine Daten liegen in einem fremden Produkt und gehen zu fremden Bedingungen hinaus. commercetools ist das nicht. Deine Daten gehören dir, sie liegen in einem gut dokumentierten Modell, und du kannst sie alle über die API zurücklesen. Ich tue also nicht so, als wäre der Pitch eine Befreiung. Er ist es nicht.

Der Hebel ist Geld und Form. Zwei Dinge treiben den Umzug. Das erste sind die Kosten. commercetools veröffentlicht keinen Listenpreis. Die Preisseite schickt dich zum Vertrieb und beschreibt ein Modell nach Bestellmengen statt nach einem Anteil am Umsatz: in ihren eigenen Worten "unlike GMV based models, our order based approach ensures no hidden fees or penalties for scaling", mit Funktionen zum Kombinieren und Zusatzpaketen wie Premium Support, einem Audit Log, erweiterten B2B APIs, zusätzlichen Regionen und einem Checkout Produkt.⁴ Das ist ein Enterprise Vertrag, kalkuliert auf dein Volumen, und für einen mittelgroßen Shop ist er häufig die größte einzelne Zeile im Technologiebudget. Ich erfinde keine Zahl, denn commercetools nennt keine, und dein Angebot ist deines.

Das zweite ist die Form. Composable Commerce ist nicht eine Rechnung. Es ist die commercetools Lizenz plus die Dienste, die du darum herum zusammensetzt: ein eigenes Content System, ein eigener Such und Merchandising Dienst, ein Frontend, das jemand bauen und hosten muss, oft eine Middleware Schicht, die Daten zwischen allem hin und her schiebt, und die Leute, die dieses Geflecht gesund halten. Jedes Teil kann ausgezeichnet sein. Zusammen sind sie ein System, das ein stehendes Team oder eine stehende Agentur braucht, und diese Kosten sinken nicht, wenn deine Bestellzahl sinkt. Ein Shop mit ein paar Millionen Umsatz im Jahr betreibt am Ende das Betriebsmodell eines Shops mit ein paar hundert Millionen. Diese Fehlpassung findet die Budgetrunde im Jänner.

Daten herausholen: die API, GraphQL und warum es keinen Export Knopf gibt

commercetools ist eine API first Plattform, also kommen deine Daten so heraus, wie alles andere hineingeht: über die API. Es gibt zwei Oberflächen über denselben Daten.

Die HTTP API ist REST förmig und nach Project gegliedert, dem obersten Container für alle deine Daten und deine Konfiguration, angesprochen über einen Project Key. Der Host folgt dem Muster https://api.{region}.commercetools.com, mit der Region, die bei der Anmeldung festgelegt wurde, und jede Anfrage trägt ein OAuth 2.0 Bearer Token.⁵ Die GraphQL API liegt unter /{projectKey}/graphql als einzelner POST Endpunkt, erreicht dieselben Ressourcen über dieselben Clients und Scopes und lässt dich in einer Abfrage genau die Felder und Referenzen holen, die du willst, was ein Exportskript kurz hält.⁶

Jetzt der Teil, der jene überrascht, die bei einer Enterprise Plattform ein Enterprise Exportwerkzeug erwarten. Es gibt keine symmetrische Massenexport API. commercetools gibt dir eine reiche asynchrone Import API zum Hineinbringen von Daten, und zum Herausholen bietet es CSV Export aus dem Merchant Center und ein Project Sync Kommandozeilenwerkzeug zum Kopieren zwischen Projects, aber keinen einzigen Endpunkt, der alles exportiert.⁷ Eine vollständige Extraktion ist also ein Paging Job gegen die Query API oder GraphQL, Ressource für Ressource: Produkte, Produkttypen, Kategorien, Kunden, Bestellungen, Warenkörbe, Bestände, Preise, Custom Objects.

Das Paging hat eine spezifische Falle, die du vor dem Start kennen solltest. Eine Abfrage liefert höchstens 500 Elemente auf einmal, und das Paging über Offsets hört jenseits eines Offsets von 10.000 auf zu funktionieren, du kannst also nicht einfach offset=0, 500, 1000 bis ans Ende eines großen Katalogs oder Kundenstamms laufen.⁸ Stattdessen pagst du mit einem Prädikat: sortiere nach id und frage jedes Mal den nächsten Block, in dem die id größer ist als die zuletzt gesehene. Dazu kommt, dass Order Search nur Bestellungen der letzten drei Monate zurückgibt, die volle Bestellhistorie muss also vom gewöhnlichen Orders Endpunkt kommen, nicht vom Such Endpunkt.⁸ Nichts davon ist schwer. Es sind ein paar hundert Zeilen sorgfältiges Skript und viel Prüfen. Aber es ist Arbeit, die du planst, kein Knopf, den du drückst.

Das Datenmodell und warum das Mapping die eigentliche Arbeit ist

Der Export ist die leichte Hälfte. Die eigentliche Arbeit ist das Mapping, denn commercetools modelliert einen Katalog abstrakter als eine einzelne Shop Anwendung.

Ein Product hat einen ProductType, der seine Attribute definiert, eine oder mehrere Variants mit je eigener SKU, eigenen Preisen und Attributwerten, und lokalisierte Felder für jede Sprache, die dein Project unterstützt. Preise können in einer Variante eingebettet sein oder als Standalone Prices geführt werden, es gibt Kundengruppen und Channels, und fast jede Ressource kann einen Custom Type mit deinen eigenen Feldern tragen. Das Modell ist gebaut, um viele Frontends und viele Märkte aus einem Kern zu bedienen, also hält es Unterscheidungen fest, die ein einzelner Shop nie gebraucht hat. Die Expansion von Referenzen ist auf drei Ebenen Tiefe begrenzt,⁸ was prägt, wie du verbundene Daten in einem Durchgang ziehst.

Das auf Solidus zu mappen ist eine bewusste Übung, keine Kopie. Solidus hat sein eigenes klares Modell: Produkte, Varianten, Optionstypen und Werte, Taxons, Preise und Bestände. Die Fragen, die Zeit kosten, sind die, die nur dein Team beantworten kann. Welche der Produktattribute werden noch genutzt und welche sind tote Felder, die seit zwei Jahren niemand gesetzt hat. Welche lokalisierten Texte zählen für die Märkte, in denen du wirklich verkaufst. Welche Custom Objects tragen echte Logik und welche waren ein Behelf für etwas, das Solidus von Haus aus kann. Das ist dieselbe Katalogabstimmung, die ich in Produkt und Katalogdaten migrieren beschreibe, und hier wird ein Umzug gewonnen oder verloren. Plane dafür Tage Arbeit ein, mit jemandem aus dem Geschäft an deiner Seite, keinen Nachmittag.

Kunden kommen über die Customers API herüber, mit E Mail, Namen, Adressen, Kundengruppen und Custom Fields. Passwörter nicht. commercetools verwaltet das Passwort eines Kunden über seine Endpunkte zum Anmelden, Ändern und Zurücksetzen und gibt das gespeicherte Passwort nie über die API zurück, und es löscht das Passwort ganz, wenn du den Kunden auf externe Authentifizierung umstellst.⁹ Das ist korrekte Sicherheit, und es ist dieselbe harte Grenze, die jede Plattform hat: du nimmst alles zum Konto mit außer dem Geheimnis, und die Kunden setzen beim ersten Besuch im neuen Shop ein neues Passwort. Die Kontenseite steht vollständig in Kundenkonten und Adressen migrieren.

Die Fallen, die für commercetools spezifisch sind

Jede Plattform hält auf ihre Weise fest. commercetools sperrt deine Daten nicht ein, aber das Composable Modell hat seine eigene Schwerkraft.

Der Stapel ringsum, nicht der Kern. Was wirklich schwer zu verlassen ist, ist nicht commercetools die API. Es ist das Geflecht aus Diensten, das du darum herum gebaut hast. Das headless Frontend, das Content System, der Suchdienst, die Integrationsschicht: jedes hat seinen eigenen Vertrag, seine eigenen Daten und seine eigenen Eigenheiten, und ein Weggang von commercetools heißt meist, alle auf einmal neu zu denken, weil sie nur je existierten, um sich mit dem Commerce Kern zusammenzusetzen. Auf einer einzigen Solidus Anwendung fällt das meiste dieses Geflechts in eine Codebasis zusammen. Das ist der Sinn des Umzugs, und zugleich der Grund, warum er ein Projekt ist und kein Wochenende.

Die Abhängigkeit von Spezialisten. Composable Commerce setzt ein Team voraus, das mehrere bewegliche Teile im Kopf halten kann. Sind das Externe oder eine Agentur, mietest du das Wissen über deinen eigenen Shop, und der Tag, an dem die Zusammenarbeit endet, ist der Tag, an dem der Shop schwer zu ändern wird. Eine eigene Rails Anwendung, deren Funktionen durch Tests abgedeckt sind, kann eine einzelne fähige Entwicklerin übernehmen und weiterführen. Das ist ein anderes Betriebsmodell, und für einen mittelgroßen Shop meist das richtige.

Zahlungen liegen beim Dienstleister, wie überall. commercetools modelliert ein Payment, sagt aber klar, dass "the actual financial process is carried out by an external PSP", der über eine anbieterspezifische Integration angebunden ist.¹⁰ Die gespeicherten Karten und die wiederkehrenden Mandate liegen also nicht in commercetools zum Exportieren. Sie liegen bei Stripe, Adyen, Mollie oder wer dein Anbieter ist, als Tokens, die zum Konto dieses Anbieters gehören. Behält der neue Solidus Shop denselben Anbieter und dasselbe Händlerkonto, bleiben die Tokens gültig und nichts muss neu eingegeben werden. Wechselst du den Anbieter, ist eine Token Migration ein zertifizierter Vorgang zwischen den beiden Anbietern, und das ist das Schwerste an jedem Shop Umzug. Kläre das zuerst, bevor eine Zeile des neuen Shops gebaut wird. Die Tiefe steht in Zahlungstoken und gespeicherte Karten migrieren, und wie das schiefgeht, steht in den versteckten Gefahren beim Wechseln von Payment Gateways.

SEO und URLs liegen in deinem Frontend. Weil commercetools headless ist, waren deine Adressen, deine Weiterleitungen und deine gerenderten Seiten nie Sache von commercetools. Sie liegen im Frontend, das du gebaut hast, und sie kommen nur mit, wenn du sie als erstklassiges Ergebnis behandelst. Jede Produkt, Kategorie und Inhalts URL, die ein Ranking oder einen Link hält, braucht eine Zeile in einer Weiterleitungsliste und eine dauerhafte 301 auf ihre neue Adresse, direkt auf das Ziel gerichtet und mindestens ein Jahr gehalten. In den Shops, die ich baue, liegen diese Weiterleitungen in einer Datenbanktabelle mit einer Verwaltungsmaske, damit sie jedes künftige Deployment überleben und deine eigenen Leute eine ergänzen können. Die Mechanik steht in Produkt und Katalogdaten migrieren.

Ein durchgerechnetes Beispiel in Graz

Machen wir es konkret mit einem erfundenen Unternehmen. Hain und Halm (hainundhalm.example) ist eine Grazer Marke für Wohn und Außenbereich. Sie macht rund 5 Millionen Euro Umsatz im Jahr online, in Österreich und zwei weiteren europäischen Märkten, mit etwa 4.000 Produkten und einem gesunden Großhandelsteil an Einrichtungsstudios. Vor drei Jahren hat eine Agentur sie auf einen Composable Stack gebracht: commercetools als Commerce Kern, ein headless Content System, ein gehosteter Such und Merchandising Dienst, ein Next.js Storefront und ein Middleware Dienst, der Lager und Buchhaltung einbindet. Es funktioniert. Es trägt auch ein Betriebsmodell, das für eine weit größere Firma gebaut ist.

Als die Gründerin es zusammenzählt, ist die commercetools Lizenz die größte einzelne Technologiezeile, kalkuliert auf die Bestellmenge, und sie sitzt obendrauf auf vier weiteren Abonnements und einem laufenden Agenturhonorar, das die Komposition gesund hält. Der Shop braucht keine fünf Marken und fünf Regionen. Er braucht einen verlässlichen Shop für Österreich und die EU mit einer guten Großhandelspreisliste. Der Plan ist also, auf eine einzige eigene Solidus Anwendung rechtzumachen und die Teile zu behalten, die sich wirklich rechnen.

Der Umzug klärt die harten Fragen zuerst. Hain und Halm nimmt Zahlungen schon über ihr eigenes Stripe Konto entgegen, der neue Solidus Shop verbindet sich also mit demselben Konto, und die gespeicherten Karten bleiben liegen: das schlimmste Problem im Projekt trifft am Ende gar nicht zu, und genau darum prüfst du es am ersten Tag und nicht in Woche zehn. Dann die Daten. Ein Paging Skript läuft die Endpunkte Products, Customers und Orders mit id Prädikaten ab, weil Katalog und Kundenstamm beide weit über der 10.000er Offset Grenze liegen und weil die volle Bestellhistorie älter ist als die drei Monate, die Order Search zurückgibt. Drei Jahre Bestellungen kommen als Nur Lese Historie herüber, und der volle Export wird für die Buchhaltung archiviert. Das Produkt Mapping dauert am längsten: von den Attributen, die auf den commercetools Produkttypen definiert sind, erweist sich ein gutes Drittel als ungenutzt, und zwei Custom Objects, die eine Agentur gebaut hat, sind Funktionen, die Solidus von Haus aus mitbringt.

Die Tabelle, nach der das Projekt läuft:

Was	Wie es commercetools verlässt	Wo es landet
Produkte, Varianten, Preise	Query API oder GraphQL, nach id gepagt, dann gemappt	Solidus Produkte und Varianten (Katalog)
Kunden, Adressen	Customers API, keine Passwörter	Solidus Konten, Passwort Reset beim ersten Besuch (Konten)
Bestellhistorie	Orders Endpunkt, nicht Order Search	Nur Lese Bestellhistorie (Bestellungen)
Gespeicherte Karten	Bleiben im Stripe Konto, nicht in commercetools	Dasselbe Stripe Konto, Tokens unverändert (Tokens)
URLs und SEO	Aus dem alten Frontend, nicht dem Commerce Kern	Weiterleitungsliste, 301 in einer Solidus Verwaltungstabelle

Zum Umschalttag sind aus fünf Diensten und einem Agenturhonorar eine Rails Anwendung geworden, die die eigene Entwicklerin der Gründerin lesen kann. Die Großhandelspreisliste, die zwei europäischen Märkte und die Lageranbindung sind Funktionen des Baus, keine Abonnements. Was nicht günstiger wird, ist die Ehrlichkeit über das erste Jahr: der Bau ist eine echte Vorabausgabe, und genau das ist das Thema der Gesamtkosten über fünf Jahre.

Der ehrliche Umzug auf Solidus

Die Form des Projekts ist dieselbe, die ich von jeder Plattform aus fahre, mit den commercetools Besonderheiten eingesetzt.

Die Erkundung klärt, was später teuer zu ändern ist: die Vier Spalten Liste dessen, was sauber, teilweise, nur neu gebaut oder gar nicht umziehen kann, wer im Geschäft die Daten besitzt, und die Zahlungsentscheidung, derselbe Anbieter oder eine Token Migration. Der Bau lässt die Extraktionsskripte wieder und wieder gegen eine Kopie des echten Projects laufen, damit der letzte Import am Umschalttag langweilig ist. Ein Parallelbetrieb von drei bis vier Wochen hält den alten Stack live, während der Solidus Shop auf einer Staging Adresse mit echten Produkten und Testzahlungen geprüft wird, bei eingefrorenem Katalog, damit die beiden nicht auseinanderlaufen. Das Umschalten passiert an einem ruhigen Wochentagmorgen: letzter Import, Zahlen gegen commercetools geprüft, Domain auf den neuen Shop gezeigt, eine echte Bestellung je Zahlart und Land aufgegeben und erstattet, die wichtigsten URLs aus der Weiterleitungsliste von Hand geprüft. Der alte Stack bleibt dreißig Tage unangetastet als Rückfallebene, dann werden die Verträge heruntergefahren.

Weil commercetools API first ist, ist ein Teil hier leichter als auf einem Monolithen: deine Organisation denkt schon in API und getrenntem Frontend, und Solidus kann diese Form behalten. Es hat eine vollständige REST API, wenn also die mobile App oder das eigene Frontend ein Behalter ist, kann der neue Shop sie genauso bedienen wie der alte Kern, und genau das ist das Thema von headless und API first Solidus. Du wirst nicht in einen Monolithen zurückgezwungen, um den Kosten der Komposition zu entkommen. Du wählst einen einfacheren, der dir gehört.

Wann du auf commercetools bleiben solltest

Das zählt so viel wie der Rest, denn für manche Leserin ist die Antwort, zu bleiben, und das sage ich lieber.

Bleib, wenn du wirklich in dem Maßstab fährst, für den commercetools gebaut ist: viele Marken oder Regionen an einem Commerce Kern, hohe und stoßweise Bestellmengen, eine Roadmap, die Microservices braucht, die du unabhängig ausrollen und skalieren kannst. Bleib, wenn du das stehende Team im Haus hast, das Composable Commerce voraussetzt, und dieses Team ausgelastet und wirksam ist statt ein Kostenpunkt, den du bereust. Bleib, wenn deine Grenze Durchsatz und globale Reichweite ist und nicht der Preis der Lizenz. In diesen Fällen tut die Plattform genau das, wofür sie entworfen wurde, und eine einzige Rails Anwendung wäre ein Rückschritt, kein Rechtmachen.

Zieh um, wenn das Composable Modell schwerer ist als der Shop darunter: wenn du Enterprise Kosten zahlst und ein Spezialistenteam mietest, um eine Architektur zu betreiben, deren Maßstab du nicht nutzen wirst, und was du wirklich brauchst, ist ein verlässlicher, gut getesteter Shop, der dir gehört und den du ohne drei Dienstleister im Raum ändern kannst. Die entscheidende Frage ist nicht "ist commercetools gut". Sie ist "brauche ich dieses Betriebsmodell". Die Enterprise Vergleiche stehen neben diesem: dieselbe Logik gegen Magento oder Adobe Commerce und gegen SAP Commerce Cloud, und gegen die andere quelloffene headless Option in von Medusa zu einem eigenen Shop wechseln. Wenn die tiefere Sorge ist, die Daten in einer Form zu besitzen, die eine Entwicklerin lesen kann, ist wem gehören eigentlich deine Geschäftsdaten der richtige Anfang.

Was das für dich bedeutet

commercetools ist starke Enterprise Software, und sie zu verlassen ist eine Frage von Aufwand und Passung, nie von Erlaubnis, denn die Daten gehören dir und die API gibt sie zurück. Der Aufwand ist ehrliche Arbeit: eine Paging Extraktion, die die 500er Seiten, die 10.000er Offset Grenze und das Dreimonatsfenster der Order Search beachtet, ein echtes Mapping von einem abstrakten Composable Modell auf ein einziges klares Solidus Schema, Passwörter beim ersten Login neu gesetzt, und Zahlungen vor allem anderen geklärt. Der Lohn ist eine eigene Rails Anwendung statt einer gemieteten Komposition, rechtgemacht auf den Shop, den du wirklich betreibst.

Wenn die commercetools Rechnung und der Stack ringsum nicht mehr zum Geschäft darunter passen, bring das Lizenzangebot, die Abonnements und die Agenturzahlen zu einem kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich stelle sie einem Solidus Bau gegenüber, benenne die Zahlungs und Mapping Fragen zuerst und sage dir ehrlich, ob sich ein Umzug für dich rechnet. Manchmal tut er es nicht, und dann sage ich das.

Footnotes

1. commercetools, About commercetools (Hauptsitz in München als commercetools GmbH, cloud native und API first, Ursprung von Headless Commerce, eine Enterprise Commerce Plattform), abgerufen am 14. November 2026, https://commercetools.com/company/about ↩

2. MACH Alliance, commercetools Mitgliedsprofil (Gründungsmitglied der MACH Alliance und eine Composable Commerce Plattform, wobei MACH für Microservices based, API first, Cloud native und Headless steht), abgerufen am 14. November 2026, https://machalliance.org/members/commercetools ↩

3. Solidus, Repository solidusio/solidus auf GitHub (ein quelloffenes Commerce Framework auf Ruby on Rails unter der BSD 3 clause Lizenz), abgerufen am 14. November 2026, https://github.com/solidusio/solidus ↩

4. commercetools, Pricing (kein veröffentlichter Listenpreis, Kontakt zum Vertrieb, ein order based Modell, beschrieben als unlike GMV based models, mit Paketen und Add ons wie Premium Support, Audit Log, erweiterten B2B APIs, zusätzlichen Regionen und Checkout), abgerufen am 14. November 2026, https://commercetools.com/pricing ↩

5. commercetools, API general concepts (HTTP API Host Muster https://api.{region}.commercetools.com, OAuth 2.0 Bearer Tokens, isolierte Regionen und ein Project als oberster Container, angesprochen über seinen project key), abgerufen am 14. November 2026, https://docs.commercetools.com/api/general-concepts ↩

6. commercetools, GraphQL API (ein einzelner POST Endpunkt unter /{projectKey}/graphql über dieselben Ressourcen, Clients und Scopes wie die HTTP API, mit einer Query Complexity Grenze von 20000), abgerufen am 14. November 2026, https://docs.commercetools.com/api/graphql ↩

7. commercetools, Import and Export overview (eine asynchrone Import API mit ImportContainers und ImportRequests von je bis zu 20 Ressourcen für Produkte, Preise, Kunden, Bestellungen, Kategorien und mehr, mit Export als Merchant Center CSV und dem commercetools project sync Kommandozeilenwerkzeug, aber ohne einen einzigen Massenexport Endpunkt), abgerufen am 14. November 2026, https://docs.commercetools.com/api/import-export/overview ↩

8. commercetools, API limits (höchstens 500 Elemente je Abfrage, maximaler Pagination Offset von 10000, Expansionstiefe von 3 Referenzen, 500 Update Actions je Anfrage, 14 MB Request Body und Order Search, die nur Bestellungen der letzten 3 Monate zurückgibt), abgerufen am 14. November 2026, https://docs.commercetools.com/api/limits ↩ ↩² ↩³

9. commercetools, Customers API (Passwörter werden über die Endpunkte zum Anmelden, Ändern und Zurücksetzen behandelt, nie von der API zurückgegeben und gelöscht, wenn ein Kunde auf externe Authentifizierung umgestellt wird), abgerufen am 14. November 2026, https://docs.commercetools.com/api/projects/customers ↩

10. commercetools, Payments API (ein Payment hält den externen Anbieter, die Methode, die Transaktionen und den Status fest, während "the actual financial process is carried out by an external PSP", angebunden über eine anbieterspezifische Integration), abgerufen am 14. November 2026, https://docs.commercetools.com/api/projects/payments ↩