ChatGPT Merchants und der Weg des Händlers: von der Registrierung bis zur Verantwortung

1. Was ist ein ChatGPT‑Händler und worin unterscheidet er sich von einem „gewöhnlichen Shop“

Aus der Perspektive von Entwicklerinnen und Entwicklern ist es leicht, Ebenen zu verwechseln: Wir haben eine Next.js‑App, einen MCP‑Server, irgendein Commerce‑Backend – und irgendwo dort noch OpenAI, ChatGPT, Stripe und andere große Dienste. Man möchte sagen: „Das ist alles ein einziges großes System; Hauptsache, die Tests sind grün.“

In der Welt des AI‑Commerce sind juristische und technische Grenzen sehr strikt getrennt. ChatGPT wird nicht zu Ihrem Shop und nicht zum Zahlungsabwickler. Es stellt lediglich ein intelligentes Interface bereit und ruft Ihre APIs nach offenen Spezifikationen auf. Händler bleibt das konkrete Unternehmen mit einem konkreten Katalog und der Verantwortung gegenüber den Nutzenden.

Das Verständnis der Händlerrolle brauchen nicht nur Juristinnen und Juristen. Davon hängen Architekturentscheidungen ab: wo die Feed‑Daten gespeichert werden, wie Sie Bestellungen validieren, was Sie loggen, wie Sie Abweichungen zwischen dem, was im Chat gezeigt wird, und dem, was tatsächlich in Ihrem System passiert ist, untersuchen und beheben.

Beispiel

Stellen wir uns klassisches E‑Commerce vor: Sie haben eine Website, einen Warenkorb, Checkout, eine Integration mit einem Zahlungsanbieter. Der Nutzer öffnet den Browser, klickt mit der Maus, gibt Kartendaten ein – alles klar.

Ein ChatGPT‑Händler ist derselbe Shop, nur dass er über einen KI‑Dialog mit hohem Automatisierungsgrad verkaufen kann. Der Unterschied liegt nicht darin, was Sie verkaufen, sondern darin, wie der Nutzer den Weg von der Anfrage bis zur Zahlung durchläuft.

Aus Sicht von OpenAI ist ein Händler eine Organisation (oder eine Einzelunternehmerin/ein Einzelunternehmer), die:

• einen Product Feed gemäß der OpenAI‑Spezifikation bereitstellt (CSV/TSV/XML/JSON mit strukturierten Daten zu SKUs);
• sich im Portal ChatGPT Merchants registriert und eine Prüfung von Kategorien und rechtlichen Anforderungen durchläuft;
• in der fortgeschrittenen Variante Agentic Checkout und Delegated Payment implementiert, damit Instant Checkout in ChatGPT eine Zahlung durchführen kann, ohne auf Ihre Website zu wechseln.

Ein Händler ist also nicht „jemand, der ein Widget gebaut hat“, sondern Eigentümer des Sortiments und der finanziellen Verpflichtungen. In unserem Kurs übernehmen wir zwei Rollen: Wir sind das Team, das GiftGenius als ChatGPT App baut, und das Team, das das Händler‑Backend entwickelt, das diese App bedient.

2. Portal ChatGPT Merchants: der Weg von der Bewerbung bis zum produktiven Händler

OpenAI hat eine eigene Website für Verkäufer – das Portal ChatGPT Merchants. Darüber gelangen Händler in das Programm Instant Checkout und schließen ihre Feeds und ihr Backend an. Wir zerlegen diesen Weg in Schritte, ohne schon tief in technische Details zu gehen (das folgt in der nächsten Vorlesung).

Vorbereitung

Bevor jemand aus Ihrem Team auf die Schaltfläche „Apply“ klickt, sollten bereits einige Bausteine vorhanden sein:

Juristische Person und Website. Ein Händler hat eine eigene Domain und ein für Nutzende verständliches Storefront – auch wenn alles später über ChatGPT verkauft wird, erwartet OpenAI eine öffentliche Schaufensterseite.

Sortiment im Rahmen der Richtlinien. In der vorherigen Vorlesung haben wir über die Prohibited Products Policy gesprochen: Verboten sind z. B. Waffen oder bestimmte medizinische Produkte. Jedes Produkt, das Sie über ChatGPT verkaufen möchten, muss in die Liste der erlaubten Kategorien passen.

Basale Zahlungsinfrastruktur. Auch wenn Delegated Payment Ihnen die direkte Arbeit mit Karten abnimmt, müssen Sie eine Integration mit einem PSP (z. B. Stripe) haben und verstehen, wie Sie Bestellungen und Rückerstattungen in Ihrem System anlegen.

Bewerbung im Merchants‑Portal

Aus technischer Sicht ist das ein eher langweiliger, aber wichtiger Schritt: Sie rufen die Website auf und bewerben sich für das Programm Instant Checkout. Üblicherweise wird gefragt:

• wer Sie sind (juristische Person, Website, Kontaktdaten);
• was Sie verkaufen (Kategorien, Preisspanne, Regionen);
• wie Sie den Product Feed bereitstellen möchten (Format, URL, Aktualisierungsfrequenz).

Dieser Teil hat wenig mit TypeScript zu tun, beeinflusst aber Ihre Roadmap stark: Solange der Händler die Basiskontrolle nicht bestanden hat, wird kein Instant Checkout aktiviert – selbst wenn Ihr Code perfekt ist.

Anbindung des Product Feed

Nachdem die Bewerbung geprüft wurde und grundsätzlich Zustimmung besteht, verlagert sich der technische Fokus auf den Product Feed. Laut Dokumentation ist der Feed für die Integration obligatorisch: Ohne ihn weiß ChatGPT schlicht nicht, was Sie verkaufen.

In diesem Schritt:

1. Bestimmen Sie das Feed‑Format (meist CSV oder JSON).
2. Vereinbaren Sie, wie Sie ihn bereitstellen: Das kann eine vorab signierte URL auf S3 sein oder ein HTTPS‑Endpoint, an den Sie periodisch Updates POSTen.
3. Bereiten Sie die Mindestfelder für jede SKU vor: id, title, description, price, currency, availability, link, Bilder sowie die Flags enable_search / enable_checkout.

Solange Sie enable_checkout = false setzen, kann der Händler im reinen Discovery‑Modus arbeiten: ChatGPT findet und empfiehlt Produkte, leitet Nutzende bei einem Kaufversuch aber auf Ihre Website weiter.

ACP‑Integration (mehr in der nächsten Vorlesung)

Wenn der Product Feed stabil ist und Sie weitergehen möchten, beginnt die Integration von Agentic Checkout und Delegated Payment. Aus Sicht des Merchants‑Portals ist das ein separater Block von Anforderungen: Sie müssen Endpunkte /checkout_sessions implementieren, den delegierten Zahlungstoken (Shared Payment Token) annehmen und Sitzungen korrekt mit den passenden Statuswerten beenden (not_ready_for_payment, ready_for_payment, completed, canceled).

In dieser Vorlesung erwähnen wir das nur als „nächste Schwierigkeitsstufe“. Alle Protokolldetails und die Schemas der Anfragen behandeln wir in der nächsten Vorlesung.

3.5. Zertifizierung und Aktivierung von Instant Checkout

Der letzte Schritt – die Prüfung, wie sich Ihr Backend in realen Szenarien verhält:

• werden Bestellungen korrekt angelegt;
• stimmen die Preise aus dem Feed mit den Preisen überein, zu denen Sie tatsächlich Geld einziehen;
• werden Fehler und Rückerstattungen korrekt verarbeitet;
• entsprechen Ihre ToS/Privacy‑Seiten den Erwartungen von OpenAI und dem lokalen Recht.

Danach erhält der Händler den Status „bereit für Instant Checkout“, und seine Produkte mit enable_checkout = true können direkt in ChatGPT gekauft werden.

Man kann sich das als einfache Grafik vorstellen:

flowchart TD
  A[Produkt und Website vorhanden] --> B[Bewerbung bei ChatGPT Merchants]
  B --> C[Product Feed angebunden]
  C --> D["ACP‑Backend implementiert
(checkout_sessions + delegated payment)"]
  D --> E[Zertifizierung
und Aktivierung von Instant Checkout]

3. Händler-Varianten: Etsy/Shopify vs. Custom‑Backend

Gute Nachricht: Nicht alle Händler müssen das gesamte ACP‑Backend selbst schreiben. Für einige Plattformen (Shopify, Etsy u. a.) gibt es bereits Integrationen, die die technische Umsetzung übernehmen.

Wenn Sie über Shopify oder Etsy verkaufen, sieht die Struktur ungefähr so aus: Sie aktivieren dort eine Option wie „Show in ChatGPT“, und die Plattform:

• formt und pflegt den Product Feed im erforderlichen Format;
• implementiert oder proxyt die ACP‑Endpoints;
• verbindet sich mit Stripe oder einem anderen PSP.

Sie als Shop‑Inhaberin/Shop‑Inhaber kümmern sich mehr um Sortiment und Beschreibungen als um REST‑Endpoints.

Wenn Sie hingegen – wie in unserem Kurs mit GiftGenius – einen maßgeschneiderten Händler mit eigenem Backend bauen, haben Sie deutlich mehr Freiheit, aber auch mehr Arbeit: Sie schreiben den Code für Feed, Checkout und die Integration mit dem Zahlungsanbieter selbst.

Praktisch lässt sich das in einer Tabelle vergleichen:

Für den Kurs wählen wir bewusst die dritte Variante: Nur so können wir den gesamten Weg von Feed bis zu Webhooks und verlässlicher Produktion durchlaufen.

4. Verantwortung des Händlers: Daten, Bestellungen, Richtlinien, Geld

Wenn Sie ChatGPT‑Händler werden, verpflichten Sie sich nicht nur zur Freude über neue Bestellungen, sondern auch zu einer Reihe sehr konkreter Pflichten. Wir betrachten sie schichtweise.

Katalogdaten und Qualität des Product Feed

Der Product Feed ist die Quelle der Wahrheit für ChatGPT. Wenn darin steht, dass ein Produkt 10 USD kostet und verfügbar ist, dann sieht der Nutzer genau das im Chat. Wenn der Feed „lügt“, bekommen Sie im besten Fall einen unzufriedenen Kunden, im schlimmsten Fall einen Richtlinienverstoß und Probleme mit OpenAI.

Von einem Händler wird erwartet:

• Korrektheit der Pflichtfelder (richtiges Preisformat, ISO‑Währungscodes, gültige HTTPS‑Links, funktionierende Bilder);
• ausreichend häufige Aktualisierung des Feeds, um keine „Geisterprodukte“ zu verkaufen;
• Konsistenz der Identifikatoren: Die id der SKU im Feed muss mit der ID in Ihrer Datenbank und im Bestellsystem übereinstimmen, damit Sie eindeutig verstehen können, was genau gekauft wurde.

Zieht man eine Parallele zum klassischen E‑Commerce, ist der Product Feed hier Ihr „Export in einen Marktplatz“ – nur dass der Marktplatz in diesem Fall kein Website‑Frontend ist, sondern ein smarter Assistent, der im Kopf der Nutzenden lebt und Unstimmigkeiten leicht merkt.

Bestellungen, Versand und Rückerstattungen

ChatGPT wird nicht zum Support Ihres Shops. Der Nutzer interagiert zwar mit ihm, rechtlich kauft er die Ware jedoch beim Händler und nicht bei OpenAI. Das heißt:

• Sie sind dafür verantwortlich, dass die Bestellung in Ihrem System angelegt wird und bis ins Lager gelangt;
• Sie sind dafür verantwortlich, dass die Sendung an die im Instant Checkout angegebene Adresse zugestellt wird;
• Sie sind für die Abwicklung von Rückerstattungen, Stornos, Teilrückerstattungen usw. verantwortlich.

Im Rahmen von ACP enthält eine checkout_session nach erfolgreichem Abschluss üblicherweise ein order‑Objekt mit Feldern. Das ist jedoch nur eine Spiegelung dessen, was in Ihrem Backend passiert ist – Sie entscheiden, wie der Eintrag in der Tabelle orders aussieht, welche Status es gibt und wie diese mit der Logistik verknüpft sind.

Richtlinien und Geografie

Im Merchants‑Portal geben Sie an, in welchen Ländern Sie verkaufen und welche Produkttypen. OpenAI prüft seinerseits, dass Sie:

• keine verbotenen Kategorien verkaufen;
• lokales Recht einhalten (z. B. Steuerregeln und Altersbeschränkungen);
• verständliche Terms of Service und eine Privacy Policy bereitstellen.

In späteren Modulen sprechen wir noch ausführlich über rechtliche Seiten, aber schon jetzt ist es hilfreich, so zu denken: „Wenn ich einer Juristin/einem Juristen nicht erklären kann, was genau ich wo verkaufe, wird ChatGPT das kaum für mich verkaufen.“

Geld und Zahlungsanbieter

Und schließlich das heikelste Thema – das Geld. Glücklicherweise vereinfachen ACP und Delegated Payment das Leben der Entwickler erheblich:

• ChatGPT und der Zahlungsanbieter (z. B. Stripe) vereinbaren einen Shared Payment Token für einen konkreten Betrag und Händler;
• Ihr Backend erhält diesen Token in der complete‑Anfrage und verwendet ihn in Ihrem PSP, ohne „rohe“ Kartendaten zu sehen.

Sie werden also nicht zum PCI‑kompatiblen Monstrum, speichern keine Kartennummern und geraten nicht in Auditalbträume. Ihre Verantwortung besteht darin, den delegierten Token korrekt zu verwenden (Zahlung anlegen, Geld einziehen, Rückerstattung durchführen) und eine saubere Buchführung zu betreiben.

5. Wie das in die GiftGenius‑Architektur passt

Kehren wir zu unserer Lernanwendung GiftGenius zurück. Architektonisch möchten wir nach Modul 14, dass die Studierenden ein Diagramm der Ebene zeichnen können: „Nutzer → ChatGPT → App‑Widget → MCP‑Gateway → Product Feed / Agents / ACP‑Backend“.

In diesem Schema wird die Händlerrolle in unserem Backend umgesetzt, während Widget und App lediglich das „Gesicht“ dieses Händlers in ChatGPT sind.

Händlerkonfiguration im Code

Beginnen wir mit einem einfachen Schritt: Wir legen im Code eine Konfigurationsstruktur für den Händler an. Nehmen wir ein TypeScript‑Modul lib/merchantConfig.ts in unserem Next.js‑Projekt:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // Händler‑ID in ACP/Stripe
  name: string;              // Menschlich lesbarer Name
  feedUrl: string;           // Wo der Product Feed liegt
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // später aktivieren
};

Zum einen machen wir hier die Grenzen explizit: Es ist der Händler, nicht ein „Widget“. Zum anderen lagern wir wichtige Werte in Umgebungsvariablen aus – in den Modulen zu Deployment und Umgebungen werden wir noch oft daran erinnern, warum man solche Dinge nicht hardcodieren sollte.

Der Bequemlichkeit halber können wir eine kleine Funktion hinzufügen, die unserem Code sagt, ob Instant Checkout aktuell verwendet werden darf:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // In Dev und Staging Instant Checkout immer deaktivieren
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

So bereiten wir die Architektur von vornherein darauf vor, dass sich das Verhalten in unterschiedlichen Umgebungen unterscheidet, und verhindern, dass wir (oder GPT) versehentlich von einer Testumgebung in einen produktiven Checkout geraten.

MCP‑Tool zum Abrufen von Händlerinformationen

Oft ist es praktisch, dem Modell und dem Widget die Möglichkeit zu geben, zu erfahren, in welchem Modus der Händler gerade arbeitet. Zum Beispiel, damit GPT keinen Instant Checkout vorschlägt, wenn er deaktiviert ist.

Im MCP‑Server (den wir in den vorherigen Modulen aufgesetzt haben) lässt sich ein einfaches Tool anlegen:

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "Gibt Basisinformationen zum Händler GiftGenius zurück",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

Dieses Tool tut nichts Außergewöhnliches, schafft aber einen expliziten Ort, an dem das Modell fragen kann: „Kann man jetzt direkt im Chat kaufen oder nur per Link wechseln?“

Verwendung der Händlerinformationen im Widget

Auf Widget‑Seite können wir mithilfe der uns bereits bekannten Hooks der Apps SDK get_merchant_info aufrufen und das UI abhängig vom Modus verändern. Ein einfaches Beispiel für eine Komponente:

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

So eine kleine Komponente macht für die Nutzenden (und für Sie selbst im Dev‑Modus) angenehm sichtbar, in welchem Zustand sich die Integration mit ChatGPT gerade befindet.

6. Praktische Mini‑Aufgabe

Damit die Vorlesung nicht nur auf der Ebene „Worte und Diagramme“ bleibt, probieren Sie die folgenden Schritte in Ihrem GiftGenius‑Projekt (oder einem ähnlichen) aus:

Erstens fügen Sie ein Modul für die Händlerkonfiguration hinzu, ähnlich wie merchantConfig.ts, und lagern MERCHANT_ID und PRODUCT_FEED_URL in Umgebungsvariablen aus. Für lokale Entwicklung können Sie .env.local verwenden, für Production – die Einstellungen in Vercel oder einer anderen Plattform.

Zweitens implementieren Sie im MCP‑Server ein einfaches Tool get_merchant_info, das zumindest name und instantCheckout zurückgibt. Überlegen Sie, welche Felder für das Modell noch nützlich sein könnten: zum Beispiel eine Liste der unterstützten Währungen oder der Lieferländer.

Drittens fügen Sie im Widget ein kleines UI‑Element hinzu (Badge, Statuszeile, Beschriftung auf der Produktkarte), das dieses Tool verwendet und den Nutzenden zeigt, in welchem Modus Ihr Händler gerade arbeitet: nur Empfehlungen oder bereits vollwertiger Instant Checkout. Das ist nicht nur nützlich für die UX, sondern hilft auch hervorragend beim Debugging.

Schließlich versuchen Sie schriftlich zu skizzieren, mit welchen Schritten Ihr konkretes Projekt vom Zustand „Wir haben Website und Backend“ zum Status eines ChatGPT‑Händlers gelangt. Wo genau binden Sie den Product Feed an, wann schalten Sie enable_checkout ein, wann beginnen Sie mit der Implementierung der ACP‑Endpoints? So eine Übung diszipliniert und hilft, wichtige, wenig geliebte Dinge wie die Rückgaberichtlinie nicht zu vergessen.

7. Typische Fehler auf dem Weg zum ChatGPT‑Händler

Fehler Nr. 1: „ChatGPT ist mein Shop“.
Manchmal „verschieben“ Entwickler gedanklich alles auf die Seite von ChatGPT: als würde es Kataloge speichern, Preise berechnen und Bestellungen ausführen. In Wirklichkeit ist ChatGPT Interface und Orchestrator, nicht Ihr ERP. Vergisst man das, baut man leicht eine Architektur ohne eigene, saubere Bestellmodellierung; alle Daten leben „irgendwo in Prompts“, und jede Verhaltensänderung des Modells gefährdet die Konsistenz.

Fehler Nr. 2: Instant Checkout erwarten – ohne separate Registrierung und ACP.
Die Tatsache, dass Sie ein großartiges Widget gebaut und den Product Feed eingerichtet haben, schaltet Instant Checkout noch nicht automatisch frei. Es braucht die Bewerbung im Merchants‑Portal, die Kategoriefreigabe, die Implementierung von Agentic Checkout und Delegated Payment sowie das Bestehen von Tests. Der Versuch, Instant Checkout „per Default“ einzuplanen, endet meist damit, dass GPT den Nutzenden etwas vorschlägt, das es in Wahrheit nicht gibt, oder Links statt der erwarteten Zahlungsansichten anzeigt.

Fehler Nr. 3: Hartes Hardcoding von Händler‑IDs und Feed‑URLs.
Klassiker: MERCHANT_ID = "prod-123" steht direkt im Code, die Feed‑URL als String in der Widget‑Komponente. Sobald ein Staging oder ein zweiter Händler benötigt wird, beginnt die große Suchen‑und‑Ersetzen‑Orgie. Viel sicherer ist es, solche Dinge in Konfiguration und Umgebungsvariablen auszulagern und über eine kleine Abstraktionsschicht zu verwenden – so wie wir es mit MerchantConfig getan haben.

Fehler Nr. 4: Der Product Feed lebt sein eigenes Leben – losgelöst von Bestellungen.
Wenn im Feed die SKU GIFT_RED_MUG 10 USD kostet, Sie im Bestellsystem für denselben Identifikator aber aus irgendwelchen Gründen 12 USD abbuchen, kommt das früher oder später ans Licht. Quelle der Wahrheit für Preise und Verfügbarkeit muss entweder der Feed sein, der aus Ihren internen Daten generiert wird, oder eine gemeinsame Zwischenschicht, der sowohl Feed als auch Checkout vertrauen. Der Versuch einer „doppelten Buchführung“ (eins für ChatGPT, eins für die eigene Website) fällt sehr schnell auf die Füße.

Fehler Nr. 5: Die Rolle des Zahlungsanbieters und die Speicherung von Zahlungsdaten ignorieren.
Mitunter ist die Versuchung groß, in den Token des Zahlungsanbieters „hineinzuschauen“ oder sogar zusätzlich Zahlungsdaten im eigenen UI abzufragen. Das verletzt nicht nur das Modell von Delegated Payment, sondern kann Sie auch in die Welt von PCI DSS und harten Compliance‑Anforderungen ziehen. Gute Praxis ist, den Shared Payment Token als undurchsichtige Zeichenkette zu behandeln, ihn nur im SDK des Zahlungsanbieters zu verwenden und nirgendwo zu loggen oder zu cachen.

Fehler Nr. 6: Die Mehrschrittigkeit des Onboardings unterschätzen und ohne Plan starten.
Ein häufiger organisatorischer Fehler ist zu denken: „Wir schließen uns einfach an ChatGPT an – wie schwer kann das sein?“ Tatsächlich besteht der Weg des Händlers aus vielen Schritten: technischen (Feed, Backend, Tests) und nicht‑technischen (rechtliche Dokumente, Kategoriefreigabe, regionale Beschränkungen). Ohne einen vorher aufgeschriebenen Plan springt das Team chaotisch zwischen Aufgaben, und Deadlines beginnen schneller zu „schmelzen“ als die eigene Begeisterung für AI‑Commerce.