ACP, UCP und AP2 im Vergleich: Die Agentic-Commerce-Protokolle im Oktober 2026 und welches davon Ihr Shop braucht

Drei offene Protokolle beschreiben inzwischen, wie ein KI-Agent bei einem Shop einkauft. Das Agentic Commerce Protocol (ACP) stammt von OpenAI und Stripe. Das Universal Commerce Protocol (UCP) stammt von Google und Shopify. Das Agent Payments Protocol (AP2), das Google ins Leben gerufen und im April an die FIDO Alliance übergeben hat, ist überhaupt kein Checkout-Protokoll: Es definiert einen signierten Nachweis, dass ein Nutzer eine Zahlung autorisiert hat, und ist dafür ausgelegt, innerhalb von UCP zu laufen. Alle drei stehen unter Apache 2.0.

Am 22. Oktober 2026 stehen sie an sehr unterschiedlichen Punkten. ACP ist als Beta gekennzeichnet, die neueste Version ist 2026-04-17, und seit dem 17. Juli ist kein Commit mehr hinzugekommen. ChatGPT, sein wichtigster Nutzer, hat sich im März vom eigenständigen Checkout abgewandt und nutzt ACP jetzt vor allem, um Produktdaten zu empfangen. UCP hat im August mit 2026-08-25 eine nicht abwärtskompatible Version veröffentlicht, während Googles eigene Oberflächen noch 2026-04-08 verwenden und Googles Checkout im Early Access läuft, nur in den USA. AP2 steht bei v0.2, und kein Google-Produkt dokumentiert, dass es AP2 verwendet.

Dieser Artikel richtet sich an CTOs und leitende Entwickler von Shops und Commerce-Plattformen, die entscheiden, was sie implementieren. Wenn Sie wissen wollen, was jede KI-Plattform von einem Shop als Unternehmen verlangt, beginnen Sie mit unserem Überblick über Agentic Commerce.

Im direkten Vergleich

ACP: Das Agentic Commerce Protocol

Governance und Versionen

Das Spezifikations-Repository gibt an, dass ACP von OpenAI und Stripe gepflegt wird, und kennzeichnet es als Beta. Das Governance-Dokument macht die beiden zu Founding Maintainers: Sie besetzen die Sitze des Lenkungsausschusses (bis zu sieben) und behalten ein Veto, das „als letztes Mittel“ eingesetzt werden soll. Meta kam am 24. April 2026 als dritter leitender Maintainer und Mitglied des Ausschusses hinzu. Stripes Dokumentation bezeichnet ACP als „von Stripe, OpenAI und Meta entwickelt“, doch die Notice-Datei des Repositorys nennt nur OpenAI und Stripe. Eine neutrale Stiftung ist bisher nur als künftiger Weg angekündigt.

Es gibt fünf datierte Releases: 2025-09-29 (Checkout und delegierte Zahlung), 2025-12-12 (nicht abwärtskompatible Änderungen aus den Erfahrungen mit den Adaptern von URBN und Etsy), 2026-01-16 (ein vom Händler gewählter 3DS-Anbieter), 2026-01-30 (Aushandlung der Capabilities, Erweiterungen und ein nicht abwärtskompatibles Framework für Payment Handler) und 2026-04-17 (Warenkorb, Feed, Bestellungen, delegierte Authentifizierung, Discovery und MCP), mit dem 2026-01-30 als veraltet markiert wurde. In den sechs Monaten seitdem ist nichts veröffentlicht worden. Der Ordner unreleased/ enthält kleinere Änderungen mit Datum bis zum 17. Juli, etwa eine ID für Feed-Aktualisierungen und eine optionale Produkt-URL für Artikel im Checkout.

Was ein Händler in Version 2026-04-17 implementiert

Die Checkout-API wird vom Händler gehostet und vom Agenten aufgerufen:

• POST /checkout_sessions erstellt eine Session, POST /checkout_sessions/{checkout_session_id} aktualisiert sie (ein POST, kein PUT), GET auf diesem Pfad ruft sie ab, und .../complete und .../cancel beenden sie.
• Anfragen tragen einen Bearer-API-Key und einen verpflichtenden Header API-Version. Seit 2026-04-17 ist ein Idempotency-Key bei jedem POST Pflicht, mit definierten Fehlern: 400 idempotency_key_required, 409 idempotency_in_flight und 422 idempotency_conflict.
• Die Anfrage zum Erstellen enthält ein Objekt capabilities. Der Agent gibt an, was er unterstützt, und der Verkäufer gibt die Schnittmenge zurück, sodass eine Inkompatibilität schon vor der Zahlung sichtbar wird.
• Der Händler sendet Bestellereignisse per POST an einen Empfänger, den OpenAI unter /agentic_checkout/webhooks/order_events hostet, signiert mit HMAC-SHA256 in einem Header Merchant-Signature. Die Statuswerte reichen von created bis delivered oder canceled, und adjustments[] enthält Erstattungen, Retouren, Disputes und Chargebacks.

Das Release 2026-04-17 hat außerdem eine statische, öffentliche /.well-known/acp.json eingeführt, deren Feld transports angibt, ob der Shop rest, mcp oder beides spricht. Es hat ein MCP-Binding über Streamable HTTP mit fünf Tools hinzugefügt (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), das in der Serverkonfiguration authentifiziert wird statt pro Anfrage. Und es hat eine Feed-API hinzugefügt, die der Agent hostet und an die der Händler seine Daten pusht (POST /feeds, PATCH /feeds/{id}/products), einen Warenkorb für einen einzelnen Verkäufer ohne Zahlungsdaten (POST /carts, PUT /carts/{id}) und delegierte 3DS2-Authentifizierung (POST /delegate_authentication). Abos gibt es nicht: Der RFC zu den Erweiterungen führt subscription als „Unterstützung für wiederkehrende Abrechnung (künftig)“.

Wie die Zahlung in ACP funktioniert

Die ursprüngliche Antwort von ACP ist die delegierte Zahlung. Der PSP oder Karten-Vault implementiert POST /agentic_commerce/delegate_payment, das eine Karte (den einzigen Typ von Zahlungsdaten) in ein Token umwandelt, das der PSP des Händlers nur innerhalb festgelegter Grenzen verwenden darf: reason (nur one_time), max_amount, currency, checkout_session_id, merchant_id und expires_at. Im Wortlaut des RFC: „Zahlungen, Abwicklung und Compliance verbleiben auf den Systemen des Händlers.“ Worldpay dokumentiert eine eigene Version dieses Aufrufs, und PayPal unterstützt ACP über delegierte Tokens in Braintree.

Seit 2026-01-30 werden akzeptierte Zahlungsmethoden als Handler unter capabilities.payment.handlers deklariert. Die Beispiel-Zahlungsdaten aus dem Changelog:

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

Das spt ist Stripes Shared Payment Token, verfügbar „in den USA, in Kanada und in ausgewählten europäischen Ländern“. Ein Verkäufer bei Stripe belastet es mit payment_method_data[shared_payment_granted_token] über eine Preview-Version der API; ein Verkäufer bei einem anderen Zahlungsabwickler kann es ein einziges Mal in die Zahlungsdaten des Kartennetzwerks auflösen. Unser Artikel zu Agentic Payments behandelt, wer das Risiko trägt.

Was OpenAIs Kurswechsel im März verändert hat

Am 24. März 2026 schrieb OpenAI, dass „die erste Version von Instant Checkout nicht das Maß an Flexibilität bot, das wir bieten möchten“, ließ Händler ihre eigenen Checkouts nutzen und erklärte, man werde „ACP so ausbauen, dass es bei der Auffindbarkeit von Produkten durchgehend die verbindende Schicht zwischen Händlern und Nutzern bildet.“ Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot und Wayfair hatten ACP für die Auffindbarkeit integriert, und Shopify-Kataloge kommen über Shopify Catalog. Was das für Entwickler bedeutet:

• Der Feed ist der Teil, der live ist. OpenAIs Händlerseite sagt, Käufe würden „auf händlereigenen Websites oder in händlereigenen Apps abgeschlossen“, und Shopping sei für Nutzer in den USA live. Das Onboarding für Feeds steht zugelassenen Partnern von einer Warteliste offen: täglich eine vollständige Datei per SFTP mit neun Pflichtfeldern, API-Aktualisierungen im Lauf des Tages, Aktionen nur per API. Der Standard-Upload „richtet sich derzeit an die USA“.
• Der Checkout ist eine eigene Hürde. Die Feed-Spezifikation sagt, der Checkout „erfordert eine separat freigeschaltete Integration“. Für ChatGPT-Apps ist der allgemein verfügbare Weg ein externer Checkout auf der eigenen Domain des Entwicklers. Das Zahlungsfenster im Chat ist eine private Beta, „auf ausgewählte Marktplätze beschränkt“, die ein Zahlungstoken in einem Tool-Aufruf complete_checkout an den MCP-Server der App übergibt.
• OpenAIs Seiten hinken der Spezifikation hinterher. Die Checkout-Referenz zeigt noch API-Version 2025-09-12 und ein provider-Enum mit stripe, adyen und braintree. Bauen Sie nach dem Repository und klären Sie mit OpenAI, welche Version akzeptiert wird.

PSP-Seiten, die Instant Checkout noch als live darstellen, sind veraltet.

UCP: Das Universal Commerce Protocol

Governance und Versionen

Google hat am 11. Januar 2026 UCP gestartet, gemeinsam entwickelt mit Shopify, Etsy, Wayfair, Target und Walmart. Die Governance-Regeln geben Google und Shopify je eine ständige Stimme im Governing Council, dem Stripe am 28. April 2026 beigetreten ist, und halten fest: „Google hält bis Dezember 2028 die Stellvertreterstimme für alle offenen Sitze“. Am 24. April wuchs der Shopping Tech Council auf 16 Sitze, mit Amazon, Meta, Microsoft, Salesforce und Stripe als neuen Mitgliedern; damit sitzen Meta und Stripe jetzt sowohl im Ausschuss von ACP als auch im Council von UCP.

Das Repository hat vier Releases. 2026-04-08 hat Capabilities für Warenkorb und Katalog, das Signieren von Anfragen und Antworten sowie Get Order hinzugefügt. 2026-08-25 ist nicht abwärtskompatibel: signing_keys[] wurde durch ein JWK Set in keys[] ersetzt, Zahlungserweiterungen wanderten von dev.ucp.shopping.* nach dev.ucp.common.payment.*, gemeinsame Schemas wurden verschoben und haben ihre $id-URLs geändert, und PAN und Netzwerk-Tokens wurden zu getrennten Typen von Zahlungsdaten. Außerdem kamen herstellerunabhängiges 3DS2, Split Payments, Zahlungsbedingungen und Interoperabilität mit Web Bot Auth hinzu.

Hier liegt die Falle. Googles Leitfaden zum Profil behandelt nur 2026-04-08 und 2026-01-23, Googles eigenes Agentenprofil unter ucp.goog deklariert "version": "2026-04-08", und Salesforce B2C Commerce 26.9 liefert dieselben beiden Versionen aus. Shopifys Checkout MCP verlinkt dagegen 2026-08-25. Wer nach dem neuesten Release baut, baut eine Version, die Google nicht dokumentiert. Die Antwort der Spezifikation ist ein Objekt supported_versions, das jeder älteren Version ihre eigene Profil-URI zuordnet.

Discovery, Transporte und Authentifizierung

Jeder Händler veröffentlicht ein Profil unter /.well-known/ucp mit ucp.version, ucp.services und ucp.payment_handlers, und Google verlangt, dass es öffentlich und ohne Authentifizierung erreichbar ist. Die Plattform des Agenten veröffentlicht ebenfalls eines, und jede Anfrage trägt dessen URI in einem Header UCP-Agent, über HTTPS mit mindestens TLS 1.3. Die Authentifizierung wählt der Händler: keine, X-API-Key, OAuth 2.0, Mutual TLS oder HTTP Message Signatures nach RFC 9421. Google sendet ein Bearer-Token, und seine FAQ bietet auch mTLS an. Ein Idempotency-Key ist nur ein „SHOULD“; ein Server, der einen akzeptiert, bewahrt ihn mindestens 24 Stunden auf und antwortet mit 409, wenn er mit einem anderen Body wiederverwendet wird.

REST ist der zentrale Transport, daneben gibt es MCP, eine A2A-Erweiterung und einen eingebetteten Modus, der über eine continue_url erreicht wird. Bestellungen bestehen aus einem GET /orders/{id} und einem Webhook vom Händler an die Plattform, signiert nach RFC 9421. Die Warenkorbpfade sind dieselben wie bei ACP. Die Checkout-Operationen sehen ähnlich aus, sind aber nicht austauschbar:

Ein Checkout-Kern kann beide bedienen. Eine Routentabelle kann es nicht.

Wie die Zahlung in UCP funktioniert

UCP bewegt kein Geld. Ein Payment Handler ist eine Spezifikation, die ein Anbieter von Zahlungsdaten schreibt, etwa com.google.pay für Google Pay oder dev.shopify.shop_pay für Shop Pay. Der Händler listet die Handler auf, die er akzeptiert, die Plattform führt einen davon aus, und bei complete erhält der Händler ein opakes Token, das er über seinen eigenen PSP belastet.

Auf Googles Oberflächen ist Google Pay der einzige Handler, PAN_ONLY ist die einzige verwendete Authentifizierungsmethode, und Ihr PSP „muss unsere Tokens verarbeiten können“. Stripe veröffentlicht com.stripe.payments für Karte und Apple Pay: „Der Agent sendet ein Shared Payment Token (SPT) in der Anfrage Complete Checkout, und der Verkäufer belastet es.“ Google Pay bleibt bei seinem eigenen Handler. PayPal nimmt den Google-Pay-Handler über Braintree oder über seine Orders-v2-API an.

Was Google verlangt, bevor es Sie aufruft

Googles Leitfaden zum nativen Checkout verlangt die REST-Checkout-API und behält den Zahlungsschritt bei sich: Der Käufer gibt sensible Daten „nur über die Google-Benutzeroberfläche“ ein. Die Service-Levels verlangen mindestens 95 % Verfügbarkeit pro Endpoint, mit Latenzen (p50 und p95) von 1 und 4 Sekunden für das Erstellen, 1 und 5 für das Aktualisieren und 6 und 10 für den Abschluss. Nach einer Bestellung senden Sie Status-Updates an einen Webhook von Google, mit einer Partner-ID und einem Schlüssel, die beim Onboarding ausgegeben werden. Im Merchant Center braucht jedes Produkt native_commerce(checkout_eligibility) auf true (das Attribut steht „standardmäßig auf FALSE“), eine Rückgaberichtlinie und ein Support-Kontakt sind Pflicht, und Abos, Ratenkäufe, personalisierte, gebrauchte und generalüberholte Waren, Vorbestellungen und altersbeschränkte Artikel sind ausgeschlossen.

Die schlankere Option ist seit 2026-04-08 die Warenkorbübergabe: Sie implementieren nur das Erstellen des Warenkorbs, Google übergibt den Warenkorb an Ihre Website, und weder ein Payment Handler noch ein Bestell-Webhook ist nötig.

Die eigentliche Grenze ist der Zugang. Der Checkout ist „für ausgewählte Händler verfügbar“, über ein Interessenformular für den Early Access, in dem Sie sich verpflichten, innerhalb von 30 Tagen zu beginnen, und akzeptieren, dass der Zugang „entzogen werden kann“, wenn Sie keine Fortschritte machen. Die Bedingungen für UCP Checkout gelten „nur für die Vereinigten Staaten“. Der Merchant-Center-Hub soll in Australien und Kanada „Anfang nächsten Jahres“ folgen; für andere Länder nennt Google kein Datum für den Checkout.

UCP außerhalb von Google

Das Microsoft Merchant Center akzeptiert seit dem 21. April 2026 UCP-fähige Feeds in den USA. Copilot Checkout braucht einen UCP-konformen Feed, nimmt englischsprachige Händler auf, die in Dollar an Käufer in den USA verkaufen, mit je einem PSP, und die zugehörige Shop-Einstellung ist als „Pilotphase nur für ausgewählte Kunden“ gekennzeichnet. Shopify stellt UCP über MCP bereit, unter https://{shop}/api/ucp/mcp, und hat seine älteren Tools für Katalog und Warenkorb entfernt. Eine Capability für Unterkunftsbuchungen wurde am 24. September 2026 als Entwurf gemergt und ist in keinem Release enthalten.

AP2: Das Agent Payments Protocol

AP2 ist kein dritter Weg zum Checkout. Seine Spezifikation sagt, es „fungiert als Sicherheitsfunktion innerhalb eines Commerce-Protokolls“ und sei „ausdrücklich so konzipiert, dass es mit dem Universal Commerce Protocol (UCP) kompatibel ist“. Version 0.1.0 erschien am 16. September 2025 und v0.2 am 28. April 2026, dem Tag, an dem Google AP2 an die FIDO Alliance übergab. Die Ankündigung der FIDO nennt eine Arbeitsgruppe Agentic Authentication und eine Arbeitsgruppe Payments unter dem Vorsitz von Mitgliedern von Mastercard und Visa und sagt, die Beiträge „werden geprüft und weiterentwickelt“. Die FIDO hat keine AP2-Spezifikation veröffentlicht. Das GitHub-Repository nimmt jetzt nur noch Beispiele und SDK-Änderungen an, und der letzte Commit war am 29. April.

Version 0.2 definiert ein Checkout Mandate (was gekauft wird) und ein Payment Mandate (die Zahlung, mit Beschränkungen wie payment.amount_range, payment.budget und payment.allowed_payees). Beide sind ein SD-JWT in einer geschlossenen und einer offenen Form (zum Beispiel mandate.payment.1 und mandate.payment.open.1). Im Modus Human Present genehmigt der Nutzer die geschlossenen Mandate. Im Modus Human Not Present genehmigt der Nutzer offene Mandate, die Beschränkungen festlegen und den öffentlichen Schlüssel des Agenten in einem Claim cnf tragen, und der Agent stellt die geschlossenen Mandate innerhalb dieser Grenzen zusammen. Tutorials über Intent und Cart Mandates beschreiben v0.1; diese Begriffe gibt es in v0.2 nicht mehr.

Innerhalb von UCP ist AP2 die Erweiterung dev.ucp.common.payment.ap2_mandate (vor 2026-08-25 dev.ucp.shopping.ap2_mandate). Sobald sie ausgehandelt ist, signiert der Händler seine Checkout-Antworten, die Plattform legt bei complete ein checkout_mandate und ein payment_mandate vor, und die Session ist „Security Locked“: Keine der beiden Seiten darf auf einen gewöhnlichen Checkout zurückfallen.

Noch verlangt niemand danach. Googles FAQ nennt AP2 „besonders nützlich für künftige Szenarien mit autonomen Transaktionen durch KI-Agenten“. Googles eigenes Agentenprofil listet Google Pay als einzigen Payment Handler und deklariert keine AP2-Capability, und auch sein Profil für 2026-08-25 hat keinen AP2-Eintrag. Kein Google-Produkt dokumentiert die Nutzung von AP2, für einen Händler gibt es also nichts zu bauen, bis eine Plattform es aushandelt.

Die benachbarten Protokolle

MCP

ACP und UCP können beide über MCP laufen, dessen aktuelle Spezifikation, 2026-07-28, Sessions und den Header Mcp-Session-Id abschafft, auf den Handshake initialize verzichtet, server/discover vorschreibt und einen Client eine Anfrage unter einer neuen ID erneut senden lässt, wenn sein Stream abbricht. Das Binding von ACP verlinkt noch den Transport von 2025-11-25. Eine Checkout-Session-ID ist genau das vom Server erzeugte Handle, das die neue Spezifikation erwartet, und ein complete, das mitten im Stream verloren geht, kommt als neue Anfrage zurück: Behandeln Sie Idempotency-Keys bei beiden Protokollen als Pflicht.

WebMCP

WebMCP ist ein vorgeschlagener Webstandard, mit dem eine Seite ihre eigenen Funktionen für Browser-Agenten bereitstellt. Shopify bietet den UCP-Checkout sowohl als Checkout MCP als auch als Checkout WebMCP an, mit demselben Checkout-Objekt, und empfiehlt Checkout MCP. Unser Leitfaden zu WebMCP behandelt seinen aktuellen Stand.

x402 und MPP

x402 und das Machine Payments Protocol, entworfen von Tempo und Stripe, berechnen einem Agenten pro HTTP-Anfrage eine Gebühr für eine API, für Daten oder für Inhalte. Sie sind keine Checkout-Protokolle für Shops. Siehe unseren Artikel zu x402.

Visa Trusted Agent Protocol und Mastercard Agent Pay

Diese stehen neben ACP und UCP, statt sie zu ersetzen. Visas Trusted Agent Protocol gibt einem Agenten „eine standardisierte, kryptografische Methode“, um Händlern seine Identität und Autorisierung nachzuweisen, und Mastercard Agent Pay ist ein Tokenisierungsprogramm für Agentic Commerce. Mastercards Leitfaden für Händler ordnet UCP und ACP der höchsten Reifestufe zu, merkt an, dass „Early Adopters derzeit integrieren“, und rät Händlern, mit den beiden einfacheren Stufen zu beginnen. Unser Artikel zu Agentic Payments behandelt beide Programme.

Personal Agent Protocol

Sierra gibt an, das Personal Agent Protocol („Poppy“) am 6. Oktober 2026 gemeinsam mit Meta angekündigt zu haben, und veröffentlichte am 9. Oktober einen Entwurf. Ein Unternehmen veröffentlicht eine einzige Datei unter /.well-known/poppy.json; das Protokoll nutzt OAuth, JWTs, HTTPS, OpenAPI und MCP, damit sich ein persönlicher Agent ausweisen und für jede Art von Aufgabe die Erlaubnis des Kunden einholen kann, und Sierra bezeichnet es als Ergänzung zu UCP. Die Website des Protokolls zeigt Version 0.2 und sagt: „Es ist ein Entwurf“. Im eigenen Newsroom von Meta haben wir keinen Beitrag dazu gefunden.

Welches Protokoll brauchen Sie?

Auf Shopify

Nichts zu bauen. Shopifys Agentic Storefronts sind „für berechtigte Shops standardmäßig aktiv“. ChatGPT erhält Ihren Katalog über Shopify Catalog und schickt Käufer in Ihren Shop. Googles direkter Checkout ist standardmäßig eingeschaltet für Shops, die in den USA ansässig sind und in die USA verkaufen, und Copilot hat Shopify-Händler automatisch aufgenommen. Zu entscheiden bleiben Ihre Produktdaten und die Frage, ob Sie den direkten Checkout eingeschaltet lassen, im Wissen, dass benutzerdefinierte Pixel in Googles Checkout nicht auslösen.

Auf Salesforce, commercetools oder einer anderen Plattform

Salesforce B2C Commerce 26.9 liefert UCP aus, in den Versionen 2026-01-23 und 2026-04-08: /.well-known/ucp mit einer Zuordnung supported_versions und die Endpoints für Checkout-Sessions hinter einem SLAS-Token. Salesforce führt den UCP-Checkout bei Google im Oktober 2026 als allgemein verfügbar. Eine Session ist eine Headless-Sicht auf einen Warenkorb, und Salesforces Audit-Leitfaden warnt, dass SFRA- und SiteGenesis-Controller und „andere SCAPI-Ressourcen, die Sie heute verwenden, in diesem Ablauf nicht laufen“; Logik, die daran hängt, muss also kopiert oder über eine Brücke an die Hooks der UCP-Checkout-Session angebunden werden. Der Feed muss auf en-US ausgerichtet sein, und Salesforce „überspringt nicht Googles Warteliste“. Für ChatGPT ist Salesforce einer der Lieferwege, die OpenAI für ACP-Feeds nennt.

Auf commercetools oder einer anderen Plattform fragen Sie den Anbieter, welche UCP-Versionen und Capabilities er ausliefert, welche Ihrer Hooks in einem Checkout durch Agenten laufen und ob er Feeds an OpenAI sendet.

Auf eigener Software

1. Zuerst die Feeds. Google Merchant Center und, sobald OpenAI Sie zulässt, dessen Produktfeed. Die kommerzielle Nutzung von ACP in ChatGPT besteht heute genau darin.
2. UCP für Google, wenn Sie in den USA verkaufen und Google Sie zulässt. Bauen Sie nach 2026-04-08: das Profil mit com.google.pay, die Checkout-Operationen innerhalb von Googles Latenzzielen, einen PSP, der Google-Pay-Tokens verarbeitet, den Bestell-Webhook und das Feed-Attribut. Oder beginnen Sie allein mit der Warenkorbübergabe.
3. ACP-Checkout nur mit gutem Grund, etwa wenn eine ChatGPT-App zur Beta des Zahlungsfensters zugelassen ist. Bauen Sie nach 2026-04-17 aus dem Repository.
4. AP2: vorerst nichts.
5. Ein Checkout-Kern. Beide Protokolle wollen eine Session, die sich über eine API erstellen, aktualisieren, abschließen und abbrechen und gefahrlos wiederholen lässt. Bauen Sie sie einmal über Ihrer Bestell-, Steuer- und Zahlungslogik, mit schlanken Adaptern für ACP und UCP darüber und MCP, wo Agenten es brauchen.

Keines der beiden Protokolle bietet einem Abo-Geschäft heute einen nativen Checkout durch Agenten.

Verkauf nur außerhalb der USA

Keines der drei bietet Ihnen heute einen Checkout durch Agenten. ChatGPT-Shopping und OpenAIs Standard-Upload für Feeds gelten für die USA; Googles Bedingungen für UCP Checkout gelten nur für die USA; Copilot Checkout bedient Käufer in den USA, in Dollar. Googles nächster angekündigter Schritt ist der Merchant-Center-Hub in Australien und Kanada „Anfang nächsten Jahres“, ohne Datum für das Vereinigte Königreich oder die EU.

Halten Sie Ihren Merchant-Center-Feed vollständig, und wenn Sie Ihren Checkout ohnehin neu bauen, bauen Sie den oben beschriebenen API-gesteuerten Kern, damit ein Adapter eine kleine Aufgabe ist, sobald sich Ihr Markt öffnet. Sie verkaufen aus dem Ausland in die USA? Prüfen Sie bei jedem Programm, wo der Händler ansässig sein muss; Shopifys direkter Checkout bei Google zum Beispiel setzt einen Shop in den USA voraus.

Wo Sie Hilfe bekommen

Wir bauen die Protokollschicht für Shops, die nicht auf Shopify laufen: ein Profil unter /.well-known/ucp und Endpoints für Checkout-Sessions auf Ihrer bestehenden Bestell-, Steuer- und Zahlungslogik, Bestell-Webhooks an Google, Produktfeeds für Google Merchant Center und OpenAI sowie MCP-Server, die denselben Checkout für Agenten bereitstellen. Unsere Leistung zur Entwicklung von KI-Agenten und MCP-Integration ist der Ausgangspunkt für diese Arbeit.

Schreiben Sie an office@c9group.dev, mit Ihrer Plattform, Ihrem Zahlungsanbieter und den Ländern, in die Sie verkaufen, und wir sagen Ihnen, welches Protokoll für Sie gilt und was die Implementierung erfordern würde. Die Programmbedingungen von Google und OpenAI sind Verträge: Wir sind Ingenieure, keine Juristen, lassen Sie sie deshalb von einem Berater lesen, bevor Sie unterschreiben.