1. Alles funktioniert bereits separat …
Zu diesem Zeitpunkt wissen Sie bereits, wie der Commerce‑Flow rund um ChatGPT läuft. Der Merchant hat einen Product Feed, ACP‑Endpunkte sind implementiert (/checkout_sessions und Co.), Instant Checkout wickelt die Zahlung ab, und das Backend erhält Webhooks und legt Bestellungen an. All das kann sogar ohne Ihre ChatGPT App funktionieren: Product Feed + ACP-Backend genügen.
Separat können Sie bereits:
- einen Product Feed nach OpenAI-Spezifikation erstellen;
- Agentic Checkout / Delegated Payment entwerfen und implementieren;
- eine ChatGPT App mit Widget und MCP‑Tools für die Geschenksuche schreiben.
Für sich genommen sieht alles großartig aus, zusammen wird es jedoch leicht zu einem „Zoo von Services“. Das Widget lebt sein eigenes Leben, der MCP‑Server seines, das ACP‑Backend ein weiteres, und die Logik der Bestellungen und Webhooks noch ein viertes. Beim ersten Versuch, einen echten Kauf zu debuggen oder einen merkwürdigen Bug zu beheben, merken Sie plötzlich, dass niemand wirklich das große Ganze sieht.
Das Ziel dieser Vorlesung ist es, Sie aus diesem Zustand herauszuholen und eine ganzheitliche, zugleich realisierbare Architektur zu geben: Wie genau ist der Product Feed mit dem ACP‑Backend verbunden, wie verhalten sich beide zur ChatGPT App und zum Widget, wo genau der Zahlungsanbieter ins Bild kommt und wie das Ganze in verständliche Team‑Komponenten verpackt wird: Services, Datenbanken, APIs.
Dabei werden wir fortlaufend betonen, was harter Standard ist (SPEC) und was lediglich unsere Architekturentscheidung für GiftGenius darstellt.
Insight: ChatGPT ist ein kostenloses Google
ChatGPT arbeitet mit Nutzern ähnlich wie Google: Es bringt Ihnen kostenlos relevanten Traffic, weil es sein Geld an anderer Stelle verdient – an den Nutzern selbst.
Aus Business-Sicht bedeutet das etwas Einfaches: ChatGPT wird zu einem kostenlosen „Werbekanal“ für Ihre Produkte, sofern Sie Product Feed und ACP‑Backend angeschlossen haben. Das Modell wird Ihre Artikel vorschlagen, wenn sie zur Nutzeranfrage gut passen, und Sie müssen nicht zusätzlich für Impressions oder Klicks bezahlen.
Daraus folgen zwei praktische Schlussfolgerungen:
- Das Zeitfenster der Möglichkeiten ist VORÜBERGEHEND sehr günstig. Der Wettbewerb im ACP‑Ökosystem ist derzeit gering, und der Zugang zu oberen Preissegmenten ist auch ohne die üblichen Werbebudgets möglich. Das ist eine seltene Situation, in der Traffic mit hoher Conversion für teure Produkte (Luftfahrt, Immobilien, Premiumwaren, Versicherungen) Sie nichts kosten kann.
- Es lohnt sich, mit den margenstärksten Vertikalen zu beginnen. Wenn Sie Zugang zu Kategorien mit hohem Warenkorbwert haben, ist es rational, diese zuerst anzubinden:
- Verkauf/Vermietung von Flugzeugen, Yachten, Villen;
- Verkauf/Vermietung von Häusern und Premium‑Immobilien;
- Schmuck, teure Uhren, Versicherungsprodukte und ‑dienstleistungen.
Das garantiert keine „schnellen Millionen“, schafft aber eine Asymmetrie: Wer zuerst einen hochwertigen Product Feed und ein zuverlässiges ACP‑Backend in teuren Segmenten aufsetzt, erzielt einen überproportional hohen Gewinn von diesem Kanal, solange er unterschätzt und faktisch kostenlos ist.
2. GiftGenius‑Referenzarchitektur: in groben Zügen
Beginnen wir mit der Draufsicht. Erinnern wir uns an das Gesamtbild aus den vorherigen Modulen: Der Nutzer schreibt in ChatGPT, das Modell ruft Ihre Tools auf, und die Commerce‑Schicht lebt in einem separaten Backend.
Formulieren wir die Hauptbausteine von GiftGenius.
Erstens: ChatGPT‑UI und das GPT‑Modell, die den Dialog mit dem Nutzer führen und bei Bedarf die GiftGenius‑App einbinden (oder sogar ohne App arbeiten – nur über den Product Feed).
Zweitens: das GiftGenius‑Widget (Next.js + Apps SDK), das Geschenk‑Karten und bei Bedarf den Checkout‑Fortschritt anzeigt. Es läuft in der Sandbox window.openai und kennt keine echten Zahlungsdaten.
Drittens: die MCP‑Schicht, die dem Modell Tools für die Geschenksuche im Katalog (Product Feed) und eventuell zum Lesen der Bestellhistorie bereitstellt.
Viertens: das Commerce‑/ACP‑Backend, das:
- den Product Feed als Single Source of Truth für Produkte und SKUs liest;
- die Agentic Checkout Spec implementiert (/checkout_sessions, Webhooks, Statuswerte);
- mit dem Zahlungsanbieter (z. B. Stripe) gemäß Delegated Payment Spec spricht.
Fünftens: die Datenbanken für Katalog (falls der Feed aus einer DB erzeugt wird), Bestellungen und Hilfsstrukturen (Nutzer, Einstellungen).
Und schließlich der Zahlungsanbieter, der Zahlungsdaten speichert und verarbeitet und Webhooks zu Zahlungsergebnissen sendet.
Schematisch lässt sich das so darstellen:
graph LR U[Benutzer in ChatGPT] --> GPT[GPT-Modell] GPT -->|rendert| W[GiftGenius Widget
Next.js + Apps SDK] GPT -->|MCP-Tools| MCP[MCP-Server
Geschenksuche] MCP --> PF["Product Feed
(DB/JSON)"] GPT -->|ACP HTTP| ACP[GiftGenius Commerce Backend
Agentic Checkout] ACP --> ORDERS[Bestell-Datenbank] ACP --> PSP["Zahlungsanbieter
(Stripe u. a.)"] PSP --> ACP ACP -->|Webhooks/Ereignisse| GPT
Dieses Diagramm beschreibt die GiftGenius‑Architektur als Beispiel einer Umsetzung. Das Format des Product Feed, der Vertrag /checkout_sessions und das Delegated Payment‑Protokoll bleiben Teil des ACP‑Standards; die Platzierung der Services, DB‑Schemata und die Aufteilung in Prozesse sind Ihre Architekturentscheidung.
3. Wie Product Feed, ACP und Widget logisch verbunden sind
Um nicht in Pfeilen zu ertrinken, halten wir eine einfache, aber wesentliche Idee fest: Sie haben genau eine Quelle der Wahrheit für Produkte.
In der Welt von GiftGenius sei das eine Tabelle products + skus in PostgreSQL. Daraus:
- erzeugen Sie den Product Feed gemäß OpenAI‑Spezifikation (direkt oder per Export);
- bauen Sie einen Suchindex für MCP‑Tools (z. B. search_gifts);
- validieren Sie Anfragen des ACP‑Backends – prüfen Sie, dass die eingehende sku_id überhaupt existiert und einen korrekten Preis und eine korrekte Währung hat.
So blicken MCP‑Suche und ACP‑Checkout auf dieselben Daten, und das Widget zeigt nur die Ergebnisse an, die entweder aus MCP‑Tools oder mittelbar aus ACP (z. B. Bestellinformationen) kommen.
Man kann sich das als zwei „Fenster“ in denselben Katalog vorstellen: ein Fenster für Suche und Empfehlungen, das andere für den Kaufabschluss. Wenn diese Fenster in unterschiedliche Datenbanken schauen, erwartet Sie ein fröhliches Leben mit Desynchronisationen.
4. Daten modellieren: vom Product Feed bis zur Bestellung
Beginnen wir mit einfachen TypeScript‑Typen, die in Ihrem GiftGenius‑Repository leben (z. B. in src/domain/commerce.ts). Diese Typen sind keine wörtliche Kopie der Spezifikationen, spiegeln aber ihre Kernideen in einer für die App praktischen Form wider.
// src/domain/commerce.ts
export interface ProductSku {
id: string; // stabile SKU-ID (entspricht dem Product Feed)
title: string; // menschenlesbarer Titel
priceCents: number; // Preis in Cent/Kopeken
currency: string; // ISO-Code, z. B. "usd"
}
export type CheckoutStatus = "pending" | "succeeded" | "failed";
export interface CheckoutSession {
id: string;
skuId: string;
totalCents: number;
currency: string;
status: CheckoutStatus;
}
Hier ziehen wir in CheckoutSession explizit die Referenz auf skuId sowie feste Währung/Betrag mit. Das ist unser internes Modell; die reale Agentic Checkout Spec ist umfangreicher, aber die Grundidee ist dieselbe: Eine Session ist „wie viel, wofür und in welchem Status“.
Als Nächstes brauchen wir einen Bestelltyp:
export interface Order {
id: string;
userId: string;
skuId: string;
totalCents: number;
currency: string;
checkoutSessionId: string;
status: "awaiting_payment" | "paid" | "canceled" | "refunded";
}
Hier spürt man den Einfluss der allgemeinen Entitäten aus dem vorherigen Modul: intent, checkout_session, order. In unserem Lernprojekt klappen wir intent und order etwas zusammen, um die Entitäten nicht zu vervielfachen, behalten aber die Verbindung über checkoutSessionId.
5. Wie das GiftGenius‑Widget in die Commerce‑Welt hineinblickt
Wichtig: Das Widget selbst spricht nicht mit dem Zahlungsdienst und muss ACP‑Details nicht kennen; seine Rolle ist es, den Zustand anzuzeigen, der auf Backends berechnet und fixiert wurde.
Das einfachste sinnvolle Szenario: Nach einem erfolgreichen Kauf kann der Nutzer in den Chat zurückkehren und fragen: „Zeig mir meine letzten Bestellungen in GiftGenius“. GPT ruft ein MCP‑Tool wie get_user_orders auf, das Ihr Backend kontaktiert, und das Widget zeigt die Liste.
Stellen wir uns eine Next.js‑API‑Route vor, die die letzten Bestellungen zurückgibt (vereinfacht):
// app/api/orders/recent/route.ts
import { NextRequest, NextResponse } from "next/server";
import { getRecentOrdersForUser } from "@/lib/orders";
export async function GET(req: NextRequest) {
const userId = req.headers.get("x-giftgenius-user-id")!;
const orders = await getRecentOrdersForUser(userId);
return NextResponse.json({ orders });
}
Die Funktion getRecentOrdersForUser lebt bereits in Ihrer Commerce‑Schicht, arbeitet mit der DB und kennt die Bestellstruktur. Das Widget wiederum kann diese Route über window.fetch aufrufen (so haben wir es in den vorherigen Modulen bereits gemacht) und Kaufkarten anzeigen.
Die Kombination „MCP‑Tool → Ihre API → Bestell‑DB → Widget“ gibt dem Nutzer das Gefühl, dass die App ein „Gedächtnis“ für Käufe hat, obwohl das Widget lediglich den Backend‑Zustand darstellt.
6. Einfache Implementierung eines ACP‑Endpunkts im Next.js‑Stil
Skizzieren wir nun, wie eine Lern‑Implementierung eines der Schlüssel‑ACP‑Endpunkte aussehen kann – das Anlegen einer checkout_session. Laut Spezifikation ist der Vertrag recht umfangreich, für den Kurs genügt aber der Kern: Es kommt eine skuId, wir prüfen sie gegen Feed/DB, erzeugen eine Session und geben deren ID und Betrag zurück.
Nehmen wir die Route POST /api/checkout-sessions:
// app/api/checkout-sessions/route.ts
import { NextRequest, NextResponse } from "next/server";
import { findSkuById, createCheckoutSession } from "@/lib/checkout";
export async function POST(req: NextRequest) {
const body = await req.json(); // { skuId: string }
const sku = await findSkuById(body.skuId);
if (!sku) {
return NextResponse.json(
{ error: "SKU not found" },
{ status: 400 },
);
}
const session = await createCheckoutSession(sku);
return NextResponse.json({ session });
}
Hier gibt es einige wichtige Punkte.
Erstens: Genau hier gleicht die Commerce‑Schicht mit Product Feed/DB ab: findSkuById muss in dieselbe Quelle schauen, aus der der Feed erzeugt wird. Wir vertrauen nichts, was „aus der Luft“ kommt – weder von GPT noch vom Widget.
Zweitens: Wir geben nur zurück, was ChatGPT/der ACP‑Client braucht: Session‑ID, Betrag, Währung und Status (standardmäßig pending oder not_ready_for_payment, je nach gewählter Terminologie). In der realen ACP‑Spez gibt es mehr Felder, inklusive Informationen zu verfügbaren Zahlungsmethoden und Fulfillment, aber das Lernbeispiel konzentriert sich auf das initiale Anlegen der Session.
Drittens: Eine solche Route lässt sich gut mit Contract‑Tests absichern: Wenn sich morgen die Struktur des Product Feed ändert, sollten Tests für findSkuById und createCheckoutSession das früher auffangen, als ChatGPT Nutzern merkwürdige Fehler ausspielt.
7. Verbindung zwischen ACP‑Sessions und Zahlungsanbieter
Bisher haben wir den Zahlungsanbieter nicht angefasst. In der realen Integration passiert ungefähr Folgendes (vereinfachtes Szenario).
Zuerst ruft ChatGPT (über ACP) Ihr POST /checkout_sessions auf. Ihr Backend erstellt eine lokale Session in seiner DB. Wenn der Nutzer die Zahlung im Instant‑Checkout‑UI bestätigt, fordert die Plattform beim PSP einen delegierten Zahlungstoken (Shared Payment Token) für den konkreten Merchant und Betrag an. Dieser Token kommt bei Ihnen in der complete‑Anfrage an (oder einem ähnlichen Call gemäß Delegated Payment Spec).
Danach erzeugen Sie beim PSP eine Zahlung unter Verwendung des Tokens, ohne Zugriff auf echte Zahlungsdaten. Der PSP sendet einen Webhook zum Ergebnis; Sie aktualisieren den Status der Bestellung und/oder der Checkout‑Session.
In unserem Lerncode können wir diesen Schritt simulieren. Die Funktion completeCheckoutSession kann z. B. so aussehen:
// src/lib/checkout.ts
export async function completeCheckoutSession(sessionId: string, spt: string) {
// Hier würde in der Realität das PSP-API mit dem delegierten Token (SPT) aufgerufen
const paymentOk = await mockChargeWithToken(spt);
return paymentOk
? { status: "succeeded" as const }
: { status: "failed" as const };
}
Der PSP‑Aufruf und die Nutzung des Shared Payment Token sind Teil des Delegated Payment‑Standards, und die Funktion mockChargeWithToken ist unsere Lern‑Architekturschicht, die diese Spezifik veranschaulicht.
8. End‑to‑End‑Flow GiftGenius: von der Anfrage bis zum bezahlten Geschenk
Nun setzen wir alles als Abfolge von Schritten zusammen. Das ist die „produktive“ Geschichte von GiftGenius, für die wir die Schichten kombinieren. Es ist wichtig, zwei verschiedene Welten nicht zu vermischen, daher betrachten wir sie getrennt.
Schema A: ohne App, nur Product Feed + ACP
In diesem Szenario haben Sie einen Product Feed und ein ACP‑Backend, aber keine ChatGPT App und kein Widget. Das ist der klassische Instant‑Checkout‑Merchant.
Der Nutzer schreibt in ChatGPT etwas wie: „Finde ein digitales Geschenk bis 50 $.“ GPT nutzt Ihren Product Feed, um passende SKUs zu finden, und zeigt sie in seinem nativen UI als Shopping‑Karten an. Hier gibt es noch keinen React‑Code von Ihnen – die Karten rendert ChatGPT vollständig.
Der Nutzer klickt auf die Schaltfläche „Buy“ auf einer dieser Karten. Dieser Klick wird von ChatGPT selbst verarbeitet. Die Plattform:
- bildet line_items auf Basis des Product Feed;
- ruft Ihr POST /checkout_sessions gemäß Agentic Checkout Spec auf;
- zeigt dem Nutzer das Instant‑Checkout‑UI (Zahlmethode, Adresse usw.);
- erhält nach der Bestätigung den Shared Payment Token vom PSP und ruft Ihr .../complete auf;
- erhält von Ihnen den finalen Zustand der checkout_session und wartet ggf. auf den Webhook zur Bestellung.
Aus Sicht Ihres Codes laufen hier nur ACP‑Endpunkte und der Product Feed. Es gibt keinerlei Apps SDK, window.openai und Widget. Und das ist ein vollkommen valides, „reines“ ACP‑Merchant‑Szenario.
Schema B: mit ChatGPT App und GiftGenius‑Widget
Nun fügen wir obenauf die ChatGPT App und das GiftGenius‑Widget hinzu. Product Feed und ACP‑Backend bleiben unverändert: Sie liefern weiterhin Suche und Zahlung. Der Unterschied ist, dass wir nun ein eigenes UI und eigene Logikschritte innerhalb der App haben.
Stellen wir uns den Dialog vor: Der Nutzer schreibt in ChatGPT: „Finde ein Geschenk für Mama bis 50 $.“ GPT erkennt, dass es ein Commerce‑Request ist, und schlägt vor, die GiftGenius‑App zu verwenden. Das Widget stellt ein paar Rückfragen: Alter, Interessen, Land. Danach ruft GPT Ihr MCP‑Tool search_gifts mit Filtern auf, und der MCP‑Server greift auf den Katalog (DB oder vorbereiteten Index) zu, findet mehrere passende SKUs und gibt sie strukturiert zurück.
GPT übergibt diese Daten an das Widget, und das Widget zeigt seine eigenen, markentypischen Geschenk‑Karten (React‑Komponenten, Karussells usw.). Das ist nun Ihr Design und Ihr UX, nicht das Standard‑Shopping‑UI von ChatGPT.
Wenn der Nutzer im Widget auf „Kaufen“ klickt, passiert etwas anderes als in Schema A. Dieser Klick wird vom Widget verarbeitet:
- Das Widget versteht, welche SKU der Nutzer ausgewählt hat.
- Über die eigene API (z. B. POST /api/checkout-sessions) ruft es Ihr Backend auf, um eine checkout_session zu erstellen (oder die ID einer bereits vorbereiteten Session zu erhalten).
- Anschließend ruft das Widget eine Runtime‑Methode des Apps SDK auf, etwa:
// Siehe die aktuelle Methodensignatur in der Apps-SDK-Dokumentation await window.openai.requestCheckout({ checkoutSessionId: session.id, ... });Dieser Aufruf ist Initiative des Widgets. Für ChatGPT ist das das Signal: „Es ist Zeit, den Instant Checkout für diese checkout_session zu öffnen.“
Danach arbeitet die ChatGPT‑Plattform hinter den Kulissen sehr ähnlich wie in Schema A:
- zeigt dem Nutzer das native Instant‑Checkout‑UI;
- holt den Shared Payment Token beim PSP;
- ruft Ihren ACP‑Endpunkt zum Abschluss der Session auf (.../complete);
- ist an Empfang und Verarbeitung der Webhooks Ihres Backends beteiligt.
Das heißt, in Schema B startet das Widget den Checkout über das Apps SDK, und die Aufrufe per ACP (Erstellen/Abschließen der checkout_session) passieren entweder davor (wenn Sie die Session im Backend selbst anlegen) oder nach requestCheckout, aber stets serverseitig.
Das Widget kann parallel die Schritte „Kaufabwicklung“, Status und Bestell‑Preview anzeigen, basierend auf Ihrer API (/api/orders/...) und Ihren MCP‑Tools.
Als Diagramm sieht Schema B etwa so aus:
sequenceDiagram
participant User as Benutzer
participant GPT as ChatGPT / GPT
participant W as GiftGenius-Widget
participant MCP as MCP-Server
participant ACP as Commerce-Backend
participant PSP as Zahlungsanbieter
User->>GPT: „Finde ein Geschenk bis 50 $“
GPT->>MCP: search_gifts(...)
MCP-->>GPT: SKU-Liste
GPT->>W: Daten zum Rendern der Karten
User->>W: Klick auf „Kaufen“
W->>ACP: POST /api/checkout-sessions (skuId)
ACP-->>W: checkout_session (ID, Betrag, Währung)
W->>GPT: window.openai.requestCheckout({ checkoutSessionId })
GPT->>User: Instant-Checkout-UI
User->>GPT: Zahlungsbestätigung
GPT->>PSP: Anfrage auf Shared Payment Token
PSP-->>GPT: SPT
GPT->>ACP: complete(sessionId, SPT)
ACP->>PSP: charge(SPT)
PSP-->>ACP: Zahlungsergebnis
ACP->>GPT: Bestellstatus
GPT->>User: Meldung über erfolgreiche/fehlgeschlagene Zahlung
Der entscheidende Unterschied zu Schema A:
- In A rendert ChatGPT selbst Karten und „Buy“-Button und initiiert den ACP‑Aufruf direkt.
- In B rendert Ihr Widget Karten und den Button „Kaufen“ und ruft window.openai.requestCheckout(...) auf. Erst danach spricht ChatGPT unter der Haube mit Ihrem ACP‑Backend und dem PSP.
Insight
Im SDK schreibt ChatGPT, dass Bald Monetarisierung in Apps verfügbar sein wird. Genau so ist es. Widgets haben bereits Zugang zu einigen noch nicht angekündigten Methoden. Die interessanteste davon ist requestCheckout().
So sieht der Aufruf aus:
window.openai.requestCheckout({
id: "checkout_session_123",
payment_provider: {
merchant_id: "stripe",
supported_payment_methods: ["card"]
},
...
}
Er zeigt einen Dialog an, der dem Nutzer erlaubt, die Zahlung abzuschließen. Gestalten Sie Ihre Anwendung also so, als wäre die Monetarisierung bereits eingeschaltet: Wenn Sie fertig sind, wird es genau so sein.
9. Mini‑Umsetzung für den Kurs: monolithisches Backend
In den Architektur‑Modulen kam bereits die Frage auf: Alles als einen Service bauen oder sofort in MCP‑Server, Commerce‑Backend und einen separaten Service für die Zahlungsintegration aufteilen? Für Bildungszwecke reicht meist der „Fast‑Monolith“: ein Repository, ein Deploy, aber die Logik sauber auf Schichten verteilt.
Die Lernvariante GiftGenius kann so aussehen: eine Next.js‑App, in der:
- das Widget in app/widget/page.tsx lebt;
- die ACP‑Endpunkte in app/api/checkout-sessions und benachbarten Routen;
- die MCP‑Tools in app/api/mcp/route.ts oder einem eigenen Ordner;
- die Arbeit mit Bestellungen in src/lib/orders.ts, src/lib/checkout.ts und verwandten Modulen.
Physisch ist das ein Server (insbesondere in Dev/Staging), logisch denken Sie aber bereits in drei Rollen: UI (Widget), MCP (Tools/Ressourcen für GPT) und ACP (Commerce‑Backend).
Später, in den Produktions‑Modulen, sehen Sie, wie dieser „Monolith“ auf mehrere Services und Umgebungen verteilt wird und davor ein MCP‑Gateway erscheint. Aber bereits auf dem Niveau von Modul 14 liefert ein solcher „Monolith mit den richtigen Schichten“ eine sehr glaubwürdige Architektur.
10. Praxisaufgabe: Ihre Architektur rund um ACP
Damit das oben Beschriebene nicht Theorie bleibt, lohnt es sich, es jetzt auf Ihre Domäne anzuwenden. Im Rahmen der Vorlesung bieten sich zwei Mini‑Übungen an.
Erstens: Wählen Sie Ihr eigenes Szenario: SaaS‑Abo, Buchung, Essenslieferung, Online‑Kurse – jeder Use Case, in dem es ein Produkt/eine Dienstleistung, einen Preis und einen sinnvollen Checkout gibt. Erinnern Sie sich an das Phasenmodell: Discovery → Decision → Checkout → Post‑Payment.
Zweitens: Stützen Sie sich auf die GiftGenius‑Architektur und beschreiben Sie frei: Wie bauen Sie den Product Feed (wo leben SKUs und Preise, wer aktualisiert sie), wo implementieren Sie den ACP‑Vertrag (eigener Service oder Teil des bestehenden Backends), wie binden Sie den Zahlungsanbieter an und wie interagiert Ihr Widget (falls vorhanden) über MCP und Apps SDK mit all dem.
Es ist hilfreich, ausdrücklich festzuhalten, ob Ihr Projekt nur Schema A (Instant Checkout ohne App), nur Schema B (App + Widget) oder beide Szenarien gleichzeitig nutzt. Schon so ein textueller Architektur‑Entwurf reduziert das Risiko von Überraschungen in der realen Integration deutlich.
11. Typische Fehler bei der Integration von Product Feed, ACP und Widget
Fehler Nr. 1: Zwei unterschiedliche Kataloge – einer für Suche, einer für Checkout.
Mitunter baut das Team zuerst einen schnellen „Suchfeed“ für GPT (z. B. eine kleine JSON), und später separat eine Commerce‑DB für Bestellungen. Wenn sie nicht durch gemeinsame IDs und gemeinsame Update‑Logik verbunden sind, kann GPT Produkte vorschlagen, die nicht mehr kaufbar sind oder zum alten Preis. Der richtige Ansatz ist eine Single Source of Truth, aus der sowohl Product Feed als auch interne Tabellen für ACP‑Endpunkte erzeugt werden.
Fehler Nr. 2: Vertrauen in Daten, die von GPT oder dem Widget kommen.
Wenn in der checkout_session eine skuId und ein Preis ankommen, ist es verlockend, diesen Werten einfach zu glauben: „GPT wird schon nicht lügen.“ Doch das Modell kann kreativ werden oder SKUs verwechseln, und der Nutzer kann versuchen, die Anfrage zu manipulieren. Ohne Abgleich mit Product Feed/DB riskieren Sie, Falsches und zu falschen Preisen zu verkaufen. Jeder ACP‑Endpunkt sollte mit einer Validierung gegen den primären Katalogspeicher beginnen.
Fehler Nr. 3: Vermischung der Rollen von Widget und Commerce‑Backend.
Manchmal rufen Entwickler aus Gewohnheit direkt vom Frontend das Zahlungs‑SDK auf, erstellen Sessions in Stripe und verhalten sich insgesamt wie auf einer „normalen“ Website. Im Kontext von ChatGPT Apps bricht das das Sicherheitsmodell und widerspricht ACP: Der Zahlungs‑Flow muss über ChatGPT und Ihr Commerce‑Backend laufen, und das Widget soll nur den Zustand anzeigen und Ereignisse senden (wie requestCheckout). Wenn das Widget zu viel über den Zahlungskontext weiß, steigen Komplexität und Risiko.
Fehler Nr. 4: Übermäßige Vereinfachung des ACP‑Vertrags.
Im Lernbeispiel lassen wir bewusst nur skuId, Betrag und Status übrig, um nicht in Details zu versinken. Problematisch wird es, wenn ein solcher „Demo‑Vertrag“ unbemerkt in Produktion wandert. Plötzlich fehlen Felder für Adresse, Steuern, Versandarten, Promo‑Codes, und Sie „schrauben“ sie chaotisch dazu. Besser ist es, interne Modelle von Anfang an mit Reserve für reale Szenarien zu entwerfen, auch wenn ein Teil der Felder zunächst ungenutzt bleibt.
Fehler Nr. 5: Keine Verknüpfung zwischen Bestellungen und Nutzern.
Im Demo reicht es leicht, bei orderId und skuId stehenzubleiben, ohne daran zu denken, wie der Nutzer in einer Woche zurückkommt und fragt: „Zeig mir meine Käufe.“ Wenn man von Anfang an keine userId (oder einen anderen stabilen Identifikator) in Bestellung und Checkout‑Session anlegt, sind später Migrationen und Brücken nötig. Die Commerce‑Architektur rund um ChatGPT setzt fast immer voraus, dass GPT den aktuellen Dialog mit der Bestellhistorie verknüpfen kann – das sollte man früh bedenken.
Fehler Nr. 6: Unterschätzung der Bedeutung von Webhooks und Idempotenz.
In der Vorlesung erwähnen wir Webhooks nur, und tiefer gehen Sie in späteren Modulen darauf ein. Man denkt leicht: „Der Webhook kommt einmal, wir aktualisieren die Bestellung – fertig.“ In der Praxis wiederholen Zahlungsdienste gerne Ereignisse, und Netzwerke verlieren Antworten. Wenn Bestellungen und Checkout‑Sessions nicht idempotent (per checkoutSessionId oder paymentId) konzipiert sind, drohen doppelte Abbuchungen, Duplikatbestellungen und subtile Divergenzen zwischen PSP und Ihrer DB.
Fehler Nr. 7: Ignorieren von Einschränkungen und Richtlinien im Product Feed.
Im Eifer eines schnellen Demo‑Feeds vergisst man leicht Altersbeschränkungen, Verfügbarkeit nach Ländern, verbotene Kategorien und andere „Kleinigkeiten“. Dann schlägt GPT dem Nutzer fröhlich ein Produkt vor, das in seiner Region oder Altersgruppe nicht verkauft werden darf. Felder zu Policy und Einschränkungen sollten von Anfang an entworfen und gepflegt werden – auch wenn Sie derzeit nur harmlose digitale Geschenke verkaufen.
GO TO FULL VERSION