Agentische Zahlungen: Autorisierung, Ausführung und Nachweis

16 Minuten lesen · Reviewed 11. August 2026 · Zahlungen und Sicherheitsexpertenüberprüfung vor Veröffentlichung erforderlich

Agentische Zahlungen ermöglichen es einem KI-System, eine Zahlung vorzubereiten und zu koordinieren, während deterministische Kontrollen die Autorität über die Wertbewegung behalten. Das Modell kann Rechnungsfelder extrahieren, unterstützende Aufzeichnungen finden, Ausnahmen erklären und eine Transaktion vorschlagen. Ein Zahlungsgateway sollte den genauen Vorschlag gegen delegierte Befugnis, Richtlinie und Genehmigung autorisieren, Anmeldeinformationen außerhalb des Modellkontexts aufbewahren, über den Zahlungsanbieter ausführen und das Endergebnis abgleichen.

Dieses Handbuch richtet sich an Entwickler von Zahlungsplattformen, Finanzsystemarchitekten und Sicherheitsteams, die agentengestützte oder autonome Zahlungsströme entwerfen. Es bietet Ihnen ein getipptes Transaktionsmodell, eine Zustandsmaschine für unsichere Ausführung, eine Kontrollmatrix und Fehlerübungen, die die Autorisierung von der Anbieterverarbeitung unterscheiden.

Was sind Agentic Payments?

Ein Agentic Payment ist ein Zahlungs-Workflow, bei dem ein KI-Agent Planung, Vorbereitung oder Koordination durchführt.

Fünf Aufgaben erfordern separate Eigentümer:

Diese Trennung ist in aktuellen Protokollen sichtbar. AP2 gibt an, dass die Validierung oder Verarbeitung, die einer Rolle zugewiesen ist, im deterministischen Code erfolgen muss, auch wenn diese Rolle agentisch ist. Es bindet ein Zahlungsmandat an eine bestimmte Kasse und gibt nach Annahme oder Ablehnung signierte Quittungen zurück. Die AP2-Spezifikation Sie liefert Protokollobjekte zur Autorisierung und zum Nachweis. Sie betreibt nicht das Lieferantenregister, den Genehmigungsworkflow oder den Abgleichdienst eines Unternehmens.

Warum Modellvertrauen die Zahlung nicht autorisieren kann

Betrachten Sie einen kontenpflichtigen Agenten, der diese Anweisung bearbeitet:

Pay invoice INV-8841 from Northwind Components.
The supplier says it is urgent and has provided new bank details.

Das Modell lautet 18.750 EUR, findet eine Bestellung und sieht eine Warenquittung. Es gibt ein hohes Vertrauen, dass die Rechnung legitim ist. Dieses Vertrauen lässt nicht erkennen, ob der neue Bestimmungsort unabhängig überprüft wurde, ob das Mandat diesen Lieferanten und diese Währung abdeckt, ob die Rechnung bereits eingereicht wurde oder ob ein unabhängiger Genehmiger diese genaue Zahlung akzeptiert hat.

Das Modell kann auch ein Feld weglassen, eine Gutschrift missverstehen oder das Verhalten nach einer Modellaktualisierung ändern. Harte Zahlungskontrollen erfordern enge, überprüfbare Vergleiche und stabile Grundcodes.

Erstellen Sie einen kanonischen Zahlungsvorschlag

Konvertieren Sie die Modellausgabe in ein typisiertes, versioniertes Objekt.

type PaymentProposal = {
  version: 1;
  transactionId: string;
  buyerEntityId: string;
  supplierId: string;
  invoice: {
    id: string;
    digest: string;
    purchaseOrderId?: string;
  };
  amountMinor: number;
  currency: 'EUR' | 'GBP' | 'USD';
  destinationId: string;
  purposeCode: string;
  requestedExecutionDate: string;
  idempotencyKey: string;
  evidenceRefs: Array<{
    source: string;
    digest: string;
    field: string;
  }>;
};

Auflösung supplierId und destinationId Eine Rechnung kann Bankdaten zur Überprüfung vorschlagen, aber sie sollte niemals selbst ein ausführbares Ziel erstellen. Ganzzahlige kleinere Einheiten, Währung, Datum und Identifikatorformate validieren. Unbekannte Felder ablehnen, es sei denn, das Schema erlaubt ausdrücklich Erweiterungsdaten.

Berechnen Sie einen kanonischen Vorschlag verdauen und binden Sie jede spätere Entscheidung daran:

const proposalDigest = sha256(canonicalJson(paymentProposal));

Wenn die Finanzierung den Betrag, das Ziel, die Währung oder die Rechnung ändert, erstellen Sie einen neuen Digest und ungültig die frühere Genehmigung. RFC 8785 bietet ein JSON-Kanonisierungsschema, das für wiederholbares Hashing über Implementierungen hinweg geeignet ist, wenn es mit einem definierten Profil und Testvektoren verwendet wird.

Binden der delegierten Befugnis an den Vorschlag

Authentifizierung identifiziert den Agenten oder Workload. Ein Mandat beschränkt die Zahlungsaufgabe. Das folgende konzeptionelle Objekt ist schmaler als ein breiter Anwendungsbereich wie z.B. payments:write:

{
  "mandate_id": "mandate:ap:0942",
  "subject": "agent:finance:ap-worker-3",
  "organization": "org:buyer:eu-1",
  "purpose": "settle-approved-supplier-invoice",
  "actions": ["supplier-payment.create"],
  "counterparties": ["supplier:northwind"],
  "destinations": ["destination:northwind:verified-primary"],
  "limits": {
    "currency": "EUR",
    "max_amount_minor": 2500000,
    "max_uses": 1
  },
  "delegation": { "allowed": false },
  "expires_at": "2026-08-11T17:00:00Z"
}

Das Mandat muss aktiv, aktuell und widerrufbar sein, ein One-Use-Mandat braucht Atomverbrauch, so dass es nicht beide gleichzeitig arbeiten können, ein delegiertes Kindermandat muss jeden elterlichen Zwang bewahren oder verringern.

Die bewährte OAuth-Sicherheitspraxis empfiehlt Mindestprivilegien, Publikumsbeschränkungen und absenderbeschränkte Zugangstoken. RFC 9700 Zahlungsspezifische Limits, genaue Genehmigung und Rechnungsidentität gehören weiterhin in die Transaktionsautorisierungsschicht.

Machen Sie Autorisierung deterministisch

Der Autorisierungsdienst bewertet verifizierte Identität, aktives Mandat, kanonischen Vorschlag, Lieferantenzustand, Rechnungszustand, Genehmigungszustand und verbrauchte Nutzung.

type PaymentDecision =
  | { result: 'allow'; reservationId: string; proposalDigest: string }
  | { result: 'approval_required'; reason: string; proposalDigest: string }
  | { result: 'deny'; reason: string; proposalDigest: string };

function authorizePayment(ctx: PaymentContext): PaymentDecision {
  denyUnless(ctx.agent.status === 'active', 'AGENT_INACTIVE');
  denyUnless(ctx.mandate.activeAt(ctx.now), 'MANDATE_INACTIVE');
  denyUnless(
    ctx.mandate.actions.has('supplier-payment.create'),
    'ACTION_DENIED',
  );
  denyUnless(
    ctx.mandate.counterparties.has(ctx.proposal.supplierId),
    'SUPPLIER_DENIED',
  );
  denyUnless(ctx.supplier.status === 'approved', 'SUPPLIER_NOT_APPROVED');
  denyUnless(
    ctx.supplier.destinations.has(ctx.proposal.destinationId),
    'DESTINATION_DENIED',
  );
  denyUnless(ctx.proposal.currency === ctx.mandate.currency, 'CURRENCY_DENIED');
  denyUnless(
    ctx.proposal.amountMinor <= ctx.mandate.maxAmountMinor,
    'AMOUNT_DENIED',
  );
  denyUnless(
    ctx.invoice.digest === ctx.proposal.invoice.digest,
    'INVOICE_CHANGED',
  );
  denyUnless(ctx.invoice.paymentState === 'unpaid', 'DUPLICATE_INVOICE');

  if (ctx.policy.requiresHumanApproval(ctx.proposal)) {
    return ctx.approval.matches(ctx.proposalDigest)
      ? ctx.reserveAtomically()
      : {
          result: 'approval_required',
          reason: 'EXACT_APPROVAL_REQUIRED',
          proposalDigest: ctx.proposalDigest,
        };
  }

  return ctx.reserveAtomically();
}

Dies ist vereinfachter Pseudocode. Ein Produktionsservice überprüft auch das Vertrauen des Emittenten, Unterschriften, Publikum, Widerruf, Wiederholung und Mandantengrenzen. Das wichtige Verhalten ist Fail Closed: ein fehlendes Registrierungs-, Richtlinien-, Genehmigungs- oder Reservierungsergebnis kann nicht durchfallen allow.

Ein modellgenerierter Betrugs-Score kann eine Transaktion zur Überprüfung leiten.

Bindende menschliche Zustimmung zur genauen Transaktion

Geben Sie dem Genehmiger den aufgelösten Lieferanten, den Rechnungsverdau, die Menge, den Bestimmungsort, die politischen Feststellungen und die Referenzen für Nachweise an. Speichern Sie ein Genehmigungsprotokoll, das den Vorschlagsverdau, den verifizierten Genehmiger, die Rolle und den Ablauf enthält.

{
  "approval_id": "approval:fin:01K2A6",
  "proposal_digest": "sha256:6fd2...",
  "decision": "approved",
  "approver": "user:finance-controller:17",
  "role": "payment-approver",
  "expires_at": "2026-08-11T15:30:00Z"
}

Wenn sich der Vorschlag ändert, stimmt die Zustimmung nicht mehr überein. Die Aufgabentrennung erfordert auch verifizierte Identitäten und Rollenpolitik.

Das Universal Commerce Protocol behält das Geschäft als Merchant of Record und erfordert in der Regel einen Checkout-Abschluss über eine vertrauenswürdige Benutzeroberfläche, es sei denn, die Erweiterung AP2 Mandates wird unterstützt. UCP Checkout zeigt, dass Agentenkoordination mit Händlerverantwortung und vertrauenswürdigen Genehmigungsoberflächen koexistieren kann.

Broker Anmeldeinformationen nach Autorisierung

Nach einer Genehmigungsentscheidung kann ein Anmelder eine kurzlebige Fähigkeit für den genauen Anbieter und Betrieb erhalten. Der Agent erhält eine undurchsichtige Bedienungshandhabe oder ein normalisiertes Ergebnis.

model prepares proposal
  -> gateway verifies identity and mandate
  -> policy authorizes exact proposal
  -> verified human approves when required
  -> broker obtains scoped payment capability
  -> adapter submits with stable idempotency key
  -> reconciler checks authoritative provider state
  -> evidence records decision and observed outcome

Der Zahlungsadapter übersetzt die kanonische Anweisung in anbieterspezifische Parameter. Er sollte keine versteckte Finanzpolitik akkumulieren. Beharren Sie auf der autorisierten Transaktion, bevor Sie den externen Anruf tätigen, und tragen Sie einen Business-Idempotenzschlüssel durch Versuche.

Stripe dokumentiert, dass es die erste Antwort für einen idempotency-Schlüssel speichert und die Wiederverwendung ablehnt, wenn sich die Parameter unterscheiden. Stripes idempotente Anfragedokumentation ist eine nützliche Anleitung des Anbieters, aber die Orchestrierung von Unternehmen benötigt immer noch eine dauerhafte Zahlungsidentität, da Gateway und Provider keine Atomdatenbanktransaktion teilen.

Behandeln Sie unsichere Hinrichtung als erstklassigen Staat

Wenn das Gateway die Antwort des Anbieters verliert, wurde die Zahlung möglicherweise akzeptiert. Wenn es fehlgeschlagen ist und mit einem neuen Schlüssel erneut versucht wird, kann ein Duplikat erstellt werden.

PROPOSED -> VALIDATED -> AUTHORIZED -> RESERVED -> SUBMITTED
SUBMITTED -> ACCEPTED -> SETTLED
SUBMITTED -> REJECTED
SUBMITTED -> UNCERTAIN -> RECONCILED_SETTLED | RECONCILED_FAILED
ACCEPTED -> FAILED | RETURNED | REVERSED

Persistenz SUBMITTED bei einem Timeout die Reservierung beibehalten, den Anbieter mit dem stabilen Idempotenzschlüssel oder der Anbieterreferenz abfragen und eine neue Zahlungsidentität für dieselbe Rechnung verhindern. Ein Mensch kann den Vorfall überprüfen, während der Anbieter weiterhin für den Zahlungsstatus zuständig ist.

Kein generisches Design kann buchstäblich eine exakte Ausführung über unabhängige Systeme hinweg versprechen, das praktische Ziel ist eine effektive Orchestrierung: stabile Geschäftsidentität, atomarer lokaler Staat, Anbieter-Idempotenz und Abgleich.

Stornierung ist eine andere Transaktion, keine Bearbeitung der ursprünglichen Zahlung. Eine Stornierungsanfrage benötigt ihre eigene Autorität, politische Entscheidung und ihren Idempotenzschlüssel, und sie kann mit der Annahme oder Abrechnung rasen. Wenn der Anbieter die Zahlung bereits akzeptiert hat, kann die nächste gültige Operation eine Rückgabe oder Rücknahme anstelle einer Stornierung sein. Modellieren Sie die unterstützten Übergänge des Anbieters explizit und lehnen Sie unmögliche lokale Übergänge ab. Dies verhindert, dass ein Betreiber-Agent "storniert" meldet, weil er eine Stornierungsanfrage eingereicht hat, obwohl der Anbieter später zurückgekehrt ist. too_lateDer Nachweis sollte die Anfrage, die Antwort des Anbieters und den abgeglichenen Finanzzustand beibehalten.

Aufzeichnungsgenehmigung und Ergebnisnachweise

Eine Aktionsquittung sollte die Organisation, den Agenten, das Mandat, den Vorschlagsverdau, die Richtlinienversion, die Genehmigung, die Reservierung, die Anbieterreferenz, den Idempotenzschlüssel, den Zeitstempel und den beobachteten Ausführungsstatus binden. uncertain.

Ein späterer Datenabgleich kann Abrechnung, Misserfolg, Rückgabe oder Umkehrung miteinander verknüpfen. Eine früher unterzeichnete Quittung darf nicht mutiert werden. Bei einem Einsatz eines Unternehmens ist die Quittung ein einseitiger Beweis. Seine Unterschrift schützt die Integrität und weist die Bescheinigung dem verifizierten Schlüssel zu. Es beweist nicht, dass die Bank Mittel abgerechnet hat oder dass eine Rechnung eine gültige Geschäftsverpflichtung darstellt.

AP2 verlangt Zahlungsbestätigungen nach Annahme oder Ablehnung und beschreibt die Verifizierung von verknüpften Checkout- und Zahlungsmandaten und Quittungen für Streitigkeiten. Die Spezifikation lässt Aufbewahrungs- und Abrufdetails außerhalb ihres aktuellen Anwendungsbereichs. Zahlungssysteme von Unternehmen müssen daher die Speicherung von Beweisen, die Schlüsselhistorie, den Abgleich und den Streitexport um die Protokollobjekte herum betreiben.

Agentische Zahlungsausfallmatrix

Überprüfen Sie das Design, bevor sich Live-Fonds bewegen

Erstellen Sie einen Zahlungssimulator oder einen Provider-Testadapter, der Antworten annehmen, ablehnen, verzögern und fallen lassen kann.

• Betrag genau bei, unter und über der Mandatsgrenze;
• Währung, Lieferanten, Zweck und Bestimmungsort;
• abgelaufenes und widerrufenes Mandat nach Genehmigung, aber vor dem Versand;
• zwei gleichzeitige Einreichungen für eine Rechnung;
• Absturz vor der Reservierung, nach der Reservierung und nach der Akzeptanz des Anbieters;
• Provider-Timeout gefolgt von jedem möglichen autoritativen Ergebnis;
• Schlüsselumdrehung während der Empfangsüberprüfung;
• Wiederverwendung von Genehmigungen gegen einen geänderten Vorschlag;
• Redaktionstest für Anmeldeinformationen und sensible Zahlungsdaten.

Prüfen Sie bei jedem Durchlauf den erwarteten Entscheidungsgrund, den dauerhaften Zustand, die Anbieteranrufe, die Reservierungs-, Empfangs- und Abgleichsaufzeichnung. Ein vorübergehender glücklicher Weg sagt wenig über die Zahlungssicherheit aus. Die Timeout- und Parallelitätsfälle zeigen, ob das Design Duplikate verhindern kann, ohne legitime Arbeit zu verlieren.

Aktueller Intelliger und OATI Grenze

Die öffentliche Entwicklervorschau von OATI bietet derzeit Reisepässe, Mandate, Transaktionsumschläge, deterministische Commerce-Bewertung, kanonische Unterschriften, Quittungen, Middleware und Konformitätsfeststellungen. Der Commerce-Evaluator deckt Preis, Währung, pro Transaktion und kumulative Budgets, Nutzungsverbrauch und signierte Kontextbindung ab. Seine lokale Sandbox zeigt eine bezahlte API-Transaktion.

Agent Spend Control, gehärtete betriebene Gateways, Workflows für die Geschäftsgenehmigung, ein Produktionszahlungsanschluss, dauerhafter Zahlungszustand, Abgleich und Beweissicherung bleiben kommerzielle Zielfunktionen. Eine unabhängige Kryptographie- und Protokollüberprüfung ist noch offen.

Der breitere Intelliger Agentic-Commerce-Blueprint umfasst Modellschlussfolgerung, Ergebnisvorhersage und eingeschränkte Optimierung. Diese Komponenten können Zahlungsaktionen vorschlagen und einstufen. Sie erhalten keine Befugnis, ein hartes Zahlungslimit zu überschreiten. Zahlungsanbieter und Unternehmensfinanzsysteme besitzen weiterhin die Ausführung und Abwicklung.

Zahlungs- und Sicherheitsüberprüfungshinweis: Qualifizierte Gutachter müssen Zahlungsschienenregeln, Anbieterverträge, Betrugskontrollen, Schutz von Grenzen, Datenschutz, Aufgabentrennung, kryptographischer Lebenszyklus und Incident Recovery für den tatsächlichen Einsatz bewerten. Diese Seite wurde am 11. August 2026 mit dem dokumentierten OATI-Entwicklervorschaustatus verglichen. Es handelt sich um Architekturleitlinien, nicht um regulatorische oder Zahlungsschema-Zertifizierung.

Anwendung der Kontrollen auf einen Zahlungsfluss

Arbeiten Sie durch das unterstützende Payment Engineering Cluster:

• Agentisches Bedrohungsmodell für die Zahlungssicherheit
• Zahlungs-Idempotenz für KI-Agenten
• Agentische Zahlungsinfrastruktur und Kontrollgrenzen
• AI Agent Zahlungsberechtigung mit exakter Genehmigung
• Agentische Zahlungen Betrug Prävention Kontrollen und Übungen
• Agentische Zahlungsabgleich Zustand Maschine

Die Enterprise AI Agents Deployment Guide platziert diesen Zahlungskontrollpfad innerhalb des breiteren Agentenlebenszyklus. AI Agent Payment Platform Shortlist beginnt mit dem Zahlungsauftrag, während die Agent Payment Stack Vergleich trennt AP2, x402, UCP, Circle, Catena und Concordium nach Verantwortung. Agentischer Commerce Hub verbindet Zahlungen mit Discovery- und Transaktionsinfrastruktur. Kreditorenautomatisierung unter unsicherer Ausführung und Begrenzte autonome Verhandlungen. Die AI Agent Audit-Trail-Leitfaden Deckt die Quittungsprüfung in mehr Tiefe, und die OATI Mandat Dokumentation beschreibt die portable delegierte Befugnis.

Produkt- und Zahlungsführer bewerten einen Anbieter, Schiene und Währung können Diskutieren Sie ein Agent Trust Design mit Intelliger Vor dem Verbinden von Live-Anmeldeinformationen.