--- title: "Agentic Commerce: MCP, OAuth und Stripe Checkout" canonical: "https://pascalebeier.de/agentic-commerce-mcp-stripe-checkout" pubDate: "2026-08-11T18:30:00.000Z" author: Pascale Beier description: "Ein Praxisbericht über Discovery, OAuth, Buyer Confirmation, Idempotency, Stripe Checkout und Webhooks für kaufende AI Agents." tags: [agentic commerce, mcp, stripe checkout, ai agents, a2a, oauth] categories: [AI Engineering] --- Ein AI Agent kann heute Produkte finden, Preise vergleichen und einen Checkout vorbereiten. Die schwierige Frage beginnt einen Schritt später: **Wie verhindert man, dass aus einer Empfehlung unbeabsichtigt eine kostenpflichtige Bestellung wird?** Meine kurze Antwort nach dem Aufbau eines funktionierenden Agent-Checkouts: Ein `llms.txt` oder eine OpenAPI-Datei macht noch keinen Agent-native Shop. Es braucht einen durchgängigen Vertrag aus Discovery, klar getrennten Read- und Write-Aktionen, expliziter Buyer Confirmation, Idempotency, einem sicheren Zahlungsdienst und einem verifizierten Fulfillment-Signal. Ich habe diesen Vertrag für die Sponsoring-Plätze auf [kannkidas.de](https://kannkidas.de/) umgesetzt. Die Seite veröffentlicht mehr als 100 deutschsprachige Build-or-buy-Prüfberichte. Menschen können einen festen Sponsorplatz buchen; AI Agents können Verfügbarkeit prüfen und nach ausdrücklicher Bestätigung einen Stripe Checkout erstellen. ## Was bedeutet Agentic Commerce in diesem Beispiel? Agentic Commerce bedeutet hier nicht, dass ein Agent frei über ein Budget verfügt. Der Agent kann einen Kaufprozess technisch bedienen, aber die kostenpflichtige Aktion bleibt an eine konkrete Bestätigung gebunden. Der Ablauf ist bewusst unspektakulär: 1. Der Agent entdeckt die verfügbaren Interfaces. 2. Er liest den Live-Status der zehn Sponsorplätze. 3. Er nennt Platz, Nettopreis und Laufzeit. 4. Der Käufer bestätigt genau dieses Angebot. 5. Erst dann darf der Agent einen Stripe Hosted Checkout erstellen. 6. Eine Buchung gilt erst nach dem signierten Stripe Webhook als bezahlt. Diese Trennung ist wichtiger als die Wahl eines einzelnen Protokolls. ## 1. Discovery muss für Menschen und Agents lesbar sein Die zentrale Seite [kannkidas.de/agents/](https://kannkidas.de/agents/) verlinkt die verfügbaren Formate an einer Stelle. Dazu gehören unter anderem: - [`llms.txt`](https://kannkidas.de/llms.txt) als kuratierter Inhaltsindex, - [`AGENTS.md`](https://kannkidas.de/AGENTS.md) mit Quellenregeln und Kauf-Guardrails, - die [OpenAPI-Beschreibung](https://kannkidas.de/openapi.json), - eine [MCP Server Card](https://kannkidas.de/.well-known/mcp/server-card.json), - die [A2A Agent Card](https://kannkidas.de/.well-known/agent-card.json) und - die [OAuth-Metadaten](https://kannkidas.de/.well-known/oauth-authorization-server). Die Dokumente erfüllen verschiedene Aufgaben. `llms.txt` hilft beim Verstehen der Inhalte. OpenAPI beschreibt HTTP-Requests. Die Server Cards unterstützen Discovery. Keines dieser Formate ersetzt die Autorisierung der eigentlichen Aktion. Das [Model Context Protocol](https://modelcontextprotocol.io/specification/) standardisiert die Verbindung zwischen AI-Anwendungen und externen Tools oder Datenquellen. Die öffentliche MCP Registry verwendet dafür ein eigenes [`server.json`-Format](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/server-json/generic-server-json.md). Eine proprietäre Manifest-Datei mit ähnlichem Namen ist nicht automatisch Registry-kompatibel. ## 2. Read und Write brauchen unterschiedliche Verträge Die Verfügbarkeit eines Sponsorplatzes ist öffentlich und ungefährlich. Sie lässt sich über die [Slots API](https://kannkidas.de/api/slots), MCP oder A2A lesen. Der Checkout verändert dagegen Zustand: Er reserviert einen Platz und erzeugt eine Stripe Session. Deshalb gelten zwei getrennte Regeln: | Aktion | Zugriff | Ergebnis | | ------------------- | ------------------------------------------------------ | ---------------------------------------------- | | Sponsorplätze lesen | öffentlich, Read-only | aktueller Status ohne Reservierungszusage | | Checkout erstellen | OAuth Write-Scope, Buyer Confirmation, Idempotency-Key | zeitlich begrenzte Reservierung und Stripe URL | Der A2A-Endpunkt bleibt in der aktuellen Version absichtlich Read-only. Die A2A Agent Card verspricht deshalb auch keine Checkout-Capability. Ein Agent kann für den Kauf den dokumentierten MCP- oder HTTP-Weg verwenden. Das ist weniger spektakulär als eine einzige universelle Agent-Route, aber leichter zu prüfen: Die öffentliche Beschreibung darf nie mehr versprechen als der Handler tatsächlich ausführt. ## 3. Buyer Confirmation muss der Server erzwingen Eine Bestätigung nur im Prompt oder im MCP Client ist keine ausreichende Guardrail. Ein anderer OAuth Client könnte den HTTP-Endpunkt direkt ansprechen und die UI-Prüfung umgehen. Darum verlangt der Purchase-Endpunkt serverseitig ein explizites Feld wie: ```json { "slot_id": "P03", "buyer_confirmed": true } ``` Vor der Bestätigung muss der Agent mindestens das konkrete Angebot nennen: Sponsorplatz, 990 Euro netto und 30 Tage Laufzeit. Eine allgemeine Formulierung wie „du kannst fortfahren“ ist für eine kostenpflichtige Aktion zu ungenau. Die Bestätigung autorisiert außerdem nicht alle späteren Änderungen. Ändern sich Platz, Preis oder Laufzeit, muss der Käufer erneut entscheiden. ## 4. Idempotency verhindert doppelte Checkouts Agents und verteilte Systeme wiederholen Requests. Ein Timeout bedeutet nicht, dass der erste Versuch fehlgeschlagen ist. Ohne Idempotency kann ein Retry zwei Reservierungen oder zwei Checkout Sessions erzeugen. Jeder mutierende Request erhält deshalb einen stabilen `Idempotency-Key`. Derselbe fachliche Kaufversuch mit demselben Key liefert dasselbe Ergebnis; eine neue Kaufentscheidung bekommt einen neuen Key. Stripe unterstützt [Idempotent Requests](https://docs.stripe.com/api/idempotent_requests) ebenfalls. Sinnvoll ist die Absicherung auf beiden Ebenen: im eigenen Purchase-Endpunkt und beim Aufruf der Stripe API. ## 5. Zahlungsdaten gehören in Stripe Hosted Checkout Der Agent, der MCP Server und kannkidas.de benötigen keine Kartendaten. Der Checkout-Endpunkt gibt eine Stripe URL zurück. Kontakt-, Steuer- und Zahlungsdaten werden ausschließlich auf der von Stripe gehosteten Seite erfasst. Die Redirect-Seite nach dem Checkout ist dabei kein Zahlungsbeleg. Browser-Tabs werden geschlossen, Requests wiederholt und Redirect-URLs manuell geöffnet. Verlässlich ist das serverseitige Ereignis. Stripe empfiehlt für das Fulfillment die Verarbeitung von [Checkout-Webhooks](https://docs.stripe.com/checkout/fulfillment). Der Webhook wird mit dem Stripe Signing Secret geprüft. Erst ein verifiziertes `checkout.session.completed` mit bezahltem Status macht aus einer Reservierung eine bezahlte Buchung. Danach können interne Benachrichtigung und manuelle Freigabe der Werbemittel folgen. ## Der vollständige Ablauf ```text Discovery -> Live-Verfügbarkeit lesen -> konkretes Angebot anzeigen -> Buyer Confirmation -> OAuth Write-Scope + Idempotency-Key -> Stripe Hosted Checkout -> signierten Webhook prüfen -> Buchung intern melden und Werbemittel prüfen ``` Jede Stufe hat eine eigene Verantwortung. Wer sie in einem einzigen Tool-Call versteckt, macht Fehlerzustände und Autorisierung schwerer nachvollziehbar. ## Was ich bewusst noch nicht behaupte Die Implementierung ist derzeit kein vollständiger [Universal Commerce Protocol](https://ucp.dev/)-Merchant und kein vollständiger ACP-Shop. Es gibt einen echten, bezahlbaren Sponsoring-Checkout für Agents, aber noch keinen standardisierten Produktkatalog, Cart-Lifecycle oder Order-Management-Vertrag dieser Commerce-Protokolle. Diese Abgrenzung ist wichtig. Agent- und MCP-Verzeichnisse schaffen nur dann Vertrauen, wenn Capability, Endpoint und tatsächliches Verhalten übereinstimmen. ## Checkliste für einen Agent-native Checkout - Gibt es eine stabile, öffentliche Discovery-Seite? - Sind Read- und Write-Aktionen getrennt beschrieben? - Ist der kleinste OAuth Scope der Default? - Erzwingt der Server die Buyer Confirmation selbst? - Bindet die Bestätigung Preis, Produkt und Laufzeit ein? - Sind mutierende Requests idempotent? - Bleiben Zahlungsdaten beim Payment Provider? - Wird Zahlung ausschließlich über einen signierten Webhook bestätigt? - Existiert ein verständlicher Fehler- und Retry-Pfad? - Stimmen Agent Card, OpenAPI und reale Handler überein? Wer den aktuellen Stand prüfen will, kann mit der [Agent-Zentrale](https://kannkidas.de/agents/) oder der öffentlichen [Slots API](https://kannkidas.de/api/slots) beginnen. Beides funktioniert ohne Account und ohne einen Kauf auszulösen.