Das Gesamtbild des AI‑Commerce und die Rolle von OpenAI

1. Was ist AI‑Commerce überhaupt

Wenn klassischer E‑Commerce die Geschichte „auf die Website gegangen – Katalog geöffnet – in den Warenkorb gelegt – sich durch drei Formulare geschleppt“ ist, dann ist AI‑Commerce der Fall, in dem der Dialog mit ChatGPT zum primären Interface wird. Der Nutzer formuliert die Aufgabe in natürlicher Sprache, und ein Agent innerhalb von ChatGPT übernimmt die Rolle von Berater, Merchandiser und teilweise Product Manager.

Anfragen sehen nicht aus wie „category=Socken&price_max=20“, sondern wie „Wähle ein lustiges, aber nicht zu peinliches Geschenk für einen Kollegen bis 20 US‑Dollar, das per E‑Mail verschickt werden kann“. Der Agent interpretiert die Aufgabe, stellt Rückfragen, schaut in den Produktkatalog, erklärt Vor‑ und Nachteile der Optionen und führt den Nutzer anschließend bis zum Kauf – und das alles, ohne dass der Nutzer einen „Warenkorb“ als separate Seite sieht.

Aus architektonischer Sicht verwandelt sich die ChatGPT‑App in diesem Moment vom „intelligenten Geschenkekatalog“ in eine Commerce‑Applikation, die Folgendes beherrscht:

1. Die Absicht des Nutzers und Randbedingungen verstehen (Budget, Geschenktyp, Land, digital/physisch).
2. Konkrete SKU aus dem Product Feed auswählen und die Entscheidung begründen.
3. Den Kauf über das standardisierte Protokoll ACP (Agentic Commerce Protocol) anstoßen.

Die Idee des AI‑Commerce ist, dass „Katalog + Checkout“ nicht mehr eine separate Website sind, sondern eine logische Fortsetzung des Dialogs, den der Nutzer ohnehin mit GPT führt.

2. Klassischer E‑Commerce versus AI‑Commerce

Um den Unterschied besser zu spüren, ist es praktisch, beide Ansätze nebeneinanderzulegen. Unten steht eine vereinfachte Tabelle, die keinen Anspruch auf Vollständigkeit erhebt, aber den Paradigmenwechsel gut hervorhebt.

Praktische Folge: Im AI‑Commerce verschiebt sich der Fokus weg vom visuellen Design von „Katalog und Warenkorb“ hin zur Datenstruktur und Datenqualität sowie zum formalen Protokoll der Interaktion zwischen ChatGPT, eurem Backend und dem Zahlungsanbieter. Product Feed und ACP-Endpoints werden zu einem ebenso wichtigen „UI“ wie das Widget selbst.

Während man im klassischen Shop einen Teil des UX im Browser ausgleichen kann, stützt sich das Modell im AI‑Commerce fast vollständig auf die Daten und Schemata, die ihr bereitstellt: von der Produktbeschreibung bis zu den Status einer Checkout‑Sitzung.

3. Bausteine von OpenAI Commerce

OpenAI bietet kein „magisches Zahlungssystem GPTPay“, das alles von selbst erledigt. Stattdessen gibt es einen Satz an Spezifikationen und Guides, die beschreiben, wie bestehende Merchants und Zahlungsanbieter korrekt an die Welt von ChatGPT angebunden werden. Von diesen Dokumenten sind für uns vier Bausteine besonders wichtig.

Erstens, die Product Feed Specification. Das ist das offizielle Format, in dem der Verkäufer seinen Produktkatalog beschreibt: id, title, description, Preis, Währung, Verfügbarkeit, Bilder usw. Der Feed fungiert als „strukturierte Quelle der Wahrheit“, die OpenAI validiert, indexiert und für Suche, Ranking und Checkout innerhalb von ChatGPT nutzt.

Zweitens, die Agentic Checkout Specification. Das ist ein REST‑Vertrag für die Arbeit mit der Entität checkout_session: Das API beschreibt, wie man eine Payment‑Sitzung erstellt, aktualisiert (z. B. bei Änderung von Adresse oder Versandoption) und abschließt, sowie welche Felder das Backend zurückgeben muss (Summen, Steuern, Fulfillment‑Optionen, Links zu Rückgabebedingungen usw.).

Drittens, die Delegated Payment Specification. Das ist das Protokoll, nach dem die Agentenplattform (ChatGPT) vom Zahlungsanbieter einen delegierten Zahlungstoken erhält (z. B. Stripe Shared Payment Token) und ihn an euer Backend weitergibt, ohne die eigentlichen Zahlungsdaten offenzulegen. Der Token ist in Betrag, Lebensdauer und anderen Parametern beschränkt und wird von eurem Backend verwendet, um die reale Zahlung beim PSP zu erzeugen.

Und schließlich der Instant Checkout in ChatGPT – eine UX‑Schicht über diesen Spezifikationen. Im Chat erscheint ein kompakter Checkout‑Bildschirm: ausgewähltes Produkt, Preis, Adresse, Zahlungsmethode. Unter der Haube stützt er sich auf den Product Feed, ruft eure /checkout_sessions gemäß Agentic Checkout Spec auf und verwendet Delegated Payment, um die Transaktion beim PSP durchzuführen.

Die gute Nachricht ist: All das ist kein „geheimes ChatGPT‑API“, sondern offene Spezifikationen des ACP (Agentic Commerce Protocol). Das bedeutet, dass dasselbe Backend theoretisch auch mit anderen AI‑Plattformen funktionieren kann, sofern sie ebenfalls ACP unterstützen.

4. Rollen und Verantwortungsgrenzen

Jetzt wird’s spannend: Sobald Geld ins Spiel kommt, werden Regulierer und Juristen plötzlich eure besten Freunde. Um den Überblick zu behalten, ist es wichtig, die Rollen klar zu trennen.

Die wichtigste Rolle hat die Agentenplattform, in unserem Fall ChatGPT. Sie verantwortet die User Experience: Chat, Widgets, Instant‑Checkout‑UI. Die Plattform initiiert den Commerce‑Flow, wählt Produkte aus dem Product Feed, ruft eure ACP‑Endpoints auf und zeigt dem Nutzer das Ergebnis. Dabei wird ChatGPT jedoch weder Eigentümer der Ware noch Zahlungsanbieter und speichert eure Produktdaten nicht als „eigenen Katalog“ – es nutzt genau den Feed, den ihr bereitgestellt habt.

In der zweiten Rolle – der Merchant (Seller, Merchant‑of‑Record). Das ist der Eigentümer der Waren oder Dienstleistungen. Der Merchant ist verantwortlich für den Product Feed (Struktur, Qualität, Aktualität von Preisen und Verfügbarkeit), für die korrekte Implementierung der ACP‑Endpoints (/checkout_sessions, Webhooks), für das Anlegen und die Speicherung von Bestellungen sowie für Versand, Support und Retouren. Die ACP‑Dokumentation betont, dass der Merchant im rechtlichen Sinne Verkäufer bleibt – nicht die Agentenplattform.

Die dritte Rolle – der Zahlungsanbieter (PSP), z. B. Stripe. Der PSP ist verantwortlich für die Zahlungsabwicklung, die Einhaltung von PCI DSS und weiteren Anforderungen, die Speicherung von Zahlungsdaten sowie die Bekämpfung von Fraud und Chargebacks. Im Kontext von Delegated Payment stellt der PSP der Agentenplattform einen speziellen Token (SPT) aus, der anschließend von eurem Server zur Erstellung der realen Zahlung verwendet wird (z. B. PaymentIntent in Stripe).

Die vierte und wichtigste Rolle – der Nutzer. Er formuliert die Aufgabe, trifft die finale Kaufentscheidung, erteilt die Zahlungsfreigabe und liest idealerweise die Terms / Privacy Policy, die ihr im Checkout‑UI ehrlich anzeigt. Der Product Feed kann Links zu diesen Dokumenten und zu den Rückgabebedingungen enthalten, um Vertrauen und Transparenz zu erhöhen.

Zur Übersicht fassen wir das in einer kleinen Tabelle zusammen:

Die Trennung der Verantwortungsbereiche ist nicht nur für Juristen wichtig, sondern auch für die Architektur. Wenn ihr morgen z. B. einen zweiten PSP anschließt, müsst ihr die ChatGPT‑App nicht umschreiben: Es reicht, die Delegated‑Payment‑Schicht im eigenen Backend anzupassen. Und wenn eine zweite AI‑Plattform hinzukommt, die ebenfalls ACP versteht, könnt ihr sowohl den Product Feed als auch die Checkout‑Endpoints wiederverwenden.

5. Wie ein „alles im Dialog“-Kaufszenario aussieht

Fassen wir nun alles zusammen und betrachten aus architektonischer Sicht ein End‑to‑End‑Szenario für den Kauf eines digitalen Geschenks in ChatGPT. Es ist vereinfacht, spiegelt aber die Essenz wider.

sequenceDiagram
  participant U as Nutzer
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as Merchant Backend
  participant P as PSP (Stripe)

  U->>C: "Kauf ein digitales Geschenk bis $50"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: Liste passender SKU
  G-->>C: Geschenkoptionen + Metadaten
  C-->>U: Erklärt die Auswahl, bietet Optionen an
  U->>C: "Ich nehme dieses"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: Zahlungs-Token (SPT) anfordern
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: Zahlung ausführen
  B-->>C: Webhook zur Auftragserstellung
  C-->>U: Kaufbestätigung

In der trockenen ACP‑Sprache passiert hier Folgendes:

1. Der Agent verwendet den Product Feed (über euer Backend), um passende SKU zu finden.
2. Bei der Entscheidung „wir kaufen“ erstellt ChatGPT eine checkout_session über euren /checkout_sessions‑Endpoint gemäß Agentic Checkout Spec.
3. Während des Instant Checkout fordert ChatGPT beim PSP einen delegierten Zahlungstoken für einen konkreten Betrag und Merchant an.
4. Dieser Token wird in POST /checkout_sessions/{id}/complete übergeben; euer Backend erzeugt die Zahlung beim PSP und legt die Bestellung an.
5. Wenn die Bestellung bereit ist, benachrichtigt euer Server OpenAI per Webhook, woraufhin der Nutzer die finale Bestätigung sieht.

Wichtig ist weniger, sich die Namen der Endpoints zu merken, als die Struktur zu sehen: Feed → Auswahl der SKU → checkout_session → Zahlung → Bestellung → Webhook. In den nächsten Vorlesungen nehmen wir jedes Teil separat auseinander, inklusive der Felder im Feed, der Felder der Checkout‑Sitzung und des Formats der delegierten Zahlungen.

6. GiftGenius: Wie unsere App in den AI‑Commerce passt

Bis zu diesem Punkt spielte GiftGenius die Rolle eines „Assistenten für Geschenke‑Discovery“. Er konnte:

• den Nutzer fragen, für wen und zu welchem Anlass ein Geschenk benötigt wird;
• die Tools von MCP zur Suche im eigenen Katalog verwenden;
• Karten mit Optionen im Widget zeigen und Follow‑up‑Buttons in den Chat schicken.

Aus Commerce‑Sicht war das ein „intelligentes Discovery“ ohne echten Kauf. In der Welt von OpenAI Commerce entspricht dieser Modus einem Feed, in dem für eine SKU enable_search = true gesetzt ist, aber enable_checkout = false: Produkte können gefunden und besprochen werden, aber der Instant Checkout ist für sie deaktiviert.

Im AI‑Commerce‑Modul verwandeln wir GiftGenius schrittweise in einen vollständig integrierten Merchant:

• Wir fügen einen strukturierten Product Feed nach OpenAI‑Spezifikation hinzu;
• wir entwerfen ein ACP‑Backend, das mit checkout_sessions umgehen kann;
• wir binden Delegated Payment über den Stripe Shared Payment Token an;
• wir bringen der App bei, dem Nutzer zu zeigen, dass er nicht nur auswählen, sondern das Geschenk direkt im Chat auch kaufen kann.

Damit das nicht wie „Schwarze Magie“ wirkt, fügen wir unserem Code eine kleine technische Schicht hinzu, die die Rollen und Schritte des Commerce‑Flows explizit modelliert. Das ist sowohl für Logs als auch für interne Tests nützlich.

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

Diese Typen helfen, bereits auf TypeScript‑Ebene gedanklich zu trennen, „wer was tut“. Wir können sie z. B. in Tests oder in einem Debug‑UI innerhalb des Widgets verwenden.

Ein kleines Beispielarray von Schritten für das Szenario „digitales Geschenk bis $50“:

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "Anfrage und Budget formulieren" },
  { id: "search", role: "chatgpt", description: "SKU aus dem Product Feed auswählen" },
  { id: "checkout", role: "merchant", description: "checkout_session erstellen" },
  { id: "payment", role: "psp", description: "Zahlung per Token ausführen" }
];

Dieser Code spricht noch mit keinem Netzwerkpartner, schafft aber bereits eine nützliche „Koordinatenachse“, um die wir in den nächsten Vorlesungen den echten ACP‑Code aufbauen werden.

7. Mini‑Aufgabe: Zerlegt den Flow „Kauf mir ein digitales Geschenk bis $50“

Zum Schluss der Vorlesung ist es hilfreich, das gerade Besprochene einmal selbst zu zerlegen. Nehmt die Nutzereingabe:

„Kauf mir ein digitales Geschenk bis $50“.

Aufgabe – beschreibt in 3–5 logischen Schritten, was als Nächstes passiert, und gebt für jeden Schritt an, wer ihn ausführt: ChatGPT, euer Merchant‑Backend, der Zahlungsanbieter oder der Nutzer selbst. Ihr könnt euch an der obigen Diagrammfolge und am Array digitalGiftFlow orientieren, müsst aber nicht 1:1 übereinstimmen.

Ihr könnt beispielsweise mit einem Schritt beginnen, in dem ChatGPT die Anfrage interpretiert und Details beim Nutzer nachfragt (digitaler Gutschein, Region des Empfängers, für wen genau das Geschenk ist). Anschließend ein Schritt, in dem euer Backend über den Product Feed passende SKU sucht, danach – das Erstellen der checkout_session, das Einholen eines Zahlungstokens vom PSP und der Abschluss des Kaufs.

Wenn ihr möchtet, könnt ihr das direkt in Code gießen, indem ihr dem digitalGiftFlow noch ein paar Schritte hinzufügt und sie in einem kleinen Debug‑Komponenten im Widget rendert. Solch eine Übung trainiert die Gewohnheit, nicht nur „über Code“, sondern auch über Rollen im Protokoll nachzudenken.

Ein Beispiel für einen einfachen API‑Endpoint, der einen solchen „Flow‑Plan“ entgegennehmen und loggen könnte (noch ohne echte Commerce‑Funktionalität):

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

In der Realität schreibt ihr statt console.log strukturierte Logs und speichert solche Szenarien möglicherweise als Teil der Dokumentation oder der Tests. Aber selbst so ein kleines Beispiel hilft, die abstrakte Architektur mit konkretem TypeScript‑Code in eurer Next.js‑Applikation zu verbinden.

Wenn ihr das in dieser Vorlesung erarbeitete Rollenbild im Kopf behaltet, werden die weiteren technischen Details – Felder des Product Feed, Schemata der Checkout‑Sitzungen und die Struktur delegierter Zahlungen – viel leichter einzuordnen sein, ganz ohne übertriebenen Romantizismus rund um den „allmächtigen GPT“.

8. Typische Missverständnisse rund um AI‑Commerce und Rollen

Fehler Nr. 1: zu glauben, „ChatGPT macht alles selbst“.
Manche Entwickler denken, es reicht, „Stripe anzuschließen“ und der „Modell‑API irgendwie Zugang zu geben“, und den Rest klärt GPT. In Wirklichkeit stützt sich AI‑Commerce rund um ChatGPT auf formale Spezifikationen: Product Feed, Agentic Checkout, Delegated Payment. Wenn ihr eure Produkte nicht als strukturierten Feed beschrieben, /checkout_sessions nicht implementiert und Delegated Payment nicht eingerichtet habt, kann kein Modell das für euch „erfinden“.

Fehler Nr. 2: die Rollen von ChatGPT und Merchant zu verwechseln.
Ein weiteres häufiges Missverständnis ist, ChatGPT als „Shop“ zu betrachten und sich selbst nur als „Kataloglieferant“. In Wahrheit ist es umgekehrt: Ihr bleibt Merchant, haltet den Product Feed vor, erstellt und betreut Bestellungen, bearbeitet Retouren. ChatGPT ist nur für die Dialog‑UX und das korrekte Aufrufen eurer ACP‑Endpoints verantwortlich. Wenn ihr versucht, das System so zu entwerfen, als würde „GPT selbst Abos verteilen und Waren versenden“, landet ihr früher oder später in einer juristischen und technischen Sackgasse.

Fehler Nr. 3: den Zahlungsanbieter als eigene Entität zu ignorieren.
Mitunter möchte man den PSP „im Backend verstecken“ und ihn wie jedes REST‑API behandeln, dabei vergessend, dass die Zahlungsebene nach eigenen Regeln funktioniert (PCI, Fraud, Chargebacks, Limits). Im ACP‑Ansatz gibt es nicht umsonst eine eigene Delegated‑Payment‑Spezifikation: Die Agentenplattform spricht mit dem PSP auf ihrer Ebene, erhält einen SPT‑Token und übergibt ihn euch, und ihr erzeugt die Zahlung. Wenn ihr versucht, dieses Schema zu umgehen und Kartendaten direkt in der App anzunehmen, schießt ihr euch schnell mit Compliance‑Anforderungen ins Knie.

Fehler Nr. 4: den Product Feed als „Marketing‑Einstellung“ statt als API für LLMs zu betrachten.
Viele kommen mit einem Google‑Shopping‑Hintergrund und denken über den Feed eher als etwas nach, das für den Werbeaccount wichtiger ist als für den Code. In der Welt des AI‑Commerce ist der Feed im Grunde die Wissensbasis eures Sortiments für das Modell. Wenn es dort kaputte Bildlinks, inkonsistente Attribute, seltsame Maßeinheiten und Marketing‑Übertreibungen statt Fakten gibt, wird das Modell Dinge vorschlagen, die ihr nicht wollt, und die Conversion sinkt.

Fehler Nr. 5: Instant Checkout „in einem Schritt“ einführen zu wollen.
Die Versuchung ist groß: „Lasst uns gleich enable_checkout aktivieren, damit Nutzer direkt aus dem Chat kaufen.“ Aber ohne gutes Discovery (qualitativer Feed), ohne zuverlässiges Checkout‑Backend und ohne durchdachte PSP‑Integration riskiert ihr ein fragiles System, in dem die Hälfte der Bestellungen auf halbem Weg hängen bleibt. Viel vernünftiger ist es, die von OpenAI vorgeschlagenen Stufen zu gehen: zuerst ein hochwertiger Product Feed, dann das Debugging der ACP‑Endpoints, anschließend Delegated Payment und erst danach die Aktivierung des Instant Checkout im Live‑Betrieb.