Der Stand der Standards für Agentic Commerce, Mitte 2026

Agentic Commerce hat irgendwann Ende 2025 aufgehört, ein Gedankenexperiment zu sein. Mitte 2026 lautet die Frage nicht mehr, ob KI-Agenten im Auftrag von Käufern transagieren, sondern welche Standards sie dabei sprechen. Die ehrliche Antwort heute: mehrere zugleich. Dies ist eine Momentaufnahme des Stands der wichtigsten Protokolle, der jüngsten Releases und einer konkreten Spezifikationslücke, die wir schließen halfen.

Drei koexistierende Protokolle

Die wichtigste Tatsache der Standardlandschaft ist, dass es keinen einzelnen Gewinner gibt — und Händler, die auf einen einzigen setzen, werden zu kurz kommen. Drei Protokolle besetzen unterschiedliche, aber überlappende Ebenen.

MCP — Model Context Protocol. Bei Anthropic entstanden und vollständig offen, ist MCP die Ebene, die Werkzeuge und Daten eines Systems einem LLM-Agenten zugänglich macht. Die Adoption ist die steilste der drei: SDK-Downloads stiegen von rund 100K pro Monat zum Start auf zweistellige Millionenzahlen pro Monat Anfang 2026, mit heute Tausenden öffentlichen MCP-Servern. WooCommerce lieferte ein natives MCP in Version 10.3, und WordPress 7.0 standardisierte die zugrunde liegende Abilities API für das gesamte Ökosystem.

ACP — Agentic Commerce Protocol. Getragen von Stripe und OpenAI und unter Apache 2.0 veröffentlicht, konzentriert sich ACP auf die Kauftransaktion selbst — den Checkout- und Zahlungs-Handshake zwischen Agent und Händler.

UCP — Universal Commerce Protocol. Getragen von Google und Shopify, ebenfalls Apache 2.0, definiert UCP den End-to-End-Commerce-Flow einschließlich einer formalen Checkout-Zustandsmaschine. Es ist das Protokoll, in dem ein Großteil der schwierigen transaktionalen Grenzfälle derzeit öffentlich ausgearbeitet wird.

Diese drei sind weder austauschbar noch schließen sie sich gegenseitig aus. Ein Multichannel-Händler muss Mitte 2026 MCP, ACP und UCP gleichzeitig denken, denn unterschiedliche Agenten und Plattformen erreichen ihn durch unterschiedliche Türen.

AP2: die darunterliegende Mandatsebene

Unter den Transaktionsprotokollen liegt AP2, das Mandatsmodell für Agentenzahlungen. AP2 führt signierte Intent- und Cart-Mandate ein: kryptografische Belege, dass ein Käufer einen bestimmten Kauf autorisiert hat, versehen mit einer Time-to-Live (TTL). Das Cart-Mandat ist der unbestreitbare Autorisierungsnachweis des Händlers — das Artefakt, das eine strittige Agententransaktion verteidigbar macht. Wie wir sehen werden, konzentriert sich genau um den Lebenszyklus dieses Mandats ein Großteil der aktuellen Spezifikationsarbeit.

Was zuletzt erschienen ist

WordPress 7.0 (Mai 2026) standardisierte die Abilities API plattformweit und gibt jedem WordPress- und WooCommerce-Shop eine gemeinsame Art, Fähigkeiten gegenüber Agenten offenzulegen.

WooCommerce 10.7 (April 2026) ergänzte native ACP-Unterstützung über ein agentic_commerce-Flag an Zahlungsgateways, nach dem WooCommerce-MCP aus 10.3.

3DS2 in UCP wird zu einem erstklassigen Szenario (verfolgt in den UCP-Issues #420 und #421). Das wiegt schwerer, als es klingt: Eine 3-D-Secure-Challenge kann Minuten dauern, wenn der Käufer unterbrochen wird — was lange Abschlüsse vom Grenzfall zum Normalfall macht.

Eine Lücke, die wir schließen halfen: Mandatsablauf mitten im Checkout

Beim Implementieren eines UCP-Händlerservers für Long-Tail-Händler (außerhalb von Shopify) stießen wir auf eine Frage, die die Spezifikation nicht beantwortete, und eröffneten sie als UCP-Issue #512: Was passiert, wenn ein AP2-Mandat seine TTL nach der Annahme von Complete Checkout, aber vor Abschluss der Zahlung erreicht — während der Checkout in complete_in_progress ist?

Das ist nicht theoretisch. Asynchrone europäische Zahlungswege (SEPA-Lastschrift, iDEAL, Bancontact), unterbrochene 3DS-Challenges und PSP-Wiederholungen bei weichen Ablehnungen schieben die Verarbeitung regelmäßig über die verbleibende Lebensdauer eines Mandats hinaus. Ohne normative Antwort würden identische Checkouts auf einem Händlerstack gelingen und auf einem anderen scheitern — und eine gegen ein abgelaufenes Mandat autorisierte Zahlung würde genau den Prüfpfad schwächen, für den AP2 existiert.

Die Diskussion konvergierte zu einem sauberen Modell:

• Einmal prüfen, dann einfrieren. Die Mandats-TTL wird ein einziges Mal geprüft, bei Empfang von Complete Checkout. Nach der Annahme läuft die Verarbeitung bis zu einem Endzustand, unabhängig von späterem Ablauf. Dem liegt eine Trennung von Autorisierung und Liveness zugrunde: Die Annahme klärt die Autorisierung; die TTL steuert nur, ob der Grant betreten werden darf — nie, ob laufende Arbeit autorisiert bleibt.
• Verankert in AP2 und PSD2. AP2 bietet dem Käufer keinen protokollinternen Kanal, ein Mandat vor seiner TTL zu widerrufen; die TTL ist also eine vorab vereinbarte Grenze, kein Live-Widerrufssignal. Das spiegelt PSD2 wider, wo der Widerruf der Einwilligung (Art. 64) durch die Unwiderruflichkeit (Art. 80) begrenzt ist — die Annahme von Complete Checkout ist der natürliche Unwiderruflichkeitspunkt.
• Ein signiertes Endartefakt für den Ablauf. Ist ein Mandat bei der Annahme bereits abgelaufen, tritt der Checkout nie in complete_in_progress ein; stattdessen wird eine signierte EXPIRED-Stornoquittung zum Endzustand, aus einem geschlossenen Enum (USER_REQUESTED / MERCHANT_REQUESTED / COMPLIANCE_TERMINATED / EXPIRED).
• Ein Prüfpfad, zwei Ausgänge. Die positive aufgezeichnete Auswertung (autorisiert-und-ausgeführt) und die EXPIRED-Quittung sind Geschwister: dieselbe signierte Beweisform, über einen einzigen Pfad geprüft — JCS-Kanonisierung (RFC 8785) plus Ed25519 — statt durch zwei eigene Prüfer.
• Vom Händler deklarierte Policy. Das Capability-Profil bewirbt die Policy, ein optionales min_remaining_ttl und das Signaturprofil, damit eine Plattform die Regeln kennt, bevor sie Complete Checkout aufruft.

Der nächste Schritt ist normativer Spezifikationstext: ein gemeinsames, versioniertes Quittungs-Envelope mit einem receipt_type-Diskriminator, ein gemeinsames Bindungsfeld, das beide Quittungen an denselben Checkout knüpft, und getrennte, normativ separierte Zeitstempel, damit das Widerrufs-Timing auditierbar bleibt. Eine kleine Änderung mit überproportionaler Wirkung: der Unterschied zwischen einem deterministischen, verteidigbaren Prüfpfad und einem Haufen divergierenden PSP-Verhaltens. Das vollständige Lebenszyklus-Modell — die Regel einmal-prüfen-dann-einfrieren, der eine Prüfpfad hinter beiden Ausgängen und das Händler-Capability-Profil — dokumentieren wir auf unserer UCP-mandate-evaluation-Referenzseite.

Was das für Händler bedeutet

Sie müssen keinen Protokollgewinner küren, denn so bald wird es keinen geben. Sie müssen über alle hinweg lesbar und transagierbar sein, und Ihre Plattform — oder Ihre Audit-Ebene — muss die unscheinbaren Grenzfälle wie den Mandatsablauf korrekt behandeln. Die Standards reifen schnell und öffentlich, und die Händler, die den Spezifikationsdiskussionen folgen, sind jene, die die nächste normative Änderung nicht überrascht.

MerchantStamp-Audits prüfen die Katalog- und Storefront-Bereitschaft gegen MCP, ACP und UCP nebeneinander, damit Sie sehen, wo Sie an jeder Tür stehen, die ein Agent nutzen könnte. Starten Sie einen kostenlosen Scan, um Ihren aktuellen Status zu prüfen.