Agentic Checkout: KI-gestützter Checkout

TL;DR — Agentic Checkout ist der Teil des KI-Shoppings, der sagt: „Kauf das für mich.“ Wenn ein KI-Assistent ein Produkt findet und den Kauf für Sie abschließt, ist dieser letzte Transaktionsschritt der Agentic Checkout. In OpenAIs Ablauf für delegierte Zahlungen verwendet der Agent ein begrenztes Zahlungs-Token statt einer echten Kartennummer. Bei riskanten Schritten wie Login oder zusätzlicher Prüfung stoppt er und übergibt die Kontrolle an einen Menschen. Agentic Checkout ist ein Baustein der größeren Protokolle ACP und UCP, aber keine eigenständige Lösung.

Was Agentic Checkout ist

Beim „KI-Shopping“ geht es meist um die Produktsuche (Discovery): Sie bitten einen Assistenten, etwas zu finden; er liest die Produkt-Feeds von Händlern und schlägt Optionen vor. Agentic Checkout ist der Schritt danach — der Teil, in dem der Agent tatsächlich die Bestellung erstellt, eine Versandoption auswählt, Steuern und Versandkosten ermittelt, die Zahlung weitergibt und den Kauf abschließt.

Das Schlüsselwort ist Schritt. Agentic Checkout ist kein eigenes Produkt und kein eigenes Unternehmen. Es ist die Fähigkeit zum Transaktionsabschluss, die in den beiden großen Standards für agentischen Handel steckt: dem Agentic Commerce Protocol (ACP) von OpenAI und Stripe sowie dem Universal Commerce Protocol (UCP) von Google und Shopify. Die Geschwisterartikel behandeln diese Standards im Überblick; diese Seite konzentriert sich vollständig auf die Mechanik des Checkouts.

Drei häufige Irrtümer

• „Die KI kauft völlig ohne Menschen.“ Nicht ganz. Beide Protokolle haben einen eingebauten Schritt „stoppen und einen Menschen fragen“ — etwa für Login, zusätzliche Kartenprüfung oder Bestätigung. Ein vollständig autonomer Checkout ist nicht die Art von Ablauf, für die diese Spezifikationen gebaut sind.
• „Die KI sieht meine Kreditkarte.“ Nein. Die Zahlung wird als begrenztes Token übergeben — ein Stellvertreter, der an einen Händler, einen Betrag und ein Zeitfenster gebunden ist und nur einmal verwendet werden kann. Die echte Kartennummer erreicht den Agenten nie.
• „Das ist schon normal — die meisten Shops können das.“ Ebenfalls nein. Mitte 2026 steht die Entwicklung noch am Anfang: Vor OpenAIs Rücknahme der vollständig im Chat ausgeführten Version im März 2026 waren nur etwa ein Dutzend Shopify-Shops mit ChatGPT-Checkout live.

Wer ist verantwortlich, wenn etwas schiefgeht?

Der Shop, bei dem Sie gekauft haben, bleibt der Shop — er ist der Merchant of Record, also der rechtlich verantwortliche Händler. Er bearbeitet Bestellung, Erstattungen und Streitfälle wie bei einem normalen Onlinekauf. Die wirklich schwierige, noch nicht vollständig gelöste Frage ist, was bei einem angefochtenen Umsatz passiert, wenn der „Käufer“ ein KI-Agent war. Mehr dazu auf der Registerkarte Fortgeschritten.

Möchten Sie die tatsächliche Zustandsmaschine, die Begrenzung der Zahlungs-Tokens, die Stellen für menschliche Eingriffe und die Tests sehen, die Händler vor der Aktivierung durchführen müssen? Wechseln Sie zur Registerkarte Fortgeschritten.

TL;DR — Agentic Checkout ist die Fähigkeit zum Transaktionsabschluss im agentischen Handel: eine Checkout-Sitzung erstellen, aktualisieren, abschließen oder abbrechen, die Zahlung delegieren und die Bestellung bestätigen. Er ist ein Baustein von ACP und von UCP, kein eigenständiges Protokoll. Das technische Rückgrat ist eine Zustandsmaschine: ACP führt eine Sitzung über not_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required, falls nötig) → completed; UCP bildet dies mit incomplete → requires_escalation → ready_for_complete ab. Die Eskalationsstatus bilden die vorgesehene Schnittstelle für menschliche Eingriffe. Zahlungsdelegation verwendet begrenzte Tokens — händlergebunden, betragsbegrenzt, zeitlich befristet und einmalig — sodass der Agent keine echte Karte besitzt. Bestellbestätigung erfolgt per Push: Händler senden HMAC-signierte Webhooks mit dem vollständigen Objekt. Der Händler bleibt Merchant of Record; Abrechnung, Erstattungen und Chargebacks liegen bei ihm und seinem PSP. Das Belegsystem für Chargebacks ist Mitte 2026 jedoch weiterhin offen. Bauen und testen Sie idempotenzsichere Wiederholungen, Webhook-Signaturprüfung und Eskalationspfade, bevor Sie den Ablauf aktivieren.

Der Transaktionsschritt, nicht das ganze Protokoll

Agentic Checkout ist eine einzelne Fähigkeit. In ACP ist er buchstäblich der Block Agentic Checkout, einer von fünf Blöcken neben Product Feed, Delegate Payment, Delegate Authentication und Orders/Webhooks. In UCP ist er die Checkout-Fähigkeit innerhalb einer breiteren, über Fähigkeiten ausgehandelten Spezifikation. Die Geschwisterartikel zu ACP und UCP behandeln Protokollumfeld und Geschäftskontext — Feed-Qualität, das /.well-known/ucp-Profil und die Folgen des Kurswechsels im März 2026 für die Produktsuche. Diese Seite bleibt bei der Abwicklung der Transaktion: Sitzungslebenszyklus, Zahlungsdelegation, menschliche Eingriffe, Bestellbestätigung und Haftung.

Eine Perspektive aus dem ACP-Geschwisterartikel, die wir nicht erneut herleiten müssen: Agenten handeln gegen Feeds und APIs, nicht gegen Ihr gecrawltes HTML. Optimiert wird hier also die Checkout-Zuverlässigkeit, nicht der Seitentext.

Die Zustandsmaschine der Checkout-Sitzung

Das wichtigste Unterscheidungsmerkmal von Agentic Checkout — und das, was viele Erklärungen auslassen — ist: Ein Checkout ist eine Sitzung mit einem Status, und dieser Status bewegt sich durch eine definierte Maschine.

Die ACP-Checkout-Referenz führt das vollständige Status-Enum auf: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress und expired. Der Erfolgsweg ist kurz — not_ready_for_payment → ready_for_payment → in_progress → completed; der andere Endstatus ist canceled. Nach den ACP-Lebenszykluskonzepten wechselt eine Sitzung zu ready_for_payment, sobald eine erforderliche Fulfillment-Option vorhanden ist; eine fehlgeschlagene Zahlung kann sie für einen erneuten Versuch zurück auf ready_for_payment setzen.

Interessant sind die Status, die nicht zum Erfolgsweg gehören:

• requires_escalation / authentication_required — der Agent kann nicht allein fortfahren; ein Mensch oder eine zusätzliche Prüfung ist nötig (siehe nächster Abschnitt).
• pending_approval — wartet auf eine Freigabe, etwa die Genehmigung einer B2B-Bestellung.
• expired — die Sitzung ist abgelaufen (CheckoutSession enthält expires_at).

UCP verwendet im Kern dasselbe Design: incomplete → requires_escalation → ready_for_complete; bei requires_escalation übernimmt der Käufer über eine continue_url (siehe den UCP-Geschwisterartikel). Zwei getrennte Protokolle, ein konvergentes Muster: Ein Checkout kann nicht immer ohne Unterbrechung und Rückfrage an einen Menschen abgeschlossen werden. Das ist keine nachträglich angesetzte Einschränkung, sondern die Grundform des Designs.

Eine praktische Notiz für die ACP-Implementierung: Eine fehlerhafte Anfrage gibt ein HTTP-Fehlerobjekt zurück (type ist invalid_request, request_not_idempotent, processing_error oder service_unavailable). Ein Business-Logic-Problem in einer ansonsten gültigen Sitzung erscheint dagegen als MessageError-Objekt im Array messages[], nicht als HTTP-Fehler. Sie müssen beide Fälle behandeln; in frühen Integrationen werden sie leicht verwechselt.

So funktioniert die Zahlungsdelegation

Der Sinn der Zahlungsdelegationsschicht ist, dass Rohdaten der Karte den Agenten nie erreichen. Statt dem Agenten eine Kartennummer zu übergeben, werden die Zahlungsdaten der kaufenden Person in ein begrenztes Token umgewandelt.

Nach OpenAIs Spezifikation für delegierte Zahlungen werden die Nutzdaten direkt an den PSP oder Vault des Händlers gesendet; dieser gibt ein Zahlungs-Token zurück, das außerhalb des PCI-Umfangs auf die delegierte Zahlung begrenzt ist. Das Token ist in vier Dimensionen beschränkt:

• reason — derzeit "one_time": einmalige Verwendung.
• max_amount — begrenzt die Belastung auf die Checkout-Summe; das Token kann nicht für einen höheren Betrag verwendet werden.
• expires_at (RFC 3339) — das Token hat einen festen Ablaufzeitpunkt.
• merchant_id + checkout_session_id — an einen Händler und eine Sitzung gebunden.

Ein delegiertes Token ist also händlergebunden, betragsbegrenzt, zeitlich befristet und einmalig. So kann ein Agent „Geld ausgeben“, ohne dass ihm ein wiederverwendbares Kartenmerkmal anvertraut wird. Auf ACP-Seite wird Stripes Shared Payment Token als erste mit der Delegated Payment Spec kompatible Implementierung beschrieben; weitere PSPs sollen folgen. UCP verwendet ein paralleles entkoppeltes Modell, das Zahlungs-instrumente von Handlern trennt (siehe den UCP-Geschwisterartikel).

Der PCI-Umfang ist hier eine echte Architekturentscheidung. OpenAIs Spezifikation sagt ausdrücklich, dass eine direkte Integration der Delegated Payment Spec die direkte Verarbeitung von Karteninhaberdaten einschließt und den PCI-Umfang beeinflussen kann; für die direkte Integration ist PCI DSS Level 1 erforderlich. Für die meisten Händler ist der tokenisierte Weg — Netzwerk-Tokens oder ein PSP, der die Delegation übernimmt — der beste Weg, Karteninhaberdaten aus der eigenen Umgebung herauszuhalten. Die Entscheidung zwischen „CHD selbst verarbeiten“ und „den PSP tokenisieren lassen“ ist die erste Architekturentscheidung; der Entscheidungsbaum führt hindurch.

Wo ein Mensch noch eingreifen muss

„Der Käufer autorisiert es weiterhin“ stimmt, ist aber zu vage. Die Auslöser auf Protokollebene sind konkret; wer sie benennt, kann die Übergabe gestalten, statt in einer Sackgasse zu landen:

• 3-D Secure / Step-up. ACP modelliert dies mit InterventionCapabilities (unterstützte Typen sind 3ds und address_verification), einer enforcement-Stufe (always / conditional / optional) und einem display_context (native / webview / modal / redirect). Das Ergebnis kommt als AuthenticationResult mit Werten wie authenticated, denied, rejected, abandoned, canceled oder not_supported zurück.
• requires_escalation / authentication_required. Diese Sitzungsstatus sagen: „Ich brauche einen Menschen oder eine zusätzliche Prüfung, bevor ich fortfahren kann.“
• B2B approval_required. Das Objekt PaymentData enthält B2B-Felder (purchase_order_number, payment_terms, due_date, approval_required) — Agentic Checkout gilt nicht nur für DTC.
• UCP-Übergabe über continue_url. UCP stellt bei requires_escalation eine continue_url bereit, über die der Käufer Login, Bestätigung oder Altersprüfung selbst abschließt. Dieselbe Nahtstelle, ein anderes Protokoll.

Die Schlussfolgerung: Eine Transaktion, die sauber eskaliert, ist viel besser als eine, die still endet. Gestalten Sie Eskalationspfade als feste Bestandteile des Ablaufs, nicht als Fehlerfälle.

Bestellbestätigung ist ein Push, kein Pull

Hier lassen viele konkurrierende Erklärungen ein wichtiges Detail aus. Nach dem Kauf fragt die Agentenplattform nicht ständig Ihre API nach dem Bestellstatus ab. Der Händler sendet signierte Webhooks.

Nach der ACP-Webhook-Referenz senden Händler Bestellereignisse, damit die Agentenplattform mit den maßgeblichen Daten aus dem Fulfillment-System synchron bleibt. Zwei Ereignistypen tragen diese Information: order_create für neue Bestellungen und order_update für Statusänderungen. Genannte Bestellstatus sind created, manual_review, confirmed, canceled, shipped und fulfilled. Für die Implementierung sind drei Einzelheiten wichtig:

• Anfragen müssen signiert sein — mit einer HMAC-Signatur im Header Merchant-Signature. Unsignierte oder falsch signierte Anfragen erhalten 401.
• Das Feld data muss das vollständige Bestellobjekt enthalten, keine inkrementellen Deltas. Bei jedem Ereignis wird der gesamte Zustand gesendet.
• Diese Antwortcodes müssen behandelt werden: 200 Erfolg, 401 ungültige Signatur, 429 Rate-Limit.

Wie erfährt die Plattform also, ob die Bestellung erfolgreich war? Die konkrete Antwort lautet: Sie teilen es ihr mit — per signiertem POST mit dem vollständigen Objekt — und behandeln die 429-Rate-Limit-Antwort der Plattform.

Betrug, Chargebacks und Haftung — was geklärt ist und was nicht

Dies ist der ehrlichste und unterscheidendste Abschnitt. Ich sage klar, wo die Grenze zwischen „geklärt“ und „offen“ tatsächlich liegt.

Geklärt ist der Merchant of Record. OpenAIs Zahlungsspezifikation sagt, dass OpenAI nicht Merchant of Record ist: Im ACP bringen Händler ihren eigenen PSP mit; Abrechnung, Erstattungen, Chargebacks und Compliance bleiben beim Händler und seinem PSP. Ryes Arjun Bhargava bestätigt unabhängig, dass der Händler in beiden Protokollen Merchant of Record und damit für Fulfillment, Chargebacks und Streitfälle verantwortlich bleibt. Das entspricht der Darstellung in beiden Geschwisterartikeln — übernehmen Sie diese Einordnung, statt sie erneut herzuleiten.

Nicht geklärt ist das Belegsystem für Chargebacks. Die Rolle des Merchant of Record sagt, wer einen Streitfall standardmäßig trägt. Sie sagt nicht, wie man ihn gewinnt, wenn der „Kunde“ durch einen KI-Agenten vermittelt wurde. Klassische Chargeback-Abwehr stützt sich auf von Menschen erzeugte Spuren (IP, Gerät, Browsing-Verhalten, menschlicher Klick auf „Kaufen“). Von Agenten erzeugte Autorisierungslogs sind eine andere Art Beleg, und die Regeln der Kartennetzwerke wurden nicht für sie geschrieben. Chargeflows Betrugsspezialist Ben Herut beschreibt den agentischen Handel als eine neue Ebene von Betrug und Verwirrung, die Legacy-Systeme nicht interpretieren können; die Analyse von Chargeflow ist noch deutlicher: Es gibt bisher keine eindeutigen Antworten — Kartennetzwerke, Issuer und Plattformanbieter arbeiten diese Fragen noch aus.

Die Rahmenwerke entstehen erst und sind noch nicht fertig. Visas Trusted Agent Protocol wird als standardbasiertes Rahmenwerk beschrieben, mit dem Händler Identität und Absicht eines Agenten in Echtzeit prüfen und Identitätsmissbrauch verhindern können, ohne die Nutzererfahrung zu verschlechtern. Mastercards Agent Pay (angekündigt im April 2025) verwendet „Agentic Tokens“, eine Erweiterung des Digital Enablement Service. Laut Drittberichten (Fintech Wrap Up / Finextra) soll Mastercards Haftung denselben Regeln wie bei tokenisierten Standardtransaktionen folgen — der Issuer trägt die Betrugshaftung, wenn das Token bei der Autorisierung gültig ausgestellt und akzeptiert wurde. Diese konkrete Zuweisung würde ich jedoch als berichtet, nicht bestätigt behandeln, bis sie in Mastercards eigenen Dokumenten steht. Visas verbraucherseitige Nullhaftung schützt Karteninhaber vor nicht autorisierten Belastungen; sie löst nicht die eigentliche Händlerfrage zum Streitfall. Verwechseln Sie beides nicht.

Was Händler implementieren und testen müssen

Die vorhandenen Inhalte geben strategische Vorbereitungstipps (saubere Feeds, Treueprogramme). Hier geht es um die Betriebsebene: Was müssen Sie tatsächlich bauen und prüfen, bevor Sie den Ablauf aktivieren?

• PCI-Position festlegen. Tokenisierter oder Netzwerk-Token-Weg gegenüber direkter CHD-Verarbeitung (Level 1). Die meisten Händler sollten die Delegation beim PSP belassen.
• Wiederholungen idempotenzsicher machen. ACP hat den Fehlertyp request_not_idempotent nicht ohne Grund. Ein Agent oder eine instabile Netzwerkverbindung wird Erstellungs-/Abschlussaufrufe wiederholen; senden Sie einen Idempotenzschlüssel und machen Sie Wiederholungen mit demselben Schlüssel sicher, damit weder eine Doppelbelastung noch eine doppelte Bestellung entsteht.
• Webhook-Signaturen prüfen. Validieren Sie die HMAC-Signatur Merchant-Signature jedes eingehenden Order-Webhooks, lehnen Sie Abweichungen ab und bestätigen Sie, dass Sie unter Last korrekt mit 200 und 429 antworten.
• Eskalationspfade in der Sandbox simulieren. Erzwingen Sie requires_escalation / authentication_required, führen Sie einen 3DS-Step-up aus und prüfen Sie, dass AuthenticationResult auch denied/rejected/abandoned und nicht nur authenticated behandelt.
• Preisangaben zwischen Feed und Checkout abgleichen. Wenn der Agent im Feed einen anderen Preis sieht als der Checkout liefert, schwindet Vertrauen schnell — was im ACP-Geschwisterartikel für Feeds gilt, ist am Checkout besonders kritisch.
• Agentenbestellungen zuordnen. Ein abgeschlossener Agentic Checkout kann ohne GA4-Sitzung eintreffen. Erfassen Sie ihn auf Bestell-/OMS-Ebene, statt auf einen Websitebesuch zu warten.

Die Registerkarten Testing SOP und Spickzettel machen daraus einen konkreten Testlauf.

Wo der Stand Mitte 2026 ist

Orientieren Sie sich an der tatsächlichen Verbreitung, nicht an Präsentationsfolien. Shopifys Präsident Harley Finkelstein zufolge waren nur etwa ein Dutzend Shopify-Händler aktiv mit KI-Checkout-Tools unterwegs — verschwindend wenig gemessen an Shopifys gesamter Händlerbasis. OpenAI nahm die vollständig im Chat ausgeführte Version von Instant Checkout im März 2026 nach Problemen bei Onboarding, Genauigkeit und Warenkörben mit mehreren Artikeln selbst auf Produktsuche plus Weiterleitung zurück. Semrushs Leigh McKenzie fasste die Reibung gut zusammen: Die Katalognormalisierung in Echtzeit über zig Millionen SKUs ist ein Problem im Maßstab eines Jahrzehnts, während Verbraucher weiterhin Checkout-Abläufe bevorzugen, denen sie vertrauen — Apple Pay, Google Wallet und Amazon One-Click.

Das bedeutet nicht, dass Agentic Checkout heiße Luft ist. Die Protokollfähigkeit — eine Sitzung programmatisch erstellen, aktualisieren und abschließen, mit delegierter Zahlung und signierten Order-Webhooks — ist real, spezifiziert und eine sinnvolle Investition. Sie ist nur nicht „bereits normal“; ob der letzte Schritt im Chat oder auf Ihrer Website abgeschlossen wird, ist ein Implementierungsdetail, das sich bereits einmal geändert hat und wieder ändern kann.

KI-Zusammenfassung

Die Kurzfassung der fortgeschrittenen Version:

• Agentic Checkout ist der Transaktionsabschluss im agentischen Handel: Ein Agent erstellt, aktualisiert, schließt eine Checkout-Sitzung ab oder bricht sie im Auftrag einer kaufenden Person ab. Er ist ein Baustein von ACP und UCP, kein eigenständiges Protokoll.
• Es ist eine Zustandsmaschine. ACP: not_ready_for_payment → ready_for_payment → (requires_escalation/authentication_required) → completed; canceled, expired und pending_approval liegen außerhalb des Erfolgswegs. UCP bildet dies mit incomplete → requires_escalation → ready_for_complete ab.
• Eskalationsstatus bilden die Schnittstelle für menschliche Eingriffe — Login, 3DS-Step-up, Adressprüfung, B2B approval_required und UCP continue_url. Ein vollständig autonomer Checkout ohne Menschen ist nicht die Bauweise der Spezifikationen.
• Zahlung bedeutet begrenzte Tokens: händlergebunden (merchant_id + checkout_session_id), betragsbegrenzt (max_amount), zeitlich befristet (expires_at) und einmalig (reason: one_time). Der Agent erhält nie eine echte Karte. Direkte CHD-Verarbeitung wirkt sich auf den PCI-Umfang aus (Level 1); die meisten Händler verwenden den PSP- und Token-Weg.
• Bestellbestätigung erfolgt per Push: Händler senden HMAC-signierte (Merchant-Signature) Webhooks mit vollständigem Objekt (order_create/order_update) und behandeln 200/401/429.
• Haftung: Der Händler bleibt Merchant of Record (Abrechnung, Erstattungen und Chargebacks beim Händler und PSP gemäß OpenAIs Spezifikation). Das Belegsystem für die Anfechtung eines Kaufs durch einen KI-Agenten ist Mitte 2026 jedoch offen. Visa TAP und Mastercards Agent Pay befinden sich noch in Entwicklung und sind nicht fertig.
• Testen: idempotenzsichere Wiederholungen (request_not_idempotent), Webhook-Signaturen, simulierte Eskalations-/3DS-Pfade, Preisgleichheit zwischen Feed und Checkout sowie die Zuordnung von Agentenbestellungen (keine GA4-Sitzung).
• Die Verbreitung steht am Anfang: etwa ein Dutzend aktive Shopify-Händler vor OpenAIs Kurswechsel im März 2026 zu Produktsuche plus Weiterleitung.

Offizielle Dokumentation

Primärquellen für die Mechanik des Checkouts.

ACP — Checkout, Lebenszyklus und Webhooks

• ACP-Checkout-API-Referenz — Endpunkte der Checkout-Sitzung, vollständiges Status-Enum, CheckoutSession-Felder, Fehler- und MessageError-Objekte, RiskSignals, AuthenticationResult und InterventionCapabilities.
• ACP-Checkout-Lebenszyklus und Konzepte — Statusübergänge (Fulfillment-Option → ready_for_payment; Wiederholung nach fehlgeschlagener Zahlung).
• ACP-Order-Webhooks — order_create/order_update, HMAC-Anforderung Merchant-Signature, vollständige Payloads und Antwortcodes.
• ACP-Spezifikation auf GitHub — OpenAPI-/JSON-Schema und datumsbasierte Versionen.

OpenAI / Stripe — Zahlungsdelegation

• Spezifikation für delegierte Zahlungen von OpenAI — Ablauf für begrenzte Tokens, das Allowance-Objekt (max_amount, expires_at, merchant_id, checkout_session_id, reason), PCI-Hinweis und Formulierung zum Merchant of Record.
• OpenAI-Commerce-Dokumentation — Überblick über die Händlerintegration.
• Stripe — Agentic Commerce (ACP) — Shared Payment Token, die erste mit Delegated Payment kompatible Implementierung.
• Stripe — ACP-Protokollspezifikation — Aufbau der Checkout-Endpunkte.

UCP (parallele Checkout-Maschine)

• UCP-Leitfaden von Google for Developers — Bedingungen zum Merchant of Record und zur Teilnahme auf der Google-/Shopify-Seite.

Plattformen und Zahlungsnetzwerke

• Anforderungen für Agentic Storefronts bei Shopify — Supplemental Terms und der zum Recherchezeitpunkt geltende Early-Access-Status für Google AI Mode/Gemini.
• Visa — Agentischer Handel: Bedrohungen und Risiken — Einordnung des Trusted Agent Protocol.

Zitate aus der Quelle

Aufzeichnungen darüber, wie Agentic Checkout funktioniert und wo offene Fragen liegen. Die Deep Links springen zur belegten Passage auf der Quellseite.

ACP / OpenAI — die Spezifikation

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (Übersetzung) „Der Händler behält die vollständige Kontrolle über Bestand, Preise, Steuerberechnungen und Zahlungsabwicklung.“ — ACP-Checkout-API-Referenz. Zum Zitat springen
• Das Status-Enum des Checkouts, wörtlich: “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (Übersetzung) „unvollständig, nicht für Zahlung bereit, Eskalation erforderlich, Authentifizierung erforderlich, für Zahlung bereit, Freigabe ausstehend, Abschluss läuft, abgeschlossen, abgebrochen, in Bearbeitung, abgelaufen.“ — ACP-Checkout-API-Referenz. Zum Zitat springen
• “OpenAI is not the merchant of record.” (Übersetzung) „OpenAI ist nicht der Merchant of Record.“ Unter ACP bringen Händler ihren eigenen PSP mit; Abrechnung, Erstattungen, Chargebacks und Compliance bleiben beim Händler und seinem PSP. — Spezifikation für delegierte Zahlungen von OpenAI. Zum Zitat springen
• Zum Token-Flow: Der PSP oder Vault gibt ein “payment token scoped to the delegated payment” (Übersetzung) „auf die delegierte Zahlung begrenztes Zahlungs-Token“ außerhalb des PCI-Umfangs zurück. — Spezifikation für delegierte Zahlungen von OpenAI. Zum Zitat springen

Stimmen aus der Branche — die Haftungsfrage

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (Übersetzung) „Agentischer Handel schafft Effizienz, aber auch eine neue Ebene von Betrug und Verwirrung, die Legacy-Systeme nicht interpretieren können.“ — Ben Herut, Betrugs- und Chargeback-Stratege bei Chargeflow. Berichterstattung lesen
• Zur Frage, ob die Regeln geklärt sind, lautet Chargeflows Analyse: “there are no clean answers yet” (Übersetzung) „Bisher gibt es keine eindeutigen Antworten“ — Kartennetzwerke, Issuer und Plattformanbieter arbeiten diese Fragen noch aus. Berichterstattung lesen
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (Übersetzung) „In beiden Protokollen bleibt der Händler Merchant of Record — verantwortlich für Fulfillment, Chargebacks und Streitfälle.“ — Arjun Bhargava, Co-Founder und CEO, Rye. Berichterstattung lesen

Zahlungsnetzwerke — entstehende Rahmenwerke

• Zu Visas Ansatz: Das Trusted Agent Protocol ist “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (Übersetzung) „ein standardbasiertes Rahmenwerk, das Händlern ermöglicht, Identität und Absicht eines Agenten in Echtzeit zu prüfen und Identitätsmissbrauch zu verhindern, ohne die Nutzererfahrung zu verschlechtern.“ — Visa, Agentischer Handel: Bedrohungen und Risiken. Zum Zitat springen

Verbreitungsrealität

• Warum vollständig autonomer Checkout langsamer vorankommt als der Hype: “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (Übersetzung) „Die Katalognormalisierung in Echtzeit über zig Millionen SKUs ist ein Problem im Maßstab eines Jahrzehnts, das Google mit Merchant Center bereits gelöst hat; Verbraucher entscheiden sich trotzdem weiterhin standardmäßig für Checkout-Flows, denen sie vertrauen — Apple Pay, Google Wallet und Amazon One-Click.“ — Leigh McKenzie, Director of Online Visibility bei Semrush, über Search Engine Land. Berichterstattung lesen

Welchen Zahlungsintegrationsweg sollten Sie wählen?

Die erste echte Architekturentscheidung beim Agentic Checkout lautet, wie die Zahlung delegiert wird — denn davon hängen PCI-Umfang und eigener Implementierungsaufwand direkt ab. Gehen Sie den Entscheidungsweg Schritt für Schritt durch:

Testlauf vor dem Start für Agentic Checkout

Führen Sie diesen Test in Sandbox-/Testmodus durch, bevor Sie Agentic Checkout in Produktion aktivieren. Das ist die Betriebsebene, die der strategische Rat „Bereinigen Sie Ihren Feed“ auslässt.

1. Checkout-Sitzung erstellen und Erfolgsweg durchlaufen. POST /checkout_sessions senden; 201 und eine Sitzung in not_ready_for_payment (oder incomplete) bestätigen. Fulfillment-Option hinzufügen und den Wechsel zu ready_for_payment bestätigen.
2. Summen als maßgeblich prüfen. Prüfen, dass totals[] der Sitzung (subtotal / tax / fulfillment / discounts / total) mit der Backend-Berechnung übereinstimmen und der Preis dem Feed entspricht. Eine Abweichung zwischen Feed- und Checkout-Preis zerstört Vertrauen.
3. Sitzung abschließen. POST /checkout_sessions/{id}/complete senden; bestätigen, dass die Zahlung verarbeitet, eine Order erstellt und der Status completed erreicht wird.
4. Sitzung abbrechen. POST /checkout_sessions/{id}/cancel senden; bestätigen, dass Bestand freigegeben wird und keine Bestandsreservierung hängen bleibt.
5. Eskalationspfade erzwingen. requires_escalation / authentication_required simulieren. Einen 3DS-Step-up ausführen und prüfen, dass AuthenticationResult alle Fehlerausgänge (denied, rejected, abandoned, canceled, not_supported) und nicht nur authenticated abdeckt.
6. Idempotenz testen. Dieselbe Erstellungs-/Abschlussanfrage zweimal mit demselben Idempotenzschlüssel senden; eine Bestellung statt zwei bestätigen und prüfen, dass eine tatsächlich nicht idempotente Wiederholung request_not_idempotent statt einer Doppelbelastung liefert.
7. Business-Logic- und HTTP-Fehler unterscheiden. Ein Sitzungsproblem auslösen (zum Beispiel eine nicht vorrätige Position) und bestätigen, dass es als MessageError in messages[] erscheint; eine fehlerhafte Anfrage muss als HTTP-Fehlerobjekt zurückkommen. Der Client muss beide Fälle behandeln.
8. Webhook-Signaturen prüfen. Einen gültigen order_create-Webhook senden, Merchant-Signature per HMAC prüfen und 200 zurückgeben. Einen manipulierten Webhook senden und 401 bestätigen. Prüfen, dass das vollständige Bestellobjekt und kein Delta ausgegeben wird.
9. Rate-Limits bei Webhooks testen. Bestätigen, dass der Sender ein 429 der Plattform mit Wiederholung und Backoff behandelt, statt das Ereignis zu verwerfen.
10. Zuordnung erfassen. Prüfen, dass die abgeschlossene Bestellung auf OMS-Ebene als agentenvermittelt markiert wird, da keine GA4-Sitzung existieren muss.

Häufige Fehler — und was stattdessen zu tun ist

Annehmen, „Agentic Checkout“ bedeute vollständig autonomes Kaufen ohne Menschen. Warum das falsch ist: Jede glaubwürdige Implementierung hat eine Autorisierungs-/Eskalationsschnittstelle — requires_escalation, authentication_required, 3DS-Step-up und B2B approval_required. Vollständige Autonomie ohne Autorisierung durch einen Menschen entspricht weder dem Protokolldesign noch der derzeitigen Behandlung solcher Transaktionen durch Kartennetzwerke. Tun Sie stattdessen: Gestalten Sie Eskalationspfade (continue_url, 3DS, Freigabe) als feste Ablaufzweige, damit eine Transaktion, die einen Menschen braucht, sauber eskaliert und nicht endet.

Behandeln, was in den Schlagzeilen steht, als bereits normal. Warum das falsch ist: Vor OpenAIs Rücknahme der In-Chat-Version im März 2026 waren nur etwa ein Dutzend Shopify-Händler mit ChatGPT-Checkout live. Tun Sie stattdessen: Bauen Sie gegen die Protokollfähigkeit (sie ist real und spezifiziert), planen Sie Ressourcen aber so, als wären Sie ein früher Anwender und nicht der Nachzügler in einem etablierten Markt.

Glauben, die Betrugshaftung sei geklärt, weil der Merchant of Record feststeht. Warum das falsch ist: Der Merchant of Record ist für Abrechnung, Erstattungen und Compliance bestätigt, aber das Belegsystem für Chargebacks — der Nachweis, dass ein angefochtener Umsatz autorisiert war, wenn der Käufer ein KI-Agent war — wird von Branchenexperten ausdrücklich als offen beschrieben. Tun Sie stattdessen: Erfassen Sie jetzt Agenten-Autorisierungslogs und Risikosignale, behandeln Sie Visa TAP und Mastercard Agent Pay als noch nicht fertige Rahmenwerke und nehmen Sie nicht an, dass Ihre bisherige Chargeback-Evidenz ausreicht.

Annehmen, der Agent überspringe Ihre Website, daher sei Ihr eigener Checkout egal. Warum das falsch ist: „Überspringt immer die Händlerseite“ war die ursprüngliche ChatGPT-Instant-Checkout-Ankündigung; die Vorzeigeimplementierung von ACP wechselte im März 2026 selbst zu Produktsuche plus Weiterleitung. Die Protokollfähigkeit ist unabhängig von einer bestimmten Oberfläche. Tun Sie stattdessen: Halten Sie Ihren gehosteten Checkout stabil und unterstützen Sie zugleich den programmatischen Sitzungsablauf — je nach Oberfläche kann der Abschluss im Chat oder auf Ihrer Website erfolgen.

Denken, der Agent verarbeite die Kartennummer des Kunden. Warum das falsch ist: Rohdaten der Karte erreichen den Agenten absichtlich nicht — begrenzte oder delegierte Tokens (Shared Payment Token und UCPs entkoppeltes Instrument-/Handler-Modell) sind der Sinn der Zahlungsdelegation. Tun Sie stattdessen: Leiten Sie die Delegation über Ihren PSP, sodass ein händlergebundenes, betragsbegrenztes, einmaliges Token die Arbeit erledigt und Ihr PCI-Umfang klein bleibt.

Nicht idempotente Wiederholungen akzeptieren. Warum das falsch ist: Agenten und Netzwerke wiederholen Anfragen. ACP hat den Fehlertyp request_not_idempotent gerade deshalb, weil naive Wiederholungen zu Doppelbelastungen oder doppelten Bestellungen führen. Tun Sie stattdessen: Erzwingen Sie Idempotenzschlüssel für Erstellungs-/Abschlussaufrufe und machen Sie Wiederholungen mit demselben Schlüssel sicher.

Agentic Checkout — Spickzettel

Status-Enum der ACP-Checkout-Sitzung

Die parallele UCP-Maschine: incomplete → requires_escalation (Mensch über continue_url) → ready_for_complete.

Checkout-Endpunkte (ACP)

• POST /checkout_sessions — erstellen (201)
• GET /checkout_sessions/{id} — abrufen
• POST /checkout_sessions/{id} — aktualisieren
• POST /checkout_sessions/{id}/complete — Zahlung verarbeiten und Bestellung erstellen
• POST /checkout_sessions/{id}/cancel — abbrechen und Bestand freigeben

Begrenztes Zahlungs-Token — die vier Grenzen

• merchant_id + checkout_session_id → an Händler und Sitzung gebunden
• max_amount → betragsbegrenzt
• expires_at (RFC 3339) → zeitlich befristet
• reason: "one_time" → einmalig

Bestell-Webhooks (ACP)

• Ereignisse: order_create, order_update
• Signiert: HMAC-Header Merchant-Signature (erforderlich)
• Payload: vollständiges Bestellobjekt, keine Deltas
• Antworten: 200 ok · 401 falsche Signatur · 429 Rate-Limit
• Bestellstatus: created · manual_review · confirmed · canceled · shipped · fulfilled

Auslöser für menschliche Eingriffe

• Status requires_escalation / authentication_required
• InterventionCapabilities (3ds, address_verification; enforcement always/conditional/optional)
• Ergebnisse von AuthenticationResult (authenticated/denied/rejected/abandoned/…)
• B2B approval_required; UCP continue_url

Haftung auf einen Blick

• Händler = Merchant of Record → Abrechnung/Erstattungen/Chargebacks bei Händler und PSP ✅ geklärt
• Regeln für Chargeback-Belege bei Agenten-Käufern ⚠️ offen (Mitte 2026)
• Visa TAP / Mastercard Agent Pay → noch nicht fertige Rahmenwerke

Snippets für Agentic Checkout

Diese Beispiele dienen dazu, Ihre eigene Integration zu untersuchen und zu testen — nicht dazu, Live-Käufe auszulösen. Verwenden Sie Sandbox-/Test-Zugangsdaten.

Webhook-Signatur prüfen (Node.js, HMAC)

Lehnen Sie alles ab, dessen Merchant-Signature nicht übereinstimmt. Vergleichen Sie in konstanter Zeit.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Status einer Checkout-Sitzung abfragen (Shell)

Beobachten Sie, wie eine Sandbox-Sitzung während des Tests durch die Zustandsmaschine läuft.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Create-Aufruf mit Idempotenzschlüssel senden (Python)

Beweisen Sie, dass eine Wiederholung mit demselben Schlüssel eine Order statt zwei erzeugt.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Console-Snippet — eine gerenderte Seite auf ein .well-known-UCP-Profil prüfen

Schnelle DevTools-Console-Prüfung, ob ein Händler UCP-Discovery anbietet (in der Browser-Console am Origin des Händlers einfügen):

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet — zum Status-Enum in der ACP-Dokumentation springen

Legen Sie dies als Lesezeichen an, um die ACP-Checkout-Referenz direkt bei der Statusliste zu öffnen:

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Häufige Fehler bei Agentic Checkout

Eine Wiederholung erzeugt zwei Bestellungen oder Belastungen

Symptom: Dieselbe Checkout-Sitzung erzeugt nach einem Timeout oder einer Netzwerkwiederholung doppelte Bestellungen. Wahrscheinliche Ursache: Erstellungs- oder Abschlussaufrufe sind nicht schlüsselgebunden und nicht idempotenzsicher. Behebung: Idempotenzschlüssel verlangen, bei einer Wiederholung mit demselben Schlüssel das ursprüngliche Ergebnis zurückgeben und mit zwei identischen Sandbox-Aufrufen bestätigen, dass eine Sitzung und eine Bestellung entstehen.

Checkout wird nicht zahlungsbereit

Symptom: Eine Sitzung bleibt auf not_ready_for_payment oder incomplete. Wahrscheinliche Ursache: Eine erforderliche Fulfillment-Option, ein Adressfeld oder eine Geschäftsregel ist ungelöst. Behebung: Pflichtfelder und messages[] der Sitzung prüfen, die fehlende Auswahl liefern und bestätigen, dass der Status zu ready_for_payment oder ready_for_complete fortschreitet.

Eine gültige Anfrage scheint erfolgreich, aber der Warenkorb lässt sich nicht abschließen

Symptom: Die HTTP-Anfrage ist erfolgreich, während die Sitzung einen nicht vorrätigen Artikel oder einen anderen Geschäftsfehler enthält. Wahrscheinliche Ursache: Der Client verarbeitet nur HTTP-Fehler und ignoriert MessageError-Einträge. Behebung: Transportfehler und Sitzungsnachrichten gleichermaßen verarbeiten und bestätigen, dass Benutzer oder Agent die handlungsrelevante Fehlermeldung sehen.

Menschliche Prüfung endet still in einer Sackgasse

Symptom: Der Checkout gelangt zu requires_escalation oder authentication_required und kehrt nicht zurück. Wahrscheinliche Ursache: 3DS-, Login-, Freigabe- oder continue_url-Übergabe wurde als Ausnahme statt als unterstützter Status behandelt. Behebung: Sitzung über die Übergabe hinweg beibehalten, jedes Authentifizierungsergebnis behandeln und sowohl erfolgreiche als auch abgebrochene Abläufe sauber auflösen.

Bestellstatus wird nach der Zahlung nicht mehr aktualisiert

Symptom: Der Händler besitzt die Bestellung, aber die Agentenoberfläche bleibt ausstehend oder veraltet. Wahrscheinliche Ursache: Eine Webhook-Signatur schlägt fehl, nur ein Delta wurde gesendet oder 429-Antworten wurden verworfen. Behebung: Die exakten Nutzdaten signieren, das vollständige Bestellobjekt senden, Rate-Limit-Ereignisse mit Backoff wiederholen und bestätigen, dass der Empfänger das Ereignis akzeptiert.

Denkmodelle für Agentic Checkout

Checkout ist eine Zustandsmaschine, kein einzelner API-Aufruf

Jede Antwort sollte die Sitzung in einen bekannten Status bringen oder einen bekannten Grund liefern, warum sie nicht weitergehen kann. Entwerfen Sie Clients rund um Übergänge, Endstatus, Wiederholungen und Eskalationen statt um einen einzelnen „Kaufen“-Aufruf.

Die Autorität bleibt beim Händler

Der Agent formuliert eine Absicht, aber der Händler bleibt maßgeblich für Preis, Bestand, Steuern, Fulfillment, Bestellstatus und die Pflichten des Merchant of Record. Behandeln Sie den vom Agenten gewünschten Warenkorb als Eingabe und den vom Händler zurückgegebenen Warenkorb als maßgeblich.

Delegation verengt Berechtigungen

Ein begrenztes Zahlungs-Token ist sicher, weil es an Händler und Sitzung gebunden, betragsbegrenzt, zeitlich befristet und einmalig ist. Prüfen Sie jede delegierte Fähigkeit mit den Fragen: Was kann sie tun, für wen, für wie viel und wie lange?

Eskalation ist ein erfolgreicher Zweig

Menschliches Eingreifen ist kein fehlgeschlagener autonomer Checkout. Eine saubere Übergabe für 3DS, Login, Adresse oder B2B-Freigabe ist das Protokoll, das wie vorgesehen funktioniert.

Nach dem Abschluss erfolgt die Zustellung asynchron

Der Abschluss der Zahlung beendet die Integration nicht. Signierte Webhooks mit vollständigem Objekt übermitteln nach dem Checkout weiterhin den maßgeblichen Bestellstatus; Signaturprüfung, Idempotenz und Wiederholungsbehandlung gehören daher zur Checkout-Zuverlässigkeit.

Kennzahlen für Agentic Checkout

Abschluss des Checkouts nach Endstatus

• Kennzahl: abgeschlossene, abgebrochene oder abgelaufene Sitzungen als Anteil der gestarteten Sitzungen.
• Aussage: Wo endet die Zustandsmaschine und wie viel Kaufabsicht geht verloren, bevor eine Bestellung existiert?
• Erhebung: Statusänderungen der Checkout-Sitzung aus Commerce-API oder Bestellplattform aggregieren, aufgeschlüsselt nach Protokoll und Händleroberfläche.
• Benchmark / realistische Spanne: Eine Basislinie für den eigenen Produktmix festlegen und vergleichbare Abläufe vergleichen; bei dieser Verbreitung ist keine allgemeingültige Rate belastbar.
• Rhythmus: täglich überwachen, wöchentlich den Trend prüfen.

Erholungsrate nach Eskalation

• Kennzahl: eskalierte Sitzungen, die nach 3DS-, Login-, Adress- oder Freigabe-Eingriff zurückkehren und abgeschlossen werden.
• Aussage: Ist die Übergabe an einen Menschen ein nutzbarer Weg oder eine Sackgasse?
• Erhebung: Eskalationsereignisse über die Checkout-Session-ID mit späteren Statusübergängen verbinden.
• Benchmark / realistische Spanne: Jede Eingriffsart separat als Basislinie erfassen, weil Authentifizierung und B2B-Freigabe unterschiedlich viel Reibung erzeugen.
• Rhythmus: wöchentlich und nach jeder Änderung am Übergabeablauf.

Rate doppelter Bestellungen und fehlgeschlagener Webhooks

• Kennzahl: doppelte Bestellungen durch Wiederholungen mit demselben Schlüssel plus abgelehnte oder ausgeschöpfte Webhook-Zustellungen.
• Aussage: Sind Idempotenz und asynchrone Bestellsynchronisierung bei Fehlern zuverlässig?
• Erhebung: Idempotenzschlüssel, Bestell-IDs, Signaturfehler, 401s, 429s, Wiederholungen und Dead-Letter-Ereignisse in den Anwendungslogs vergleichen.
• Benchmark / realistische Spanne: Doppelte Bestellungen sollten bei null liegen; eine normale Basislinie vorübergehender Wiederholungen festlegen und anhaltende Abweichungen untersuchen.
• Rhythmus: sofort alarmieren, wöchentlich zusammenfassen.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• Die beiden Protokolle, in denen Agentic Checkout steckt, werden auf dieser Website ausführlich behandelt: die Beiträge zu Agentic Commerce Protocol (ACP) und Universal Commerce Protocol (UCP). Diese Seite ist der darunterliegende Deep Dive in die Checkout-Mechanik.
• Der Einsteigerleitfaden für E-Commerce-SEO — wo ein agentenorientierter Checkout in das größere E-Commerce-Bild passt.

Meine Vorträge

• So funktioniert die Suche (SlideShare) — meine Erklärung von Discovery, Indexierung und Ranking; nützlich als Hintergrund dafür, wie sich eine von Agenten vermittelte Transaktionsschicht darüberlegt. (Mein ständiger Hinweis gilt: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „So verstehe ich die Systeme … diese Darstellung wird nicht zu 100 % vollständig oder korrekt sein.“)

Aus der Branche

• Agentic Commerce Protocol — Checkout-Referenz (OpenAI/Stripe) — maßgebliches Status-Enum, Sitzungsfelder und Interventions-/Authentifizierungsobjekte.
• Spezifikation für delegierte Zahlungen von OpenAI — Ablauf für begrenzte Tokens sowie Formulierungen zum Merchant of Record und PCI-Umfang.
• Referenz für ACP-Bestell-Webhooks (OpenAI/Stripe) — Push-basierte, HMAC-signierte Synchronisierung vollständiger Bestellobjekte.
• Agentic Commerce Chargebacks: Wer haftet, wenn die KI kauft? (Chargeflow) — die ehrliche „bisher keine eindeutigen Antworten“-Einordnung des Belegproblems.
• Agentischer Handel: Bedrohungen und Risiken (Visa) — Trusted Agent Protocol und Einordnung der Agentenidentität.
• OpenAIs großer ChatGPT-Instant-Checkout-Plan wurde geändert (Search Engine Land) — Kurswechsel im März 2026 und Zitate zur tatsächlichen Verbreitung.
• Was ist Agentic Checkout? (Rye) — klare unabhängige Definition und Bestätigung des Merchant of Record.
• Deep Dive: Mastercards Verifiable Intent gegenüber Visas Trusted Agent Protocol (Fintech Wrap Up / Finextra) — Vergleich der Rahmenwerke der Zahlungsnetzwerke; die konkrete Haftungszuordnung ist als berichtet, nicht bestätigt, zu behandeln.

Zitierfähige Zahlen

Die Zahlen zeigen, wo Agentic Checkout tatsächlich steht — behandeln Sie von Händlern berichtete und weitergegebene Werte als Richtwerte und prüfen Sie diese Zahlen, bevor Sie sich darauf stützen.

• Etwa ein Dutzend Shopify-Händler nutzten aktiv KI-Checkout-Tools — laut Shopifys Präsident, über die Berichterstattung von Search Engine Land zum Kurswechsel im März 2026 weitergegeben; gemessen an Shopifys gesamter Händlerbasis ist das vernachlässigbar. Berichterstattung
• März 2026: der Kurswechsel. OpenAI wechselte ChatGPTs Instant Checkout vom vollständigen Kauf im Chat zu Produktsuche plus Weiterleitung, nachdem Onboarding, Genauigkeit und Warenkörbe mit mehreren Artikeln Reibung erzeugt hatten. Berichterstattung
• Token-Umfang = vier Grenzen. Ein delegiertes Zahlungs-Token ist durch max_amount, expires_at, merchant_id/checkout_session_id und reason: one_time begrenzt — der konkrete Mechanismus, der eine echte Karte vom Agenten fernhält. Quelle
• Webhook-Regel: immer das vollständige Objekt. ACP verlangt, dass das Feld data des Webhooks das vollständige Bestellobjekt statt inkrementeller Deltas enthält und jede Anfrage HMAC-signiert ist. Quelle

Testen Sie Ihr Wissen: Agentic Checkout

Fünf kurze Fragen zur Checkout-Mechanik. Wählen Sie jeweils eine Antwort und prüfen Sie die Antworten anschließend.

Änderungsprotokoll