ACP / Instant Checkout: der Standard und seine Implementierung in ChatGPT

1. Warum ACP nötig ist und warum es nicht „nur noch eine REST‑API“ ist

Zynisch betrachtet wirkt ACP wie eine Sammlung gewöhnlicher HTTP‑Endpoints und JSON‑Strukturen: irgendein /checkout_sessions, irgendwelche Webhooks, irgendwelche Tokens. Schnell denkt man: „Okay, das ist nur eine weitere proprietäre API von irgendeiner Plattform.“ Doch die Idee von ACP geht tiefer.

ACP ist als offenes Protokoll für die Zusammenarbeit dreier Parteien gedacht: der KI‑Plattform (z. B. ChatGPT), Ihrem Commerce‑Backend und dem Zahlungsanbieter (PSP). Ziel ist es, zu standardisieren, wie Produkte und Preise beschrieben werden, wie die KI die Kaufabsicht des Nutzers mitteilt, wie eine Checkout‑Session entsteht, wie die Zahlung ausgeführt wird und wie alle Beteiligten den finalen Status erfahren.

Der Kernpunkt: Ein und dasselbe Merchant‑Backend, das ACP implementiert, kann potenziell nicht nur mit ChatGPT, sondern auch mit anderen LLM‑Plattformen arbeiten, die diesen Standard unterstützen. Sie schreiben also nicht „eine spezielle API für ChatGPT“, sondern implementieren ein Protokoll für Commerce‑Integrationen der nächsten Generation.

Instant Checkout in ChatGPT ist die erste größere Implementierung des ACP‑Standards. ChatGPT hält sich an dieses Protokoll, ruft Ihre ACP‑Endpoints auf und zeigt dem Nutzer ein ansprechendes UI an; die Spielregeln sind jedoch in den ACP‑Spezifikationen beschrieben und nicht als „GPT‑Magie“ in einer Blackbox versteckt.

2. Die drei Säulen von ACP: Product Feed, Agentic Checkout, Delegated Payment

ACP umfasst drei Hauptspezifikationen, auf die wir uns ständig beziehen werden:

Den Product Feed haben wir in früheren Vorlesungen bereits behandelt. Jetzt interessieren uns die letzten beiden Blöcke: Agentic Checkout und Delegated Payment.

Wichtig ist die Trennung von drei Ebenen:

1. Standard (SPEC). Offizielle Dokumente beschreiben, welche Felder und Endpoints existieren müssen, welche Status zulässig sind und welche Garantien Sie geben müssen.
2. Architektur‑Pattern (ARCH). Etwa die Entscheidung, SKU und Bestellungen in separaten Tabellen zu speichern, einen Service‑Wrapper um ACP zu legen oder eine Queue für Webhooks zu verwenden. Das sind Best Practices, aber nicht Teil des Standards.
3. Konkrete Implementierung (Beispiel GiftGenius). Das ist unser Übungsprojekt: Tabellenstruktur, konkrete TypeScript‑Typnamen, wie wir Bestellungen loggen usw. Das ist ein Beispiel, kein normatives Dokument.

Wir werden ständig betonen, wo die SPEC endet und Ihre Architektur beginnt – damit es nicht zu „Ich sah in der Vorlesung das Feld persona_tags und dachte, das sei Teil der offiziellen Spezifikation“ kommt.

3. Checkout‑Session von innen: Struktur und Status

Das zentrale Objekt der Agentic‑Checkout‑Spec ist die checkout_session in Ihrem Backend. Logisch ist sie der Zustand eines Kaufs: welche Artikel, zu welcher Summe, mit welchen Versandoptionen und in welchem Status sich der Zahlungsversuch gerade befindet.

Die Spezifikation beschreibt die Pflichtfelder von checkout_session ungefähr so (Formulierungen vereinfacht und teilweise gekürzt gegenüber dem Original):

• id – eine String‑ID der Session, die Sie generieren und zurückgeben. ChatGPT verwendet sie in allen folgenden Aufrufen.
• buyer – Informationen zum Käufer: Name, E‑Mail, Telefon, ggf. Adresse. In der echten Spezifikation ist dieses Objekt strukturiert, sodass PSP und Ihre Systeme es zuverlässig nutzen können.
• status – ein String‑Enum, der den aktuellen Kaufzustand widerspiegelt. Basisstatus:
  • not_ready_for_payment – es kann noch nicht gezahlt werden (z. B. weil Versandoptionen fehlen oder Steuern noch nicht berechnet sind).
  • ready_for_payment – alles ist bereit, der Zahlungstoken kann angefordert und Geld abgebucht werden.
  • completed – Zahlung erfolgreich, Bestellung erstellt.
  • canceled – Kauf storniert (durch den Nutzer oder aufgrund eines Fehlers).
• currency – Währungscode im ISO‑4217‑Format in Kleinbuchstaben ("usd", "eur" usw.).
• line_items – die Positionen im Warenkorb, jeweils mit eigenem SKU, Menge und berechnetem Preis.
• fulfillment_address – Lieferadresse (falls relevant).
• fulfillment_options und fulfillment_option_id – mögliche Versand‑/Fulfillment‑Optionen sowie die aktuell gewählte Option.
• totals – aggregierte Summen: Warenwert, Steuern, Versand, Gesamtsumme.
• order – Objekt, das die Bestellung beschreibt, die nach erfolgreichem Abschluss der Session erzeugt wird.
• messages – Liste von Nutzer‑Nachrichten, die ChatGPT dem Käufer zeigen kann, z. B. Hinweise oder Fehler.
• links – Liste von Links, z. B. auf Rückgabebedingungen, Privacy Policy und Terms of Service.

Wir müssen im Demo nicht alle Felder implementieren, aber die Idee ist wichtig: checkout_session ist „Historie und aktueller Zustand eines Kaufversuchs“, und ChatGPT erwartet darin alles, was für ein korrektes UX nötig ist.

Zur Vereinfachung führen wir in unserem Übungscode einen vereinfachten Typ ein:

// Vereinfachtes checkout_session-Modell für GiftGenius (nicht die vollständige SPEC)
type GGCheckoutStatus = 'not_ready_for_payment' | 'ready_for_payment' | 'completed' | 'canceled';

type GGLineItem = { skuId: string; quantity: number; total: number };

type GGCheckoutSession = {
  id: string;
  status: GGCheckoutStatus;
  currency: 'usd';
  lineItems: GGLineItem[];
  grandTotal: number;
};

Dieses Modell ist bewusst einfacher als die offizielle Spezifikation, eignet sich aber hervorragend für die Praxis: Status und Übergänge im Kopf behalten, ohne in hundert Feldern zu ertrinken.

4. Lebenszyklus der checkout_session

Die Agentic‑Checkout‑Spezifikation beschreibt mehrere Operationen auf der checkout_session. Vereinfacht sieht der Lebenszyklus so aus:

1. Session erstellen: POST /checkout_sessions.
2. Session aktualisieren: POST /checkout_sessions/{id}.
3. Session abschließen (complete): POST /checkout_sessions/{id}/complete.
4. (Manchmal) Stornierung: eigener Cancel‑Endpoint oder Wechsel auf canceled via Update.

Aus Sicht der Zustände kann man folgendes Diagramm zeichnen:

stateDiagram-v2
    [*] --> not_ready_for_payment
    not_ready_for_payment --> ready_for_payment: Versand/Steuern berechnen
Optionen wählen
    ready_for_payment --> completed: erfolgreicher POST /complete
    ready_for_payment --> canceled: Stornierung durch Nutzer oder Fehler
    not_ready_for_payment --> canceled: Fehler, inkonsistente Daten

Erstellung einer checkout_session beginnt üblicherweise im Zustand not_ready_for_payment oder direkt ready_for_payment, wenn bereits alles für die Zahlung bekannt ist (z. B. digitales Produkt ohne Versand und Steuern). Updates dienen dazu, Daten hinzuzufügen (Adresse, Gutscheine, Versandoption) und Summen neu zu berechnen. Abschluss ist der Moment, in dem Delegated Payment ins Spiel kommt und Geld tatsächlich abgebucht wird.

Wichtig ist die Rollentrennung:

• ChatGPT initiiert Erstellung, Updates und Abschluss der Session, basierend auf dem Dialog mit dem Nutzer.
• Ihr Backend (Merchant) ist für korrekte Business‑Logik verantwortlich: SKU‑Prüfung, Verfügbarkeit, Preis‑/Steuerberechnung, Statuswechsel, Bestellerzeugung.
• Der PSP (Stripe u. a.) führt die reale Zahlung durch und stellt den Shared Payment Token bereit, den der Merchant zum Abbuchen verwendet.

Gleich folgen konkrete HTTP‑Requests und kleine Codebeispiele, die wir auf diese Zustandslogik legen.

5. Erstellung der checkout_session: Was genau erwartet ChatGPT von uns?

Wenn ChatGPT (oder ein Agent) entschieden hat, dass der Nutzer wirklich etwas kaufen will, bildet es auf Basis des Product Feeds die Line Items: Liste der SKUs, Menge, angenommene Währung und ggf. Versandwünsche. Dann ruft es Ihren Endpoint POST /checkout_sessions auf.

Auf Merchant‑Seite ist jetzt Folgendes nötig:

1. Eingabedaten validieren: sicherstellen, dass alle SKUs existieren, verkauft werden dürfen und keine Policy verletzen (z. B. kein Alkohol für Minderjährige).
2. Preise und Steuern gemäß Ihren Regeln berechnen.
3. Versandoptionen (Fulfillment Options) vorbereiten, falls physische Ware.
4. Eine korrekte checkout_session mit Status und Summen zurückgeben.

Ein einfachster Express‑Handler für GiftGenius könnte so aussehen:

// Pseudocode: Erstellung einer vereinfachten checkout_session
app.post('/checkout_sessions', async (req, res) => {
  const items = req.body.lineItems as GGLineItem[];  // skuId + quantity
  const pricedItems = await priceItems(items);       // total für jedes SKU berechnen
  const grandTotal = sum(pricedItems.map(i => i.total));

  const session: GGCheckoutSession = {
    id: generateId(),
    status: 'ready_for_payment', // für digitale Geschenke kann man direkt zur Zahlung übergehen
    currency: 'usd',
    lineItems: pricedItems,
    grandTotal,
  };

  res.status(201).json(session);
});

Hier tun wir mehrere Dinge:

• Wir vertrauen den vom Client (ChatGPT) gelieferten Preisen nicht und berechnen sie nach unseren Daten neu – das ist für Commerce‑Sicherheit essenziell.
• Wir generieren unsere eigene id der Session (z. B. mit Präfix gg_chk_...).
• Wir geben den Status ready_for_payment zurück, wenn keine weiteren Schritte nötig sind (kein Versand, automatische Steuern, einfaches Modell).

In einem wirklich ACP‑konformen Backend würden Sie zusätzlich messages, links und ein zusammengesetztes Objekt totals zurückgeben sowie order (mindestens als Entwurf) befüllen, wie in der Spezifikation beschrieben.

6. Aktualisierung der checkout_session und Idempotenz

Nach dem Erstellen der Session kann ChatGPT den Nutzer um weitere Details bitten: Lieferadresse, Gutschein, andere Fulfillment‑Option. Sobald diese Daten vorliegen, ruft die Plattform POST /checkout_sessions/{id} auf, damit Sie neu kalkulieren.

Im Code ähnelt das stark der Erstellung, aber statt einer neuen Session erzeugen Sie:

• laden Sie die bestehende Session über die id;
• wenden Änderungen an (z. B. fulfillment_option_id ändern oder Rabatt hinzufügen);
• berechnen Summen neu;
• geben die aktualisierte checkout_session zurück.

Wichtig: Die Spezifikation erlaubt Wiederholungen von Requests (wegen Netzwerkausfällen oder Retries seitens ChatGPT). Daher – wie bereits in früheren Modulen zu Idempotenz bei Tools und Webhooks – empfiehlt es sich, den Header Idempotency-Key zu nutzen und Wiederholungen sauber zu verarbeiten.

Ein möglicher Update‑Handler könnte so aussehen:

app.post('/checkout_sessions/:id', async (req, res) => {
  const id = req.params.id;
  const key = req.header('Idempotency-Key'); // derselbe Key => derselbe Effekt
  const existing = await loadSessionWithIdempotency(id, key, req.body);

  // applyUpdates kann Preise, Versand usw. neu berechnen
  const updated = await applyUpdates(existing, req.body);
  await saveSession(updated, key);

  res.json(updated);
});

Hier folgen wir nicht strikt einer konkreten SPEC‑Struktur, sondern zeigen die Idee: Eingaben – Änderungen und ein idempotenter Key; Ausgabe – ein konsistenter Zustand der checkout_session. Wenn derselbe Request mit demselben Key kommt, müssen Sie dasselbe Ergebnis zurückgeben, ohne zusätzliche Bestellungen zu erzeugen oder Log‑Dubletten zu produzieren.

7. Abschluss der checkout_session und Delegated Payment: Wie der Shared Payment Token funktioniert

Der spannendste und nervenaufreibendste Moment ist der Abschluss der checkout_session, wenn Geld tatsächlich abgebucht wird. Hier kommt die zweite Spezifikation ins Spiel: Delegated Payment.

Die Idee von Delegated Payment

Der Nutzer gibt Zahlungsdaten in der ChatGPT‑Oberfläche ein oder wählt sie aus (Karte, Wallet, gespeicherte Zahlungsmethode). Die Plattform sendet diese Daten nicht direkt an Sie – stattdessen fordert sie beim PSP (z. B. Stripe) einen speziellen Token an, den Shared Payment Token (SPT), der:

• eindeutig mit Merchant und konkreter Session verknüpft ist;
• betrags‑ und zeitlich begrenzt ist;
• Ihre Systeme nicht mit der realen Kartennummer konfrontiert.

Am Ende ergibt sich folgendes Bild:

Dieses Design erspart dem Merchant die Speicherung von Zahlungsdaten und lässt ihn sich auf die Bestell‑Business‑Logik konzentrieren; Compliance‑Themen verbleiben bei PSP und Plattform.

Insight

Der Sinn des Shared Payment Token ist, die Kartendaten vor Ihrem Backend zu verbergen, während die Zahlung dennoch von Ihnen durchgeführt wird. Man kann ihn aber auch etwas anders betrachten.

Sie kennen sicher Situationen, in denen ein Shop oder Hotel zunächst Geld auf Ihrer Karte vorautorisiert (geblockt) und es später abbucht. Betrachten Sie den Shared Payment Token als einen Hold‑Token. ChatGPT hat den Betrag beim Nutzer blockiert, aber nicht abgebucht. Es übergibt Ihnen diesen Hold‑Token, und Sie können ihn nun an Stripe weiterreichen und den Betrag abbuchen.

Dabei gibt es zwei wichtige Nuancen:

• Hold‑Betrag und Abbuchungsbetrag sollten nicht stark voneinander abweichen, idealerweise sind sie identisch.
• Sie können über ChatGPT den ersten Monat eines Abos für $1 verkaufen und anschließend jeden Monat $49.99 abbuchen.

Anfrage POST /checkout_sessions/{id}/complete

Wenn der Nutzer im Instant Checkout auf die Bestätigung klickt, führt ChatGPT Folgendes aus:

1. Fordert beim PSP einen SPT an (z. B. über die Stripe‑ACP‑API).
2. Sendet diesen Token zusammen mit Käuferdaten an Ihr Backend via POST /checkout_sessions/{id}/complete.

Die Spezifikation beschreibt den Request‑Body ungefähr so (unten ein angepasster und verkürzter Auszug aus der offiziellen Dokumentation):

POST /checkout_sessions/checkout_session_123/complete

{
  "buyer": {
    "first_name": "John",
    "last_name": "Smith",
    "email": "johnsmith@mail.com"
  },
  "payment_data": {
    "token": "spt_123",
    "provider": "stripe"
  }
}

Ihr Backend sollte daraufhin:

1. Die checkout_session mit der ID checkout_session_123 finden.
2. Prüfen, ob der Status den Abschluss erlaubt (typischerweise ready_for_payment).
3. Beim PSP eine Zahlung erstellen, den Token spt_123 nutzen (abhängig vom PSP – bei Stripe ein bestimmter Endpoint und Payment‑Method‑Typ).
4. Die Bestätigung der Zahlung abwarten.
5. Die checkout_session auf completed setzen, eine Bestellung erzeugen und speichern, das Feld order in der Session befüllen.
6. Die aktuelle checkout_session in der Antwort zurückgeben.

In stark vereinfachtem TypeScript‑Pseudocode könnte das so aussehen:

app.post('/checkout_sessions/:id/complete', async (req, res) => {
  const { id } = req.params;
  const { buyer, payment_data } = req.body;
  const session = await loadSession(id);

  await chargeWithSharedToken(payment_data.token, session.grandTotal);
  const completed = await markSessionCompleted(session, buyer);

  res.json(completed);
});

In der Realität verbergen sich zwischen diesen Zeilen Fehlerbehandlung, Wiederholungslogik, Logging und die Integration in Ihr Bestellmodell.

Wenn etwas schiefgeht (z. B. Zahlung abgelehnt), sollten Sie eine checkout_session mit Status not_ready_for_payment oder canceled zurückgeben und messages so füllen, dass ChatGPT dem Nutzer erklären kann, was passiert ist.

8. Instant Checkout in ChatGPT: Wie alles zu einem Flow wird

Fügen wir die Teile nun zu einem durchgängigen Szenario „von der Absicht bis zur Zahlung“ in ChatGPT zusammen. Sie können die Vorlesung als „Dekodierung“ dessen sehen, was sich hinter dem Button „Kaufen“ im Widget verbirgt.

Vereinfachtes Szenario:

1. Der Nutzer schreibt: „Finde ein digitales Geschenk bis $50 und schließe den Kauf direkt ab.“
2. Ein Agent (oder die ChatGPT‑App selbst) nutzt den Product Feed, um geeignete SKUs im Budget zu finden.
3. ChatGPT zeigt im Chat mehrere Geschenk‑Karten (über Ihr GiftGenius‑Widget) und bietet eine Auswahl an.
4. Nach der Auswahl bildet ChatGPT die Line Items und ruft POST /checkout_sessions auf Ihrem ACP‑Backend auf, erhält eine checkout_session mit Summen und Status.
5. Im Instant‑Checkout‑UI sieht der Nutzer die Endsumme, den Artikelnamen, die Rückgabebedingungen und den Bestätigungsbutton.
6. Bei der Bestätigung holt ChatGPT beim PSP den Shared Payment Token und ruft POST /checkout_sessions/{id}/complete auf, wie oben beschrieben.
7. Ihr Backend führt die Zahlung aus, erzeugt die Bestellung, gibt die checkout_session mit Status completed zurück.
8. ChatGPT zeigt die Bestätigung, und Ihr Backend kann (per Webhooks gemäß Agentic‑Checkout‑Spec) ein Event an OpenAI senden, damit die Plattform über das Schicksal der Bestellung informiert ist.

Als Sequence‑Diagramm sieht das so aus:

sequenceDiagram
    actor U as Nutzer
    participant GPT as ChatGPT
    participant GG as GiftGenius ACP Backend
    participant PSP as Stripe (PSP)

    U->>GPT: Ich möchte ein Geschenk bis $50 und direkt hier kaufen
    GPT->>GG: POST /checkout_sessions (line_items)
    GG-->>GPT: checkout_session (ready_for_payment)
    GPT->>U: Zeigt Instant Checkout (Artikel, Preis, ToS)
    U->>GPT: Klickt auf „Zahlung bestätigen“
    GPT->>PSP: Fordert SPT für Betrag und Merchant an
    PSP-->>GPT: Shared Payment Token (spt_xxx)
    GPT->>GG: POST /checkout_sessions/{id}/complete (token + buyer)
    GG->>PSP: Zahlung mit SPT
    PSP-->>GG: Zahlung erfolgreich
    GG-->>GPT: checkout_session (completed + order)
    GPT-->>U: Zeigt Kaufbestätigung

In diesem Szenario tauchen nirgendwo „beliebige“ Datenbankaufrufe oder obskure interne Endpoints Ihres Systems auf. Alles fügt sich in den strikt beschriebenen ACP‑Vertrag, in dem jeder Beteiligte seine Rolle kennt.

9. Mini‑Praxis: vereinfachtes ACP‑Backend für GiftGenius

Damit diese Vorlesung nicht reine Theorie bleibt, ist es wichtig, die Implementierung der ACP‑Schicht für unser Übungsprojekt mental „durchzuspielen“.

Stellen Sie sich vor, GiftGenius hätte bereits:

• Eine SKU‑ und Preis‑Datenbasis, aus der wir den Product Feed erzeugen (das haben wir in früheren Vorlesungen modelliert).
• Ein einfaches Bestellmodell: Tabelle orders mit Feldern id, userId, skuId, amount, currency, status, createdAt.
• Ein ChatGPT‑App‑Interface und eine MCP‑Schicht, die Geschenke empfehlen kann (haben wir in früheren Kursmodulen aufgebaut).

Ihre Aufgabe ist nun, einen kleinen zusätzlichen Service gg-acp hinzuzufügen:

• Endpoint POST /checkout_sessions:
  • Nimmt Liste der SKUs und Mengen an.
  • Berechnet Summen anhand Ihrer Datenbank.
  • Erzeugt eine Entwurfsbestellung (z. B. mit Status pending) und eine checkout_session mit Status ready_for_payment.
  • Gibt die checkout_session zurück.
• Endpoint POST /checkout_sessions/{id}:
  • Findet Session und Bestellung.
  • Wendet Änderungen an (z. B. Unterstützung eines Promo‑Codes, der die Endsumme reduziert).
  • Gibt die aktualisierte checkout_session zurück.
• Endpoint POST /checkout_sessions/{id}/complete:
  • Empfängt SPT, Betrag und Käuferdaten.
  • Kann in der Demo die Bestellung einfach als „bezahlt“ markieren, ohne echten Integrationsaufruf zum PSP (oder Sie simulieren Stripe).
  • Aktualisiert die checkout_session auf completed und verknüpft sie mit order_id.

Diesen Service können Sie in einer kleinen Node/Express‑App oder in Next.js‑App‑Router‑Endpoints implementieren. Wichtig ist, den Vertrag bei Format und Status einzuhalten, selbst wenn Sie die Zahlung nur emulieren.

Ein mögliches Bestellmodell in TypeScript könnte so aussehen:

// Vereinfachtes Bestellmodell von GiftGenius
type GGOrderStatus = 'pending' | 'paid' | 'canceled';

type GGOrder = {
  id: string;
  userId: string;
  skuId: string;
  amount: number;
  currency: 'usd';
  status: GGOrderStatus;
};

In Produktion kommen darauf Verknüpfungen mit Ihrem Auth/Identity (um zu wissen, welcher Nutzer der Chat ist), Webhooks zu OpenAI und komplexere Rückgabe‑Szenarien. Als Übungsschritt in dieser Vorlesung genügt es aber, sicher den Loop zu beherrschen: Session erstellen → aktualisieren → abschließen – ohne dabei Geld oder Verstand zu verlieren.

10. Typische Fehler bei der Gestaltung von ACP / Instant Checkout

Fehler Nr. 1: Rollenmischung („ChatGPT ist mein Shop“).
Manche Entwickler sehen gedanklich ChatGPT als „zentrales System der Wahrheit“ und versuchen, den Business‑Status der Bestellung auf der Plattform zu speichern: „Dort gibt es doch die checkout_session, also lese ich die Bestellhistorie aus OpenAI.“ Das führt ins Nichts. Die checkout_session ist ein Protokollobjekt, nicht die Quelle der Wahrheit für Bestellungen. Die Quelle der Wahrheit ist Ihr Commerce‑Backend: Dort müssen Bestellungen, Status, Rückgaben und Reports leben. ChatGPT ist in diesem Schema lediglich ein vertrauenswürdiges „Chat‑Frontend“.

Fehler Nr. 2: Vertrauen in Eingabepreise von ChatGPT.
Man könnte denken: „Der Agent hat SKUs bereits ausgewählt und sogar die Summe berechnet – nehmen wir die Summe einfach und buchen ab.“ So geht es nicht. Die Eingaben von ChatGPT (Line Items, angenommene Preise) sind als Vorschlag zu verstehen, nicht als Anweisung. Ihr Backend muss SKUs, Preise, Verfügbarkeit, Rabattfähigkeit usw. selbst prüfen, anhand des Product Feeds und Ihrer Datenbank. Andernfalls entstehen lustige Bugs der Art „Nutzer kaufte für $0.01, weil das Modell gerundet hat“.

Fehler Nr. 3: Ignorieren von Status und Zustandsmaschine.
In frühen Prototypen sieht man oft „löchrige“ Implementierungen: Session‑Status ist immer completed oder einfach ok, und Abweichungen vom tatsächlichen Zahlungszustand werden kaschiert. Ergebnis: ChatGPT kann dem Nutzer nicht korrekt anzeigen, was passiert – Zahlung unterwegs, bereits abgeschlossen oder storniert. Zuverlässiger ist es, die Zustandsmaschine not_ready_for_payment → ready_for_payment → completed/canceled ehrlich zu implementieren und den realen Status aus dem Backend zurückzugeben, statt ad‑hoc‑Felder zu erfinden.

Fehler Nr. 4: Den Shared Payment Token als „Mehrweg‑Karte“ verwenden.
Ein SPT ist per Design ein einmaliger oder streng begrenzter Token: Er ist an eine konkrete Operation, einen Betrag und einen Merchant gebunden. Ihn „auf Vorrat“ zu cachen oder für einen anderen Kauf wiederzuverwenden, ist eine schlechte Idee. Im besten Fall lehnt der PSP den zweiten Versuch ab; im schlimmsten Fall verwirren Sie Zahlungs‑ und Bestellbuchhaltung. Für jedes checkout_session.complete braucht es einen frischen Token; wenn die Zahlung fehlschlägt, muss ein neuer angefordert werden.

Fehler Nr. 5: Fehlende Idempotenz bei /checkout_sessions und Webhooks.
In realen Netzen können Requests doppelt ankommen: ChatGPT kann POST /checkout_sessions nach einem Timeout wiederholen, der PSP kann nach einem temporären Fehler einen Webhook erneut senden. Wenn Ihre Implementierung jedes Mal eine neue Bestellung und einen neuen Datensatz erzeugt, erhalten Sie schnell Chaos: doppelte Abbuchungen, Bestell‑Duplikate und seltsame Abweichungen zwischen Systemen. Nutzung von Idempotency-Key, Wiederholungsprüfung und das Speichern früherer Ergebnisse sind kein „optional nettes Tuning“, sondern notwendige Elemente einer robusten ACP‑Integration.

Fehler Nr. 6: Die Verbindung zum Product Feed vergessen.
Manchmal wird die ACP‑Schicht „im Vakuum“ entworfen: SKUs und Preise stammen aus internen Tabellen, die nicht dem entsprechen, was im Product Feed landet. Ergebnis: ChatGPT zeigt dem Nutzer das eine (laut Feed), im Checkout über ACP fließt aber etwas anderes. Um solche Überraschungen zu vermeiden, muss Ihr SKU‑ und Preis‑Modell einheitlich sein: Feed, ACP‑Backend und interne Datenbank müssen auf dieselbe Quelle der Wahrheit schauen, auch wenn es darüber unterschiedliche Projektionen und Caches gibt.