Obenan

Signal-Briefings von Obenan

Bezahlte Agent-Aktionen werden zur Infrastruktur. Die Händlerzusage ist weiterhin ungelöst.

Agentenplattformen machen kostenpflichtige APIs, kostenpflichtige MCP-Server, kostenpflichtige Webinhalte und Maschinenzahlungen zu nativer Laufzeit-Infrastruktur. Das beantwortet, wie ein Agent bezahlt. Es beantwortet nicht, ob der Händler auf der anderen Seite eine bestimmte Zusage in dem Moment einhalten kann, in dem Geld fließt.

Published May 13, 2026 · Global · Öffentliche Infrastruktur

Fazit für Betreiber

Die jüngsten Veröffentlichungen verkleinern die Lücke bei der Zahlungsinfrastruktur; die Händlerseite bleibt offen. Wenn Sie Buchungen, Mobilität, Dienstleistungen, Ticketing oder einen anderen lokalen Serviceablauf betreiben, behandeln Sie die Wahrheit über Verfügbarkeit, Richtlinien, Berechtigung und Bestätigung als Ihre eigene Aufgabe, vor der Zahlungsausführung. Der September 2026 brachte Bewegung auf drei getrennten Ebenen, und keine davon ist ein Kunde, der bei Ihnen kauft.

Ceren schreibenMerchant Infrastructure ansehen

Was sich geändert hat

Die öffentliche Infrastruktur für bezahlte Agent-Aktionen hat sich zwischen dem 29. April und dem 12. Mai 2026 verfestigt

Vier voneinander unabhängige öffentliche Schritte in den vergangenen zwei Wochen behandeln bezahlte Agent-Aktionen als verwaltete Infrastruktur statt als Protokolltheater. Das Muster ist einheitlich: Agentenplattformen erwarten inzwischen, für Werkzeuge, Inhalte und Ressourcen als vollwertiges Laufzeitverhalten zu bezahlen.

01

AWS Bedrock AgentCore Payments startet als Preview

Am 7. Mai 2026 hat AWS Amazon Bedrock AgentCore Payments als Preview gestartet. Die Veröffentlichung macht Zahlungen zu einer nativen Laufzeitfunktion für Bedrock-Agenten, unterstützt x402, integriert Wallets von Coinbase und Stripe Privy, setzt Ausgabenlimits auf Sitzungsebene durch und stellt Mikrozahlungen ausdrücklich als ersten Schritt hin zu breiteren käuferseitigen Abläufen dar.

02

Stripe bündelt den Agentenhandel in einem Stack

Am 29. April 2026 hat Stripe auf der Sessions 2026 den Zugang für Händler über das Dashboard erweitert, Google über AI Mode und die Gemini-App als nachgelagerte Route für Auffindbarkeit und Checkout ergänzt und Link-Agent-Wallets sowie Unterstützung für das Machine Payments Protocol für programmatische Agentenzahlungen eingeführt.

03

MPP veröffentlicht Entwürfe für Payment-Auth und MCP-Transport

Am 12. Mai 2026 veröffentlichte das Ökosystem des Machine Payments Protocol auf paymentauth.org zwei miteinander verknüpfte Internet-Drafts: ein HTTP-Authentifizierungsschema „Payment“ und ein Mapping für den Transport über JSON-RPC und MCP. Zusammen geben sie 402 Payment Required eine konkrete Semantik und legen fest, wie kostenpflichtige Tool-Aufrufe, Ressourcenabrufe und Prompt-Abrufe in MCP ausgedrückt werden können.

04

Adyen tritt der x402 Foundation bei

In seinem Geschäftsupdate zum ersten Quartal vom 6. Mai 2026 gab Adyen bekannt, der x402 Foundation beigetreten zu sein, um offene Standards für Zahlungen über HTTP mit zu etablieren, und verknüpfte diesen Schritt ausdrücklich mit interoperablen Transaktionsabläufen im agentischen Handel. Ein großer PSP hat damit eine sichtbare Standardwette auf HTTP-native Zahlungsobjekte platziert.

Spätere Belege

In der ersten Septemberhälfte 2026 geschahen vier datierte Dinge. Man hört sie leicht als eine einzige Geschichte über Agenten, die Dinge kaufen. Es ist nicht eine Geschichte. Sie liegen auf drei verschiedenen Ebenen des Stacks, und es lohnt sich, sie getrennt zu halten, denn nur eine der drei liegt überhaupt auf der Händlerseite des Tresens – und selbst diese ist das Backoffice, nicht die Kasse.

Die folgenden Belege wurden am 22. September 2026 gelesen. Jeder Punkt ist mit dem Datum seiner Quelle versehen.

Was es ist: Bibliothekscode für ein Zahlungsprotokoll ist sorgfältiger darin geworden, Fehler deutlich anzuzeigen. Dadurch hat niemand irgendjemanden bezahlt.

  • Ein Protokoll ist ein vereinbarter Satz von Regeln, denen zwei Computer folgen, damit sie ohne einen Menschen in der Mitte eine Transaktion abwickeln können; ein SDK ist der fertige Code, den ein Entwickler in ein Programm einbaut, damit es dieses Protokoll sprechen kann. Am 15. September 2026 veröffentlichten die Betreuer des Python-SDK für das Zahlungsprotokoll x402 die Version 2.23.0, die auf 2.22.0 folgte.
  • Die Änderungen sind von der unspektakulären Art, die erst zählt, wenn echtes Geld fließt. Die Abwicklung ist der Schritt, in dem das Geld tatsächlich ankommt, statt nur autorisiert zu sein – derselbe Unterschied wie zwischen einer Karte, die am Freitag an Ihrem Terminal genehmigt wird, und dem Geld, das am Dienstag auf Ihrem Konto erscheint. Während der Abwicklung verwendet der Code jetzt eine Prüfung wieder, die er bereits gemacht hatte, statt das Netzwerk ein zweites Mal zu fragen. Dauerhafte Konfigurationsfehler werden jetzt beim Start des Programms erkannt, während vorübergehende Zeitüberschreitungen weiterhin wiederholt werden können. Wartezeiten wurden verlängert und mit festen Obergrenzen versehen – für Aufrufe an den Facilitator, den Dienst, der eine Zahlung im Namen beider Seiten prüft und ausführt, und für bezahlte Tool-Aufrufe –, damit eine langsame Abwicklung zu Ende laufen kann, statt abgebrochen zu werden. Die Routenprüfung wurde gegen eine absichtlich getarnte Webadresse gehärtet. Das Ausgabenlimit, das ein Entwickler festlegt, wird jetzt an jede Zahlungsmethode weitergegeben, die die Bibliothek unterstützt.
  • Es handelt sich um eine Sprachanbindung eines einzigen Protokolls – den Code für eine einzige Programmiersprache –, die in ihrem Betrieb expliziter wird. Geschrieben haben sie die Menschen, die dieses Protokoll pflegen, über ihren eigenen Code. Sie ist auch nicht die neueste Version: Am 22. September 2026, dem Tag, an dem diese Belege gelesen wurden, folgte die Version 2.24.0.

Das ist nicht: Verbreitung, Transaktionsvolumen oder irgendein Händler, der irgendetwas tut. Eine Versionsnotiz ist eine Aussage über eine Codebasis. Kein Restaurant, keine Praxis und keine Werkstatt wird darin erwähnt, und keine ist darin mitgemeint.

Was es ist: Software bezahlt Software. Ein Programm bezahlt für Daten oder einen Dienst, den es für seine Arbeit braucht. Der Käufer ist ein Programm, der Verkäufer ein API-Anbieter – ein Unternehmen, das anderen Programmen Zugang zu seinen Daten oder seiner Software verkauft –, und jeder Betrag liegt zwischen 0,001 und 0,01 US-Dollar.

  • Am 1. September 2026 nannte ein Artikel im AWS-Blog über t54, verfasst von AWS-Mitarbeitenden gemeinsam mit Mitgliedern des t54-Teams, die eigene Zahl von t54: Sein Dienst x402-secure hat seit dem Start „mehr als 20 Millionen von KI-Agenten ausgelöste Transaktionen“ verarbeitet, jede davon „eine Mikrozahlung zwischen $0.001 und $0.01“ – eine Zahlung, so klein, dass es sinnlos wäre, sie über eine Karte laufen zu lassen.
  • Das Anwendungsbeispiel des Artikels ist ein Agent, der Aktiendepots beobachtet und Echtzeit-Marktdaten von einer kostenpflichtigen API kaufen muss. Der Gründer von t54 beschreibt die Transaktionen genauso, als „die Art schneller, kleiner Abrufe von Daten oder einer API, die kein Mensch in Echtzeit prüfen könnte“, und der Artikel sagt, dass sie „ohne dass ein Mensch auch nur eine einzige genehmigt“ geschehen. Nach t54s eigener Beschreibung ist es das, was die Zahl zählt: Software, die einen Softwareanbieter für einen Dienst bezahlt, den die Software selbst nutzt, millionenfach.
  • Das Nächste, was einem Vergleich aus einem lokalen Geschäft nahekommt, ist die automatische Aufladung der Daten-SIM in Ihrem Kartenterminal. Sie läuft ständig, niemand genehmigt jede einzelne Abbuchung, und sie ist kein Kunde, der einen Tisch bucht.

Das ist nicht: Käufe, Kunden oder irgendein Checkout im Einzelhandel oder bei Händlern – die Zahl zählt nichts davon. Es ist keine unabhängig geprüfte Zahl: Sie stammt von dem Unternehmen, dessen Dienst die Transaktionen verarbeitet hat, in einem Artikel im Blog seines Cloud-Anbieters. Niemand hat damit einen Haarschnitt bezahlt.

Was es ist: Werkzeuge, mit denen der eigene Agent eines Unternehmens das eigene Zahlungskonto des Unternehmens bedienen kann – und ein angekündigtes Akzeptanzprodukt für Händler. Es ist die einzige der drei Ebenen auf der Händlerseite, und sie ist das Büro, nicht der Tresen.

  • Am 1. September 2026 veröffentlichte Checkout.com einen Beitrag, der seinen MCP-Server beschreibt; nach eigenen Angaben hat das Unternehmen ihn gebaut, um seine Werkzeuge in die Entwicklungssoftware der Händler zu bringen. Ein MCP-Server ist eine standardisierte Tür, die ein Unternehmen vor seine Systeme setzt, damit ein KI-Assistent sie nutzen kann – derselbe Gedanke, wie einer neuen Führungskraft einen Zugang mit festgelegten Berechtigungen zu geben statt der Schlüssel zu allem.
  • Was der Assistent durch diese Tür tun kann, ist in den Worten von Checkout.com, „den Zahlungsstatus abfragen, Zahlungslinks verwalten oder Aktionen wie Erstattungen, Rückbuchungsstreitfälle und Stornierungen sicher ausführen“. Eine Erstattung gibt einem Kunden, der bereits bezahlt hat, Geld zurück; ein Streitfall ist der Einspruch eines Kunden gegen eine Belastung, abgewickelt über die Bank; eine Stornierung hebt eine Zahlung auf, die zwar autorisiert, aber noch nicht erfasst wurde – das Geld wird also nie eingezogen. Das sind die Dinge, die die Person, die Ihre Buchhaltung macht, am Montagmorgen erledigt. Die Berechtigungen „spiegeln Ihr Checkout.com-Dashboard-Konto“, und die Werkzeuge sind sowohl in der Testumgebung als auch in der Live-Umgebung verfügbar.
  • Checkout.com erklärt außerdem, man sei dabei, „das MCP in eine native Zahlungsebene für Händler-Agenten zu verwandeln, von einfacher Unterstützung hin zu autonomen Abläufen und mehrstufigen Vorgängen“. Dieser Satz beschreibt laufende Arbeit, kein fertiges Produkt. Es ist eine erklärte Absicht und sollte so gelesen werden, bis etwas ausgeliefert ist.
  • Etwa eine Woche später kündigte IXOPAY eine Agentic Suite aus drei Teilen an: einen Payment Agent, der „neue Einkaufserlebnisse mit bestehender Infrastruktur verbindet“, Universal Tokens, die „Agentenidentität, Kundeneinwilligung und Kaufabsicht zusammen mit den Zahlungsdaten bewahren“, und einen MCP Server, der „zugelassenen KI-Assistenten einen kontrollierten Zugang zu unterstützten Zahlungs- und Tokenisierungsfunktionen gibt“. Die Ankündigungsseite nennt zwei verschiedene Daten für sich selbst – den 8. September 2026 im Seitenkopf und den 9. September 2026 in der Datumszeile. Wir nennen beide, statt eines auszuwählen. Ein Zitat von Tilopay in der Ankündigung, einem Partner, der auf der Plattform von IXOPAY aufbaut, besagt, dass Tilopay-Händler „noch heute mit agentischen Transaktionen zu wachsen beginnen können“; wenn ein Partner das in der eigenen Launch-Ankündigung des Anbieters sagt, ist das eine Partneraussage, kein unabhängiger Beleg dafür, dass Händler es getan haben.
  • Die Produktseite des Payment Agent ergänzt ein weiteres Detail: „Die anfängliche Protokollunterstützung beginnt mit dem Visa Trusted Agent Protocol (TAP). Payment Agent wird auf einer protokollagnostischen Grundlage gebaut, die darauf ausgelegt ist, weitere Protokolle zu unterstützen, während sich das Ökosystem des agentischen Handels weiterentwickelt.“ Lesen Sie das als Ausgangspunkt eines bewusst auf mehrere Protokolle angelegten Designs, nicht als Festlegung auf das Protokoll eines einzigen Netzwerks – und beachten Sie, dass es auf der Produktseite steht, nicht in der Launch-Ankündigung.

Das ist nicht: der Checkout von Verbrauchern. Nichts hiervon beschreibt einen Käufer, der bei einem Händler kauft. Erstattung und Streitfall betreffen eine bereits erfasste Zahlung; eine Stornierung hebt eine autorisierte Zahlung auf, bevor sie erfasst wird. Alle drei setzen an einer Zahlung an, die auf anderem Weg begonnen hat. Ein angekündigtes Akzeptanzprodukt ist eine Ankündigung. Und eine erklärte Absicht, eine native Zahlungsebene zu bauen, ist keine native Zahlungsebene.

Setzt man die drei Ebenen wieder zusammen, hält die ursprüngliche Aussage dieser Seite, und zwar in schärferer Form. Die Leitungen wurden sorgfältiger. Agenten, die für ihre eigene Software zahlen, lieferten eine große, selbst gemeldete Zahl. Händler bekamen bessere Werkzeuge für bereits getätigte Zahlungen. Nichts davon sagt einem Agenten, ob der Tisch um 19 Uhr, der Werkstatttermin am Dienstag oder der Platz im Kurs am Samstag gerade wirklich verfügbar ist und wirklich eingehalten werden kann.

Wo jeder dieser Schritte liegt und warum sie getrennt sind: Zum Rahmenmodell „committability ladder“

Warum das wichtig ist

Bezahlen wird zur Normalität. Eine bestimmte Zusage einzuhalten nicht.

Zahlungsinfrastruktur beantwortet eine Legitimationsfrage: wer bezahlen darf und wie Geld fließen soll. Für sich genommen beantwortet sie keine Frage der Händlerbereitschaft: ob ein bestimmter Stellplatz, ein Kursplatz, eine Restaurantanzahlung, ein Termin, ein Ticket oder ein Abholfenster in dem Moment tatsächlich eingehalten werden kann, in dem sich ein Agent festlegt. Wenn sich der öffentliche Stack um Autorisierung, Tokenisierung, Absicht und Maschinenzahlungen konsolidiert, wird die händlerseitige Frage der Verbindlichkeit nicht leichter. Sie wird sichtbarer.

Wohin sich der Stack bewegt

Infrastruktur deckt jetzt die Zahlungsausführung ab. Die Händlerzusage liegt ihr vorgelagert.

Liest man die vier Veröffentlichungen zusammen, entsteht ein Bild. Große Plattformen haben begonnen zu regeln, wofür ein Agent bezahlen darf, wie die Zahlung strukturiert ist und wie sie geroutet wird. Nichts davon entscheidet, ob eine benannte lokale Zusage auf Händlerseite real, aktuell, richtlinienvollständig und jetzt sicher umsetzbar ist.

Seite der Zahlungsinfrastruktur

Jetzt öffentlich

  • Verwaltete Zahlungslaufzeit für Agenten in einer großen Cloud-Agentenplattform (AWS Bedrock AgentCore Payments)

  • Agent-Wallets, Bausteine für Maschinenzahlungen und Routen zur Händlerauffindbarkeit, gebündelt in einem PSP-Stack (Stripe)

  • HTTP-native Zahlungssemantik mit kostenpflichtigen MCP-Tool- und Ressourcenaufrufen, definiert in Standardentwürfen (MPP)

  • Offene HTTP-Zahlungsstandards, unterstützt durch einen großen PSP, der der Foundation beitritt (Adyen und x402)

Seite der Händlerzusage

Weiterhin ungelöst

  • Ob der benannte Slot, das Ticket, der Sitzplatz, der Tisch, der Stellplatz, der Termin oder das Zeitfenster im Moment der Zusage tatsächlich verfügbar ist

  • Ob sich die Richtlinien des Händlers zu Stornierung, Anzahlung, Verspätung, Änderung und Erstattung abfragen lassen, bevor Geld fließt

  • Ob die händlerseitige Berechtigung für die konkrete Zusage jetzt zutrifft und nicht nur auf einer Profilseite

  • Ob Bestätigung, Erfüllung und Verhalten im Streitfall auch außerhalb kontrollierter Pilotprojekte Bestand haben

Unsere Position

Bezahlen wird zur Infrastruktur. Verbindlichkeit muss erst noch gebaut werden.

Das Muster über die Veröffentlichungen vom April und Mai 2026 hinweg ist einheitlich genug, um als ein einziger Schritt gelesen zu werden. Die Zahlungsseite des Agenten-Stacks konsolidiert sich öffentlich um verwaltete Laufzeitumgebungen, Agent-Wallets, Bausteine für Maschinenzahlungen und HTTP-native Zahlungssemantik. Das ist die richtige Richtung. Es macht die vorgelagerte Frage zugleich schärfer. Eine Payment-Challenge kann einem Agenten sagen, wie er bezahlen soll. Sie kann ihm nicht sagen, ob der Händler auf der anderen Seite die benannte Zusage in dem Moment einhalten kann, in dem Geld fließt. Obenan liest das als Bewegung des öffentlichen Stacks auf die Grenze der Händlerbereitschaft zu, nicht über sie hinaus.

Zahlungszugang ist nicht dasselbe wie eine Händlerzusage

Begrenzte, benannte, mit Zeitstempel versehene Zusagen sind die Einheit der Händlerbereitschaft

Händlerseitige Wahrheit liegt der Zahlungsausführung vorgelagert und der Auffindbarkeit nachgelagert

Was dieses Briefing nicht behauptet

Was dieses Briefing nicht behauptet

Die obige Argumentation ist begrenzt. Die folgende Liste benennt ausdrücklich die Aussagen, die dieses Briefing nicht trifft.

  1. 01

    Dies ist keine Behauptung, dass Obenan ein Zahlungsdienstleister, ein Acquirer, eine Checkout-Ebene, eine Tokenisierungsebene, ein Agent-Wallet oder ein Abwicklungsnetzwerk ist.

  2. 02

    Dies ist keine Behauptung einer Integration, eines Pilotprojekts oder einer Partnerschaft mit AWS Bedrock AgentCore Payments, Stripe, Coinbase, Privy, Adyen, der x402 Foundation, dem Machine Payments Protocol, OpenAI, Visa, Mastercard, American Express, dem Universal Commerce Protocol, dem Agentic Commerce Protocol, AP2 oder einem Zahlungsnetzwerk oder Entwicklerprogramm.

  3. 03

    Dies ist keine Behauptung, dass kostenpflichtige MCP-Tools, kostenpflichtige APIs oder kostenpflichtige Ressourcenaufrufe die händlerseitige Verbindlichkeit für lokale Dienstleistungen lösen.

  4. 04

    Dies ist keine Behauptung, dass alle lokalen Dienstleistungen heute für agentische Zahlungen bereit sind.

  5. 05

    Dies ist keine Behauptung, dass ein kontrolliertes Pilotprojekt irgendeines Netzwerks das Verhalten bei einer breiten kommerziellen Einführung belegt.

  6. 06

    Dieses Briefing veröffentlicht keine privaten Partnernamen, keine Stände privater Gespräche und kein Material unter NDA. Die Argumentation stützt sich ausschließlich auf öffentliche Quellen.

  7. 07

    Wir behaupten nicht, dass die von Agenten ausgelösten Transaktionen, die t54 meldet, Käufe bei Händlern, Checkouts im Einzelhandel oder eine unabhängig geprüfte Zahl sind. Es sind Mikrozahlungen von Agenten an Softwaredienste, gemeldet von dem Unternehmen, das sie verarbeitet hat.

  8. 08

    Wir behaupten nicht, dass Checkout.com eine native Zahlungsebene für Händler-Agenten ausgeliefert hat. Checkout.com erklärt diese Absicht; als verfügbar beschrieben werden Zahlungsvorgänge im Backoffice.

  9. 09

    Wir behaupten nicht, dass die Agentic Suite von IXOPAY oder einer ihrer Bestandteile von Händlern übernommen wurde. Eine Launch-Ankündigung und das Zitat eines Partners sind keine Belege für eine Nutzung.

  10. 10

    Wir behaupten nicht, dass eine neue Version der Softwarebibliothek eines Zahlungsprotokolls auf Verbreitung, Transaktionsvolumen oder Händlerbereitschaft hinweist.

Aktionsleiste für Betreiber

Was jetzt zu tun ist, was zu beobachten ist und was nicht anzunehmen ist

Unterteilt nach dem, worauf die Händlerseite direkt einwirken kann, und dem, was auf der Seite der Zahlungsinfrastruktur liegt.

01

Jetzt tun

Vom Händler gesteuert

  • Verfügbarkeit, Kapazität und Buchungsobjekte so strukturieren, dass ein Agent sie vor einer Zusage prüfen kann

  • Regeln zu Stornierung, Anzahlung, Berechtigung und Richtlinien in maschinenlesbarer Form festlegen

  • Bestätigungsnachrichten auf das abstimmen, was der Händler im jeweiligen Moment tatsächlich einhalten kann

Von der Infrastruktur gesteuert

  • Verfolgen, welche Flächen für bezahlte Agent-Aktionen beginnen, händlerseitige Zusagesemantik zu ergänzen, statt nur Zahlungssemantik

02

Beobachten

Vom Händler gesteuert

  • Ob händlerseitige Verbindlichkeit über Buchungs-, Terminplanungs- und Reservierungssysteme hinweg dauerhaft abfragbar wird

  • Ob kategoriespezifische Richtlinien der Zahlungsausführung vorgelagert standardisiert werden

Von der Infrastruktur gesteuert

  • Ob AWS, Stripe, Adyen und die x402 Foundation über Autorisierung und Mikrozahlungen hinaus in Semantik für Reservierung, Anzahlung und ausdrückliche Käuferabsicht vordringen

  • Ob die MPP- und MCP-Transportentwürfe von öffentlichen Entwürfen zu übernommenen Protokollen werden

  • Ob die Zahlungswerkzeuge auf Händlerseite, die im September 2026 erschienen sind, vom Backoffice in die Zusage übergehen, die ein Kunde kauft

03

Nicht annehmen

Vom Händler gesteuert

  • Dass ein Profil, ein Eintrag oder ein Katalogeintrag Verbindlichkeit für eine bestimmte benannte Zusage bedeutet

  • Dass die Standardisierung auf der Zahlungsseite die Bereitschaft auf Händlerseite automatisch herstellt

Von der Infrastruktur gesteuert

  • Dass kostenpflichtige MCP-Tools oder bezahlte Agent-Aktionen einer händlerseitigen Zusage gleichkommen

  • Dass Agenten-Laufzeiten im Preview-Stadium produktionsreifen kommerziellen Handelsabläufen gleichkommen

  • Dass eine Softwareversion eines Zahlungsprotokolls, eine vom Anbieter gemeldete Transaktionszahl oder eine Produktankündigung auf eine Nutzung durch Händler hinweist

Weiterlesen

Wie das mit dem Rest der Merchant-Participation-These zusammenhängt

Die Händlerseite muss erst noch gebaut werden

Bezahlte Agent-Aktionen werden zur Infrastruktur. Die nächste fehlende Ebene ist Verbindlichkeit. Für Betreiber von Buchungen, Mobilität, Dienstleistungen, Ticketing oder einem anderen lokalen Serviceablauf liegt die Arbeit der Zahlung vorgelagert: die Wahrheit über Verfügbarkeit, Richtlinien, Berechtigung und Bestätigung.

Ceren schreibenMerchant Infrastructure ansehen

Quellen

Dieses Signal stützt sich ausschließlich auf öffentliche Quellen. Die Veröffentlichungen vom Mai 2026 werden gemeinsam als ein Muster gelesen: die Konsolidierung verwalteter Zahlungsinfrastruktur für Agenten zwischen dem 29. April und dem 12. Mai 2026. Die Quellen vom September 2026 werden als drei getrennte Ebenen gelesen, bewusst nicht zusammengeführt, und jede Zahl wird demjenigen zugeordnet, der sie gemeldet hat.

  1. 1.
    Agents that transact: Introducing Amazon Bedrock AgentCore Payments, built with Coinbase and Stripeaws.amazon.com · 7. Mai 2026 · 13. Mai 2026

    Primärer Beleg dafür, dass eine große Cloud-Agentenplattform kostenpflichtige Ressourcen, kostenpflichtige MCP-Tools und budgetbegrenzte Agentenausgaben inzwischen als vollwertige Laufzeitfunktion behandelt

  2. 2.
    Stripe builds out the economic infrastructure for AI with 288 launches at Sessions 2026stripe.com · 29. April 2026 · 13. Mai 2026

    Primärer Beleg dafür, dass ein einzelner PSP-Stack inzwischen Agentendistribution, Agent-Wallets und Bausteine für Maschinenzahlungen in einer händlerseitigen Ebene vereint

  3. 3.
    Payment Authentication Scheme: JSON-RPC and MCP Transport (draft-payment-transport-mcp-00)paymentauth.org · 12. Mai 2026 · 13. Mai 2026

    Primärer Beleg dafür, dass kostenpflichtige MCP-Tool-Aufrufe, Ressourcenabrufe und Prompt-Abrufe in öffentlichen Internet-Drafts eine konkrete Zahlungssemantik erhalten

  4. 4.
    The Payment HTTP Authentication Scheme (draft-httpauth-payment-00)paymentauth.org · 12. Mai 2026 · 13. Mai 2026

    Sekundärer Beleg, der 402 Payment Required als strukturiertes HTTP-Authentifizierungsschema formalisiert

  5. 5.
    Adyen publishes Q1 2026 Business Updateadyen.com · 6. Mai 2026 · 13. Mai 2026

    Primärer Beleg dafür, dass ein großer PSP eine sichtbare Standardwette auf HTTP-native Zahlungsobjekte für den agentischen Handel platziert hat

  6. 6.
    Everything we announced at Sessions 2026stripe.com · 29. April 2026 · 13. Mai 2026

    Ausführliche Referenzberichterstattung zu den konkreten Bestandteilen der Stripe Sessions 2026, die für dieses Signal am relevantesten sind, darunter Link-Agent-Wallets, die Unterstützung des Machine Payments Protocol und die händlerseitige Dashboard-Oberfläche für den Agentenzugang

  7. 7.
    x402 Python SDK Changelog — 2.23.0github.com · 15. September 2026 · 22. September 2026

    Primärquelle. Die eigenen Versionshinweise der Betreuer für eine Sprachanbindung des Zahlungsprotokolls x402, gelesen beim Eintrag 2.23.0; dieselbe Datei führt bereits 2.24.0 mit Datum 22. September 2026. Beleg für betriebliche Härtung von Bibliothekscode, und für nichts, was Händler betrifft.

  8. 8.
    How t54 built a trust layer with Amazon Bedrock AgentCore paymentsaws.amazon.com · 1. September 2026 · 22. September 2026

    Primärquelle für den Umfang von Mikrozahlungen zwischen Agenten und Diensten und Ursprung der auf dieser Seite zitierten Transaktionszahl. Gemeldet von t54, dem Kunden, in einem Artikel im AWS-Blog, verfasst von Mitarbeitenden von AWS und t54. Keine Prüfung und kein Händlergeschäft.

  9. 9.
    Building trusted AI infrastructure with the Checkout.com MCPcheckout.com · 1. September 2026 · 22. September 2026

    Primärquelle für Zahlungsvorgänge im Backoffice auf Händlerseite über einen MCP-Server – Erstattungen, Streitfälle und Stornierungen auf dem eigenen Konto des Händlers. Die erklärte Absicht, eine native Zahlungsebene zu bauen, ist künftige Arbeit, keine ausgelieferte Funktion.

  10. 10.
    IXOPAY Launches Agentic Suite to Help Merchants Support Agentic Commerce and Automate Payment Workflowsixopay.com · 8. September 2026 (Seitenkopf) / 9. September 2026 (Datumszeile) · 22. September 2026

    Launch-Ankündigung des Anbieters für Payment Agent, Universal Tokens und einen MCP Server. Die Seite nennt zwei verschiedene Daten für sich selbst, und beide werden angegeben. Das enthaltene Partnerzitat ist eine Partneraussage, kein Nutzungsbeleg.

  11. 11.
    Payment Agent: Get Started with Agentic Commerceixopay.com · Zuletzt geändert am 8. September 2026 · 22. September 2026

    Die Produktseite des IXOPAY Payment Agent, die die Aussage zur anfänglichen Protokollunterstützung enthält. Zitiert, weil die Launch-Ankündigung diese Aussage nicht enthält. TAP wird als anfängliches Protokoll auf einer Grundlage genannt, die die Seite als protokollagnostisch beschreibt.