Spezifikation ≠ SDK ≠ Produktionszugang

Protokolle verstehen.
Passend integrieren.

Nicht jede Spezifikation löst dieselbe Aufgabe. Dieser Wegweiser trennt Commerce, Agentenzugriff, Autorisierung, Oberflächen und maschinelle Zahlungen – mit Originalquellen und konkreten Implementierungswegen.

16 kuratierte Einträge · Quellenprüfung · Deutsch

Eine Einkaufskette. Mehrere Aufgaben.

  1. Zugang & WerkzeugeWie findet ein Agent die angebotenen Fähigkeiten und erreicht sie?
  2. Commerce & ErlebnisWie werden Varianten, Angebot, Checkout und Bestellung beschrieben?
  3. Berechtigung & ZahlungWas wurde erlaubt, wer darf handeln, und wie wird bezahlt?

Die Schichten ergänzen sich. Ein Zahlungsnachweis ersetzt weder einen belastbaren Warenkorb noch eine Kundenfreigabe. Der Protokollpass im Buch bietet den größeren Zusammenhang.

Der Katalog

Ein Sprachfilter findet auch Community-Bibliotheken und Samples. Den Artefakttyp und offene Grenzen sehen Sie auf der Detailseite.

Commerce & CheckoutBeta · Snapshot 2026-04-17

ACP

Agentic Commerce Protocol

ACP beschreibt den Austausch rund um einen agentengestützten Checkout. Händler können ihren Commerce-Kern anbinden, während Käuferagenten Angebote und Bestellschritte in einer gemeinsamen Struktur verstehen. Die entscheidende Arbeit bleibt, diese Struktur mit tatsächlichen Preisen, Beständen und Bestellzuständen zu verbinden.

Veröffentlicht: 2026-04-17
Arbeitsfassung: unreleased
Details & SDKs ↗
Commerce & CheckoutVeröffentlicht · v2026-08-25

UCP

Universal Commerce Protocol

UCP macht Handelsfähigkeiten auffindbar und verhandelbar: etwa Katalog, Warenkorb, Checkout und Bestellung. Der Händler erklärt, welche Fähigkeiten und Erweiterungen er unterstützt. Für die Integration ist nicht allein der Protokollname entscheidend, sondern die tatsächlich gemeinsame Kombination aus Version, Fähigkeit und Transport.

Veröffentlicht: v2026-08-25Details & SDKs ↗
Mandate, Identität & KundenzugriffVeröffentlicht · 0.2.0

AP2

Agent Payments Protocol

AP2 adressiert die Frage, wozu ein Agent beim Kauf und Bezahlen tatsächlich ermächtigt wurde. Verifizierbare Mandate sollen die Freigabe mit der ausgeführten Handlung verbinden. Das ist eine Autorisierungsschicht, nicht die Produktberatung oder der Zahlungsverkehr selbst.

Veröffentlicht: 0.2.0Details & SDKs ↗
Mandate, Identität & KundenzugriffDokumentiert · offizielles Sample

Visa TAP

Trusted Agent Protocol

TAP hilft einem Händler, signierte Agentenidentität und zugehörigen Kontext an seiner Web- oder API-Grenze zu prüfen. So kann eine Integration Agentenzugriffe anders behandeln als unbekannte Automatisierung. Die Identitätsprüfung bleibt von der fachlichen Kaufentscheidung zu unterscheiden.

Releaseversion: nicht verifiziertDetails & SDKs ↗
Mandate, Identität & KundenzugriffDraft v0.1 · Referenz-SDK Alpha

Verifiable Intent

Verifiable Intent

Verifiable Intent verbindet eine Benutzerfreigabe mit nachfolgenden Agentenhandlungen über eine kryptografische Delegationskette. Der Ansatz verwendet SD-JWT und macht die Grenzen einer Delegation prüfbar. Für Händler ist besonders wichtig, was genau bewiesen wird – und welche Geschäftsentscheidung trotzdem ihre eigene bleibt.

Veröffentlicht: 0.1.0 (Changelog)
Arbeitsfassung: v0.1
Details & SDKs ↗
Maschinelle ZahlungenSpezifikationsfamilie v2

x402

x402 Payment Protocol

x402 verbindet den Zugriff auf eine Ressource mit einer Zahlungsanforderung und einem Zahlungsnachweis, typischerweise über HTTP 402. Das ist besonders für bezahlte APIs und maschinell abgerufene Leistungen relevant. Welche Netze und Zahlungsarten verfügbar sind, hängt von der konkreten Implementierung ab.

Veröffentlicht: v2Details & SDKs ↗
Maschinelle ZahlungenAktives Projekt · IETF-Entwurf abgelaufen

MPP

Machine Payments Protocol

MPP beschreibt maschinelle Zahlungen im Request-/Response-Fluss und trennt den allgemeinen Ablauf von konkreten Zahlungsmethoden. Das Projekt umfasst einmalige Zahlungen und Sessions. Ein aktives SDK-Ökosystem und der formale Status eines Standardisierungsdokuments sind dabei unterschiedliche Dinge.

Releaseversion: nicht verifiziert
Arbeitsfassung: draft-ryan-httpauth-payment-01
Details & SDKs ↗
Mandate, Identität & KundenzugriffVeröffentlichter Draft 0.1 · Draft 0.2 in Arbeit

Poppy

Personal Agent Protocol (früher PAP)

Poppy soll persönliche Agenten mit Unternehmen verbinden: Discovery, Sessions, Sign-in und Handeln über Unternehmensschnittstellen. Der Fokus liegt auf längerfristiger Kundenvertretung statt nur auf einem einzelnen Checkout. Die öffentliche Entwicklung ist noch jung; veröffentlichter Draft und laufende Überarbeitung müssen sichtbar getrennt bleiben.

Veröffentlicht: 0.1 (veröffentlichter Draft)
Arbeitsfassung: 0.2
Details & SDKs ↗
Mandate, Identität & KundenzugriffFrühes Projekt · keine stabile Version verifiziert

PACT

Personal Agent Consent & Trust

PACT verbindet eine verifizierbare persönliche Agentenidentität mit ausdrücklich delegierten Kundenrechten. Es baut auf A2A und OAuth auf. Für Händler liegt der Nutzen in einer klareren Trennung: Wer ist der Agent, für wen handelt er und welche Handlung wurde tatsächlich erlaubt?

Releaseversion: nicht verifiziertDetails & SDKs ↗
Transport & WerkzeugeRevision 2026-07-28

MCP

Model Context Protocol

MCP verbindet Agentenanwendungen mit Werkzeugen, Ressourcen und Kontext. Ein Händler kann darüber zum Beispiel eine Bestandsabfrage oder einen Beratungsdienst zugänglich machen. Das Protokoll liefert den Integrationsrahmen, nicht die fachliche Bedeutung eines verbindlichen Kaufabschlusses.

Veröffentlicht: 2026-07-28Details & SDKs ↗
Transport & WerkzeugeVeröffentlicht · v1.0.1

A2A

Agent2Agent Protocol

A2A organisiert Kommunikation und Aufgaben zwischen Agentenanwendungen. Ein Einkaufsassistent kann dadurch mit einem Unternehmensagenten zusammenarbeiten, ohne dessen interne Umsetzung zu kennen. Welche Rechte eine Anfrage hat und wie ein Kauf verbucht wird, muss die angebundene Fachanwendung trotzdem entscheiden.

Veröffentlicht: v1.0.1Details & SDKs ↗
Experience & OberflächeFrühes Projekt · README-Version 2026-01-13

AXP

Agentic Experience Protocol

AXP des Agentic Commerce Lab beschreibt zusätzliche Produktinformationen, Qualitätssignale und eingebettete Erlebnisse für agentengestützten Handel. Varianten, Konfiguratoren oder interaktive Produktdarstellungen sollen nicht in einer bloßen Textantwort verschwinden. Das Projekt ist als frühe Community-Arbeit einzuordnen.

Releaseversion: nicht verifiziertDetails & SDKs ↗
Experience & OberflächeOffizielle MCP-Erweiterung

MCP Apps

MCP Apps Extension

MCP Apps ergänzt Werkzeugaufrufe um interaktive Oberflächen im Agenten-Host. Für Commerce kommen etwa Variantenwahl, Konfiguratoren und Produktansichten infrage. Der Mehrwert liegt darin, eine geeignete Interaktion direkt an den fachlichen Werkzeugaufruf anzuschließen.

Releaseversion: nicht verifiziertDetails & SDKs ↗
Transport & WerkzeugeExperimentell · Community Group Draft

WebMCP

WebMCP – strukturierte Browserwerkzeuge

WebMCP beschreibt, wie eine Website strukturierte Werkzeuge für Browseragenten anbieten kann. Statt allein aus sichtbaren Oberflächen zu schließen, kann ein Agent explizit beschriebene Funktionen verwenden. Für Händler ist das eine Browser-Integrationsschicht – mit weiterhin eigenen Regeln für Berechtigungen und Kaufaktionen.

Releaseversion: nicht verifiziert
Arbeitsfassung: Draft Community Group Report vom 20.10.2026
Details & SDKs ↗
Maschinelle ZahlungenSpezifikation vorhanden · SDK-Release offen

L402

Lightning-basierte API-Zahlung und Authentifizierung

L402 verbindet Lightning-Zahlungen mit authentifiziertem Zugriff auf APIs. Es ist nicht erst für KI-Agenten entstanden, kann aber maschinell konsumierte Leistungen abrechenbar machen. Der Einsatz setzt eine passende Lightning-Infrastruktur und eine bewusste Behandlung von Zahlungs- und Zugriffsrechten voraus.

Releaseversion: nicht verifiziertDetails & SDKs ↗
Maschinelle ZahlungenImplementierungsökosystem · Version nicht verifiziert

ATXP

Agent Transaction Protocol

ATXP ist ein Implementierungsökosystem für kostenpflichtige Agentenwerkzeuge, unter anderem im MCP-Umfeld. Client-, Server- und Integrationspakete verbinden Werkzeugzugriff mit einer Zahlungsinfrastruktur. Der offene Code und die Bedingungen des betriebenen Dienstes sollten getrennt bewertet werden.

Releaseversion: nicht verifiziertDetails & SDKs ↗