ADI
ADI Blog AP2-Payments 2 Min. Lesezeit

Was AP2 für Agent Commerce löst

AP2 gibt Agent Commerce ein strukturiertes Modell für Intent, Cart, Payment-Autorisierung und Receipts. Ohne dieses Modell erfindet jede Agenten-Payment-Integration ihre eigene fragile Semantik.

AP2 macht aus „der Agent hat bezahlt“ eine nachvollziehbare Folge von Mandaten, Freigaben und Payment-Kontext.

Das Protokoll ist wichtig, weil Agent Commerce nicht nur Kartenverarbeitung ist, sondern delegierte wirtschaftliche Handlung.

AP2 ist der Punkt, an dem Trust und Payment-Verhalten zusammenkommen, nicht bloß ein Checkout-Widget für Bots.

Welches Problem AP2 tatsächlich löst

Wenn ein Agent im Namen einer Person oder eines Unternehmens einkauft, ist die schwierige Frage nicht, ob irgendeine Payment-API aufgerufen werden kann. Die schwierige Frage ist, was genau autorisiert wurde, in welchem kommerziellen Scope und wie diese Autorisierung später nachgewiesen wird.

Klassische Checkout-Modelle setzen einen direkt anwesenden Menschen voraus. Agent Commerce bricht diese Annahme. AP2 existiert, um die delegierte Payment-Intention standardisiert durch die Transaktion zu tragen.

Warum eine Payment-API allein nicht reicht

Eine Payment-API kann eine Karte belasten, aber sie erklärt nicht, warum der Agent dazu berechtigt war.

Ein PSP liefert einen Payment-Status, aber keinen Delegations- oder Mandatskontext.

Ein Merchant sieht vielleicht eine Autorisierung, braucht aber zusätzlich Evidenz über Mandate, Limits oder erlaubten Scope.

Ohne gemeinsames Modell erzeugt jede Gegenstelle inkompatible Agenten-Payment-Semantik.

Wie AP2 Agent Commerce strukturiert

AP2 beschreibt Commerce nicht als diffuses „Agent darf zahlen“, sondern über Mandate und Transaktionsobjekte. Dadurch entsteht eine Sprache dafür, was der Agent kaufen will, was schon freigegeben wurde und welcher finale Payment-Schritt tatsächlich ausgeführt werden darf.

AP2-Fluss in einer Sicht

AP2 springt nicht direkt vom Agentenwunsch zur Belastung. Es arbeitet über mandatgetragene Stufen.

flowchart LR
    intent["Intent-Kontext"] --> cart["Cart Mandate"]
    cart --> approval["Delegations- und Freigabekontext"]
    approval --> payment["Payment Mandate"]
    payment --> receipt["Receipt und Evidenz"]

Warum AP2 für Trust wichtig ist

Agent Commerce wird unbeherrschbar, wenn Payment-Ausführung von Trust-Evidenz entkoppelt ist. AP2 hilft, weil es dem kommerziellen Teil des Flows eine Struktur gibt, die gegen Policy, Certificates, Delegation und Receipts geprüft werden kann.

Genau dort wird eine Plattform wie ADI relevant: AP2 beschreibt das Zahlungs- und Mandatsverhalten, während ADI durchsetzt, wer es unter welchen Trust-Bedingungen nutzen darf.

Der praktische Mehrwert für Händler und Plattformen

Klarere Transaktionssemantik für agentengetriebene Käufe

Wiederverwendbares Modell für Freigaben und Limits

Bessere Grundlage für Audit, Streitfallanalyse und Enterprise-Kontrollen

Sauberere Brücke zwischen Trust-Systemen und Payment-Ausführung

WEITERLESEN

Weitere Artikel aus der technischen Wissensschicht.

OFFENE AGENTENVERTRAUENSKETTE Agenten-Interoperabilität

Wie externe Agenten einen ADI-Merchant-Agenten verifizieren

Ein Buyer-Agent muss nicht innerhalb von ADI laufen, um einem ADI-Merchant-Agenten zu vertrauen. Er braucht öffentliche Discovery, eine auflösbare Agentenidentität, signierte Credentials und einen klaren Mandats- und Payment-Pfad.

A2A-Discovery macht den Merchant-Agenten erreichbar.

ADI-Trust-Discovery macht den Merchant-Agenten zurechenbar.

MERCHANT TRUST Agent Commerce

Wie der Merchant-Trust-Katalog funktioniert

Ein Merchant-Agent kann aus dem Shop verkaufen, aber ADI braucht eine unabhängige Referenz dafür, was dieser Agent überhaupt verkaufen darf. Der Merchant-Katalog in ADI ist genau diese Referenz.

Der Shop-Katalog betreibt das Geschäft.

Der ADI-Katalog beweist, was der Händler freigegeben hat.

AP2-VALIDIERUNG Agent Commerce

Wie ADI validiert, was ein Merchant-Agent verkauft

Ein Merchant-Agent kann ein Angebot beschreiben, aber ADI zahlt nicht auf Basis einer Beschreibung. ADI validiert AP2-Mandate, Händlerorganisation, Produkt-SKU, Trust-Katalog, Buyer-Wallet und virtuelle Karten-Policy vor der Autorisierung.

Das Gespräch erzeugt Intent.

AP2 erzeugt strukturierte Mandate.

SHOP-INTEGRATIONEN Systemarchitektur

Warum Shop-Integrationen Trust-Inputs und nicht die Trust-Schicht sind

Shopify, WooCommerce oder ERP-Integrationen liefern wertvolle Commerce-Daten. Sie sind aber nicht die Trust-Schicht selbst. Sie speisen Trust-Entscheidungen mit Bestand, Preisen und Produktzuständen, ersetzen aber weder Delegation noch Governance.

Shop-Systeme liefern Daten.

Die Trust-Schicht bewertet Rechte, Scope und Kontrollfähigkeit.

INTEGRATIONSMODI Agenten-Integration

Drei Wege, einen externen Agenten mit der ADI-Trust-Schicht zu verbinden

Ein externer Agent muss nicht innerhalb von ADI laufen, um von ADI regiert zu werden. Entscheidend ist, wie das Zielsystem diesen Agenten technisch authentisiert und wann es ADI für Trust, Delegation und Zertifikatsstatus befragt.

Standardmodus: API-Key oder Agent-Token plus Online-Trust-Lookup

Enterprise-Modus: OIDC plus Trust-Lookup

TRUST-GRUNDLAGEN Agent Trust

Warum Agenten eine Trust-Schicht brauchen

Ein API-Token sagt nur, ob eine Anfrage authentisiert ist. Eine Trust-Schicht sagt, welcher Agent handelt, für wen er handelt, welche Nachweise gültig sind und ob dieser Agent gestoppt werden kann.

Wann OAuth nicht mehr ausreicht

Welche Fragen eine Trust-Schicht beantworten muss

ARCHITEKTUR Systemarchitektur

A2A, Trust und AP2 sauber trennen

Das zentrale Architekturprinzip ist die Trennung der Schichten. A2A ist Kommunikation. Trust ist Governance. AP2 ist das Verhalten im Zahlungs- und Mandatskontext.

Was A2A tatsächlich standardisiert

Wann zusätzlich Trust nötig ist

PRODUKT ADI-Stack

Wie ADI als Agent-Trust-Stack funktioniert

ADI ist keine einzelne Oberfläche. Es ist eine operative Schicht, die Discovery, Identität, Trust und Payment-Flows für agentische Systeme miteinander verbindet.

Die vier Schichten der Plattform

Wo A2A, MCP und AP2 zusammenkommen

A2A ERKLÄRT A2A-Grundlagen

Was A2A ist und was es nicht ist

A2A gibt Agenten eine gemeinsame Sprache für Discovery, Nachrichten und Tasks. Es löst aber nicht automatisch Identitätsbindung, delegierte Autorität, Auditierbarkeit oder Payment-Kontrolle.

A2A standardisiert Discovery, Nachrichten, Tasks und deklarierte Sicherheitsfähigkeiten.

A2A beantwortet nicht von selbst, wen ein Agent repräsentiert oder was er darf.

TRUST-GRUNDLAGEN Agent Trust

Was Agent Trust tatsächlich bedeutet

Agent Trust ist kein Marketingbegriff. Es ist die operative Fähigkeit zu beweisen, wer ein Agent ist, in wessen Namen er handelt, was er tun darf und wie diese Autorität widerrufen oder auditiert werden kann.

Trust beginnt dort, wo reine Authentisierung endet.

Eine echte Trust-Schicht muss Widerruf, Inspektion und Evidenz unterstützen.

PRODUKT-ERKLÄRUNG ADI-Stack

Was ADI in einem Agenten-Stack macht

ADI ist die Trust- und Kontrollschicht zwischen Agenten-Interoperabilität und echter Geschäftshandlung. Es hilft Organisationen, Agenten handeln zu lassen, ohne sie wie ungeregelte Black Boxes zu behandeln.

ADI ist der Punkt, an dem Governance in den Agenten-Stack eintritt.

Die Plattform verbindet externe Agenten, Enterprise-Kontrollen und Transaktionspolicies.

SIGNATUREN UND ESEALS Trust Services

Menschliche Signaturen vs. organisatorische eSeals

Eine menschliche Signatur beweist den Willen oder die Freigabe einer natürlichen Person. Ein organisatorisches eSeal beweist, dass ein Trust-Objekt von einer juristischen Person ausgestellt oder versiegelt wurde. In Enterprise-Agentensystemen sind das verschiedene Aufgaben.

Menschliche Signaturen beantworten: Wer hat persönlich zugestimmt?

OrganisationseSeals beantworten: Welche juristische Person steht hinter diesem Artefakt?