ACP (Agentic Commerce Protocol)

Was die Spezifikation tatsächlich benennt

ACP ist das handelsspezifischste der Protokolle in diesem Bereich, und die einfachste Art, es sich zu merken, ist als Liste von Objekten und nicht als Philosophie. Die Revision vom April 2026 umfasst einen Produktfeed, eine Checkout-Sitzung, Zahlungsdelegation, Warenkorb und Authentifizierung sowie einen Integrations-Hook, der es einem ACP-fähigen Agenten ermöglicht, seine Checkout-Fähigkeit durch die MCP-Tool-Erkennung zu bewerben.

Jedes Objekt existiert, weil ein Schritt, den eine Person in einem Browser ausführt, kein maschinelles Äquivalent hat. Eine Person durchsucht einen Katalog; ein Agent benötigt einen Feed. Eine Person sieht, wie sich eine Gesamtsumme zusammensetzt, während sie eine Adresse eingibt; ein Agent benötigt eine Sitzung, die eine verbindliche Summe zurückgibt. Eine Person gibt eine Karte in ein Formular auf Ihrer Domain ein; ein Agent benötigt eine definierte Methode, um die Zahlung an Ihren Prozessor zu übergeben, ohne die Anmeldeinformationen selbst zu speichern.

Die Herausgeber sind OpenAI und Stripe, und diese Paarung ist in der Form des Dokuments sichtbar. Es wurde von einer Partei verfasst, die eine Assistentenoberfläche besitzt, und einer Partei, die die Zahlungsabwicklung besitzt, und das meiste, was es spezifiziert, ist die Grenze zwischen den beiden.

Wo ACP im Verhältnis zu UCP, AP2 und MCP steht

Die vier Namen werden üblicherweise als Standardisierungskrieg dargestellt, was Händler zu dem falschen Schluss führt — dass der vernünftige Schritt darin besteht, auf einen Gewinner zu warten. Sie beantworten unterschiedliche Fragen und ergänzen sich weitgehend.

MCP, veröffentlicht von Anthropic, ist der allgemeine Mechanismus, durch den ein Agent erfährt, dass eine Fähigkeit existiert und wie man sie aufruft; es sagt nichts über Warenkörbe oder Geld aus. UCP, von Google und Shopify, deckt Kataloglesevorgänge und Warenkorbkonstruktion ab. ACP deckt die Checkout-Ausführung und Zahlungsdelegation ab. AP2, von Google initiiert und im April 2026 an die FIDO Alliance gespendet, deckt den Nachweis ab, dass ein bestimmter Mensch eine bestimmte Zahlung autorisiert hat.

Das Sponsoring erklärt die Abdeckung in jedem Fall. Google und Shopify benötigen Agenten, die die Kataloge der Welt lesen können, daher spezifiziert ihr Standard die Erkennung. OpenAI und Stripe benötigen, dass ein Kauf irgendwo abgeschlossen wird, daher spezifiziert ihr Standard Checkout und Zahlung. Niemand hat eine Spezifikation für eine Schicht geschrieben, die er nicht bereits besaß.

Die eine erwähnenswerte Überschneidung ist die Warenkorbgrenze, wo UCP und ACP beide etwas zu sagen haben. Die zugrunde liegende Anforderung auf Händlerseite ist in beiden Fällen identisch — ein Katalog, der echte Preise und echte Verfügbarkeit enthält — weshalb dieser Teil der Arbeit der einzige Teil des Stacks ist, der keine Wette darauf ist, welcher Standard sich durchsetzt.

Zahlungsdelegation ist der wirklich neue Teil

Produktfeeds sind nicht neu und Checkout-Endpunkte sind nicht neu. Das Element von ACP ohne vorheriges Äquivalent ist die Zahlungsdelegation: Die Umgebung des Agenten übergibt die Verarbeitung an den Prozessor des Händlers, anstatt Karteninformationen zu speichern oder selbst zum Merchant of Record zu werden.

Diese Anordnung macht das Protokoll für Händler überhaupt erst akzeptabel. Sie behalten die Prozessorbeziehung, die Abrechnung und den Kundendatensatz. Sie behalten auch die Haftung, und das ist die Hälfte, die es wert ist, zweimal gelesen zu werden — ein von einem Agenten initiierter Kauf und ein von einem Menschen initiierter Kauf erreichen Ihren Prozessor über dieselben Wege, während die heute existierenden Formate für Streitbeilegung alle davon ausgehen, dass eine Person bei der Transaktion anwesend war.

Diese Lücke ist genau das, wofür AP2 geschrieben wurde, um sie zu schließen, und sie wird auf der ACP-Schicht nicht behandelt. Ein Händler, der jetzt von Agenten initiierte Zahlungen akzeptiert, akzeptiert diese ohne ein Standardartefakt, das festlegt, was der Karteninhaber autorisiert hat oder innerhalb welcher Grenzen.

Was ACP nicht spezifiziert

Eine Spezifikation danach zu lesen, was sie weglässt, ist oft informativer, als sie danach zu lesen, was sie enthält, und die Auslassungen hier sind groß genug, um zu ändern, was der Ausdruck „ACP-Unterstützung“ ehrlich bedeuten kann.

Sie ziehen auch die Grenze zwischen der Bereitstellung der Voraussetzungen und der Implementierung des Protokolls. Ein maschinenlesbarer Katalog, ein bereichsspezifisches Agenten-Gateway und eine Reihe von MCP-Tools sind Dinge, die ACP von einem Händler bereits annimmt. Diese zu haben ist Vorarbeit und keine Konformität, und eine Plattform, die beides als dieselbe Behauptung darstellt, übertreibt, was sie leistet.

Was die Spezifikation ganz Ihnen überlässt:

• Vertrauen. Nichts darin entscheidet, welche Agenten Sie bedienen sollen oder zu welchen Bedingungen. Das ist eine Richtlinie, die Sie selbst erstellen und durchsetzen.
• Autorisierung und Audit. Es definiert keine Berechtigungsbereiche, keine Idempotenzanforderung und keinen Audit-Datensatz. Ein Agent, der eine mehrdeutige Anfrage wiederholt, ist ein gewöhnliches Ereignis, und nichts im Protokoll verhindert, dass daraus zwei Bestellungen werden.
• Die Hälfte nach dem Kauf. Retouren, Rückerstattungen, Stornierungen, Abonnementänderungen und Support liegen außerhalb seines Geltungsbereichs, und dort entstehen die meisten Betriebskosten einer Bestellung.
• Akzeptanz. Eine konforme Implementierung verpflichtet keinen Assistenten, sie zu nutzen. Welche Oberflächen was in welchen Kategorien lesen, ist eine kommerzielle Angelegenheit, die keine Spezifikation regelt.