Agentische Zahlungen: Zahlungen delegieren und Befugnisse begrenzen

Ein Kunde bittet einen Agenten, die üblichen Verbrauchsmaterialien zu bestellen. Während der Suche ändern sich jedoch Preis und Lieferbedingungen. Wer hat die Abbuchung des neuen Betrags erlaubt? Agentische Zahlungen sollten mit der Antwort auf diese Frage beginnen, nicht mit einer Schaltfläche zum Bezahlen im Chat. Für einen Onlineshop ist die entscheidende Frage, wie die Delegation begrenzt wird: auf einen bestimmten Verkäufer, eine Währung, einen Betrag, eine Frist und Bedingungen für eine erneute Bestätigung.

Gemeint ist ein Szenario, in dem ein Softwareagent im Namen des Nutzers innerhalb der erteilten Befugnisse eine Zahlung auslöst. Das ist keine Erlaubnis für das Modell, über eine Karte zu verfügen. Die entsprechende Infrastruktur führt die Zahlung aus, während der Shop die Bestellung und das Ergebnis der Transaktion prüft. Im Folgenden geht es darum, einen solchen Prozess zu gestalten, ihn vom gewöhnlichen Checkout abzugrenzen und vor dem Start zu testen.

Wo Einkaufshilfe endet und Delegation beginnt

Ein Assistent kann Produkte vergleichen, einen Warenkorb zusammenstellen und die Zahlungsseite öffnen. Führt der Kunde den letzten Schritt jedes Mal selbst im Standard-Checkout aus, ist das noch keine autonome Delegation der Zahlung. Eine andere Stufe ist erreicht, wenn der Nutzer dem Agenten vorab erlaubt, einen bestimmten Kauf zu vereinbarten Bedingungen abzuschließen. Dafür braucht es einen gesonderten Berechtigungsnachweis, eine Prüfung seiner Gültigkeit und eine klare Möglichkeit, die Ausführung zu stoppen.

Drei Dinge sollten getrennt betrachtet werden: die Absicht, ein Produkt zu kaufen, die Befugnis, eine Zahlung auszulösen, und das tatsächliche Verarbeitungsergebnis. Die Nachricht „Kauf das Günstigste“ legt weder den zulässigen Verkäufer noch den Gesamtbetrag einschließlich Lieferung oder einen erlaubten Ersatzartikel fest. Selbst eine erfolgreiche Bankautorisierung bedeutet nicht, dass das Lager die Ware bestätigt hat oder die Bestellung bereits versendet werden kann.

Die allgemeinen Möglichkeiten des Dialogs und der Katalognutzung sind ein eigenes Thema im Beitrag zum KI-Assistenten für den Onlineshop. Bei einem Zahlungsprojekt ist für die Abnahme nicht die Qualität der Bot-Antwort entscheidend, sondern die Übereinstimmung jeder finanziellen Aktion mit den vereinbarten Parametern.

Vergleichen Sie Betriebsarten nach Kontrolle, nicht nach Autonomiegrad

Als Einstieg kann der Agent den Warenkorb vorbereiten, während der Kunde ihn wie gewohnt bestätigt. Erweitern Sie die Befugnisse, wenn die Regelmäßigkeit der Einkäufe den zusätzlichen Betreuungsaufwand rechtfertigt.

Bei teuren Einkäufen oder individuellen Liefervereinbarungen ist die einfachere Betriebsart oft verständlicher. Begrenzen Sie den Piloten auf eine Art von Einkauf statt auf das gesamte Sortiment.

Was ein Zahlungstoken begrenzt — und was es nicht nachweist

Ein konkretes Umsetzungsbeispiel sind die Shared Payment Tokens, kurz SPT, von Stripe. Laut der offiziellen SPT-Dokumentation gewährt ein Agent einem bestimmten Verkäufer begrenzten Zugriff auf die Zahlungsmethode des Kunden. Dafür werden Währung, Höchstbetrag und Nutzungsfrist festgelegt. Dies ist ein Beispiel für einen Mechanismus, keine allgemeingültige Anforderung an alle agentischen Zahlungen.

Die Gültigkeitsdauer des Tokens entspricht nicht der Dauer der Berechtigung

Das Delegieren von Zahlungen erfordert eigene Geschäftsregeln. Ein Kunde kann einen Kauf bis zum Ende des Arbeitstags erlauben, während das ausgestellte Zahlungstoken kürzer gültig ist. Ein gültiges Token verlängert keine abgelaufene Freigabe, und eine gültige Freigabe macht ein abgelaufenes Token nicht verwendbar. Prüfen Sie vor der Aktion beide Bedingungen unabhängig voneinander.

Der Berechtigungsdienst muss die Transaktion mit einer Warenkorbversion und den Regeln für Ersatzartikel verknüpfen. Umfasst der Auftrag mehrere Einkäufe, ist eine ausdrücklich festgelegte Richtlinie erforderlich; machen Sie aus einer einmaligen Erlaubnis nicht standardmäßig ein Abonnement.

Bezeichnen Sie nicht alle Token als Einmaltoken

Stripe beschreibt SPT für nicht wiederkehrende und wiederkehrende Zahlungen: Die Bezeichnung „Token“ bedeutet nicht, dass genau eine Abbuchung erfolgt. Prüfen Sie bei einem einmaligen Kauf die gewählte Betriebsart und stellen Sie sicher, dass keine unbeabsichtigten wiederkehrenden Zahlungen vorgesehen sind. Halten Sie die Parameter anhand der Dokumentation zur tatsächlich verwendeten Integrationsversion fest.

Mit Stand vom 11. November 2026 nennt Stripe die für SPT unterstützten Länder; die Ukraine ist nicht darunter. Daraus lässt sich nichts über alle anderen Zahlungsprodukte oder alle Kunden mit ukrainischen Karten ableiten. Die Verfügbarkeit wird für die konkreten Beteiligten, Konten, Zahlungsmethoden und Märkte geprüft. Die Verfügbarkeit von gewöhnlichem Acquiring bestätigt keinen Zugang zu einem agentischen Produkt.

Hypothetisches Beispiel: Der Preis ändert sich nach der Freigabe

Ein hypothetisches Beispiel in einer unterstützten Umgebung: Ein Nutzer hat den Kauf eines Sets von Verbrauchsmaterialien bei einem vereinbarten Verkäufer erlaubt. Die Berechtigung umfasst die Artikelnummern, den Gesamtbetrag einschließlich Lieferung, die Währung und eine zeitliche Grenze. Das ist weder ein GL.ua-Projektbeispiel noch eine Aussage über die Verfügbarkeit des Dienstes in der Ukraine.

Der Agent ruft ein aktuelles Angebot ab, und der Shopserver speichert dessen Version. Nach der Freigabe ändern sich die Lieferbedingungen, und der Gesamtbetrag überschreitet die erlaubte Grenze. Richtig ist dann nicht, den Betrag zu runden oder nach der Abbuchung eine Erklärung im Chat hinzuzufügen, sondern die Ausführung zu stoppen und die neuen Bedingungen anzuzeigen. Neuer Zahlungszugriff wird erst nach einer ordnungsgemäß bestätigten Änderung der Berechtigung eingerichtet.

Bleibt der Betrag innerhalb der Grenze, wird aber das Produkt durch ein anderes ersetzt, muss die Prüfung ebenfalls greifen. Ein Geldlimit ersetzt nicht die Prüfung des Kaufinhalts. Dazu gleicht der Server die Warenkorbversion, den Verkäufer und die erlaubten Ersatzartikel ab; das Modell schlägt lediglich eine Aktion vor, statt die Freigaberegeln umzuschreiben.

Ein weiterer Ausnahmefall ist eine zusätzliche Bestätigung durch den Kunden. Bei Stripe kann ein SPT in den Zustand requires_action wechseln, etwa wenn eine Authentifizierung mit 3D Secure erforderlich ist. Der Ablauf muss pausieren, den nötigen Schritt an einen Menschen übergeben und anschließend korrekt fortgesetzt werden können. Das Versprechen „Zahlungen unter allen Umständen ohne Mitwirkung des Kunden“ ist hier unzutreffend.

Gestalten Sie einen kontrollierten Weg von der Berechtigung zur Bestellung

Sehen Sie vor dem Aufruf des Zahlungsanbieters einen eigenen Dienst zur Freigabeprüfung vor. Das Sprachmodell darf keine geheimen Schlüssel mit uneingeschränkten Befugnissen oder Kartendaten erhalten. Sein Zahlungswerkzeug sollte nur die minimal erforderlichen Parameter der erlaubten Transaktion annehmen.

In dieser Kette müssen Berechtigung, Warenkorbversion, Bestellung und Zahlungstransaktion gemeinsam miteinander verknüpft sein. Kontrolle von Zahlungsbefugnissen bedeutet, dass diese Verknüpfungen nach einer Störung überprüft werden können, statt sie aus dem Dialogtext rekonstruieren zu müssen. Eine wiederholte Anfrage mit derselben Absicht darf keinen zweiten Kauf erzeugen, nur weil die erste Antwort verloren ging.

Das AP2-Protokoll beschreibt kryptografisch signierte Mandate für Checkout und Zahlung. Die Spezifikation macht Befugnisse überprüfbar, stellt aber nicht automatisch Acquiring bereit. Unterstützte Versionen und die Rollen der Beteiligten sollten vor der Entwicklung abgestimmt werden.

Der Shop verwaltet die Warenreservierung gesondert. Wird die Zahlung nach Ablauf der Reservierung bestätigt, darf nicht automatisch ein Versand zugesagt werden. Nötig sind eine erneute Prüfung und ein festgelegter Ablauf für den Ausnahmefall. Diesen angrenzenden Prozess behandelt der Beitrag zur Bestätigung verfügbarer Bestände nach dem ATP-Prinzip.

So prüfen Sie die Lösung vor dem Start

Beginnen Sie in der Testumgebung des Anbieters mit einer Matrix zulässiger und unzulässiger Aktionen. Für jeden Test werden die erwarteten Bestell- und Zahlungszustände sowie eine für Ausnahmefälle verantwortliche Person benötigt.

1. Bestätigen Sie die Verfügbarkeit des Produkts für die benötigten Beteiligten und Zahlungsmethoden. Halten Sie die Integrationsversion und die Grenzen des Testzugangs fest.
2. Spielen Sie einen korrekten Kauf, eine Betragsüberschreitung, eine andere Währung, einen anderen Verkäufer, einen Produktaustausch und den Ablauf der Berechtigung durch. Unerlaubte Änderungen müssen die Aktion stoppen.
3. Prüfen Sie ein abgelaufenes und ein widerrufenes Token getrennt von einer widerrufenen geschäftlichen Berechtigung. Verlassen Sie sich nicht allein auf einen Hinweis im Dialog.
4. Simulieren Sie den Verlust einer Antwort nach einer Anfrage und die erneute Zustellung einer Nachricht. Stellen Sie sicher, dass eine Wiederholung weder eine neue Bestellung noch einen unnötigen Zahlungsversuch erzeugt.
5. Durchlaufen Sie zusätzliche Authentifizierung, Ablehnung, Stornierung und Erstattung. Gleichen Sie die Zustände im Shop und beim Anbieter ab, einschließlich verspäteter Ereignisse.
6. Prüfen Sie die Abschaltung des agentischen Kanals, den Standard-Checkout und die Arbeit des Supports. Das Team muss den Grund für den Stopp erkennen können und über Anweisungen für den Kunden verfügen.

Das Protokoll muss Ereignisse erklären, ohne Geheimnisse oder unnötige personenbezogene Daten offenzulegen. Prüfen Sie vor einer unumkehrbaren Aktion die Echtheit der Anbieternachrichten und den Transaktionszustand. Dies sind Abnahmekriterien, keine Garantie gegen Betrug.

Risiken, Zeitrahmen und Kosten des Piloten

Die Hauptrisiken sind eine falsch verstandene Berechtigung, manipulierte Bedingungen, wiederholte Ausführung, offengelegte Zugangsdaten und Abweichungen zwischen Zahlung und Bestellung. Token, serverseitige Prüfungen und Protokolle reduzieren die Risiken, beseitigen sie aber nicht. Eine externe Produktbeschreibung oder eine Nachricht des Agenten darf die Zahlungsrichtlinie nicht verändern.

Der Zeitrahmen hängt von der Bereitschaft der gesamten Kette ab

Planen Sie die Phasen: Verfügbarkeitsprüfung, Beschreibung der Berechtigungen, Prototyp, Integration mit den Bestellzuständen, Tests der Ausnahmefälle und begrenzter Start. Der Zeitrahmen hängt vom Produktzugang, der API-Bereitschaft, Reservierungen, Erstattungen und dem Support ab. Geben Sie erst nach diesen Prüfungen eine kalenderbezogene Schätzung ab.

Trennen Sie im Budget Geschäftsanalyse, Freigabeoberfläche, Berechtigungsdienst, Zahlungsintegration, Ereignisprotokoll, Tests und Betriebsanweisungen. Infrastruktur, Modellnutzung, Anbietergebühren, Monitoring und die Betreuung von API-Änderungen werden gesondert kalkuliert. Die Bedingungen der Zahlungsabwicklung und die Verantwortung der Parteien sind mit dem Anbieter und qualifizierten Fachleuten zu klären; dieser Artikel stellt keine Finanz- oder Rechtsberatung dar.

Beginnen Sie mit überprüfbaren Befugnisgrenzen und behalten Sie den gewöhnlichen Checkout als funktionierende Alternative bei. Hat der Shop Zahlungs- und Bestellzustände noch nicht aufeinander abgestimmt, verbessern Sie zunächst diesen Prozess. Für einen konkreten nächsten Schritt übermitteln Sie GL.ua (Glyanets) ein Schema des aktuellen Zahlungsablaufs und ein Delegationsszenario im Rahmen der Entwicklung und Integration Ihres Onlineshops: Das ist die Grundlage, um Architektur, Einschränkungen und Arbeitsumfang des Piloten zu bewerten.