Machine-to-Machine (M2M) Payments: Warum Governance wichtiger ist als Zahlungsnetzwerke

Um zu verstehen, wo M2M-Zahlungen anzusiedeln sind, lohnt sich ein Blick auf die breitere Landschaft des Agentic Commerce. Mit zunehmender Reife des Marktes werden wir voraussichtlich verschiedene Wege sehen, wie Agenten Transaktionen durchführen. Auf einer übergeordneten Ebene unterscheiden sich diese Transaktionsmodelle in drei Punkten: wer der Endverbraucher ist, wie autonom die Transaktion abläuft und was tatsächlich gekauft wird.

Mit diesem Framework im Hinterkopf haben wir uns an mehr als 70 Enterprise-Händler und Partner aus dem Ökosystem gewandt. Sie sind am dichtesten am Thema dran und haben uns geholfen zu kartieren, wo Machine-to-Machine Payments bereits Realität sind, wo sich die Entwicklung noch in der Frühphase befindet und was sich ändern muss, damit die Nutzung skaliert.

Der Großteil des heutigen Agentic Commerce konzentriert sich noch auf Human-in-the-Loop-Abläufe. Ein Agent entdeckt Optionen, bereitet einen Kauf vor und leitet die Zahlung ein. Der Käufer bleibt jedoch eine Person, und das gekaufte Produkt wird letztendlich auch von dieser Person konsumiert.

M2M Payments sind anders. Hier ist der Käufer ein anderer Agent (oder ein System), und der Kauf unterstützt diesen Agenten bei der Ausführung einer Aufgabe – selbst wenn die dafür erforderlichen Schritte vom Nutzer nicht explizit vorgegeben wurden.

Anstatt Konsumgüter oder Dienstleistungen zu kaufen, erwirbt ein Agent beispielsweise Rechenkapazität, eine Domain, Zugriff auf einen Datenfeed, Paywall-Inhalte oder zusätzliche Modellaufrufe – und das völlig ohne, dass eine Person zum Zeitpunkt des Kaufs ein Konto erstellen oder Zahlungsdaten eingeben muss.

Vier Gruppen spielen in diesem Ökosystem eine zentrale Rolle:

• Agenten-Entwickler: Sie bauen und betreiben Agenten, wählen das Zahlungsprotokoll aus und verwalten die Anmeldedaten sowie die Logik der Agenten, um auf Zahlungsaufforderungen zu reagieren.

• Händler: Sie stellen Produkte und Preise agentenlesbar bereit, entscheiden, welche Netzwerke und Modelle akzeptiert werden, und verlassen sich auf ihren Payment Service Provider (PSP) für Orchestrierung, Kontrollen und Settlement, damit agentengesteuerte Käufe in bestehende Abrechnungsabläufe passen.

• PSPs: Sie verbinden den agentengesteuerten Checkout mit den Systemen des Händlers, indem sie die Orchestrierung, die Durchsetzung von Richtlinien, Risikokontrollen und die Abwicklung über verschiedene Netzwerke hinweg übernehmen.

• Käufer: Sie legen die Ziele für Agenten fest, wählen die Finanzierungsquelle (Karten, Guthaben, Stablecoins), definieren Limits sowie Genehmigungen und überprüfen die Nutzung und Ausgaben, um Richtlinien im Laufe der Zeit anzupassen. Ein Käufer kann ein Unternehmen sein, das dem Agenten seines Entwicklerteams ein begrenztes monatliches Budget zuweist, oder eine Privatperson, die ihren persönlichen KI-Assistenten finanziert.

Ein Beispiel: Ein Entwickler (Käufer) nutzt einen KI-Coding-Agenten, um ein Feature zu entwickeln. Er stellt dem Agenten ein Budget von 50€ zur Verfügung, das dieser autonom für Infrastruktur und Daten ausgeben kann, die während des Prozesses benötigt werden.

Während der Aufgabe stößt der Agent (Produkt des Agenten-Entwicklers) bei seinem Inference-Anbieter an ein Rate-Limit und benötigt mehr Rechenleistung. Er lädt sein Guthaben direkt bei einem Cloud-Anbieter (Händler) auf, der nach Nutzungseinheiten abrechnet. Anschließend benötigt er Live-Preisdaten für eine Berechnung und fragt eine Marktdaten-API (Händler) ab, die pro Aufruf abrechnet. Schließlich muss er sein Ergebnis mit einem anderen Dienst testen und zahlt pro Anfrage für die Nutzung eines Drittanbieter-Tools (Händler).

Jede dieser Transaktionen ist eine diskrete, nutzungsbasierte Zahlung, die demselben Muster folgt: Der Agent übermittelt seine Identität und Kaufabsicht über ein für das Netzwerk geeignetes Protokoll an den Händler.

So weiß der Händler, dass er es mit einem autorisierten Agenten zu tun hat und was dieser kaufen möchte. Die Zahlung wird dann über das jeweils passende Netzwerk abgewickelt: eine zweckgebundene virtuelle Karte für den einen Händler oder eine Stablecoin-Wallet mit Echtzeit-Abrechnung für den anderen. Jeder Händler wendet seine eigenen Richtlinien an und entscheidet, wie viel er an einen nicht verifizierten Agenten verkauft, bevor ein echtes Konto oder zusätzliche Prüfungen erforderlich sind. Anstelle eines einzelnen Zahlungsereignisses ist es daher sinnvoller, M2M als einen vielschichtigen Stack zu betrachten.

Um besser zu verstehen, wie Unternehmen an M2M Payments herangehen, haben wir Enterprise-Händler und Partner aus dem Ökosystem nach den Chancen, Hürden und Anwendungsfällen gefragt, die sie sehen. Aus diesen Gesprächen haben sich drei zentrale Themen herauskristallisiert.

Thema 1: Nachfrage ist real, aber fokussiert

Datenstand: 26. Juni 2026; spiegelt den aktuellen Stand im Bereich Machine-to-Machine Payments zum Zeitpunkt der Verfassung wider.

Das Interesse an M2M Payments ist echt, aber die Nutzung befindet sich noch in der Frühphase und ist stark konzentriert. Ein Großteil des heutigen Volumens stammt aus Tests, Hackathons, Token-Käufen und anderen frühen digital-nativen Anwendungsfällen. Das spiegeln auch die Zahlen wider.

Mitte 2026 zeigen die beiden führenden Machine-Payment-Protokolle, das x402-Protokoll und MPP, eine vergleichsweise überschaubare Aktivität. Das x402-Protokoll hat seit Oktober ein kumuliertes Volumen von rund 50 Mio. $ verarbeitet, während MPP seit März etwa 200.000 $ abgewickelt hat. Die durchschnittlichen Transaktionswerte liegen etwa zwischen 0,05 $ und 0,30 $, wobei viele Marktteilnehmer erwarten, dass sich dieser Wert langfristig eher bei 0,50 $ einpendeln wird.

Die Nutzung stieg bei beiden Protokollen rund um den Start kurzzeitig an und ist in den letzten 30 Tagen zurückgegangen. Das deutet darauf hin, dass sich der Markt in einer experimentellen Entwicklungsphase befindet und noch nicht in einer nachhaltigen Skalierungsphase.

Was jedoch schwerer wiegt als die reinen Zahlen, ist die Frage, wo die Nachfrage entsteht.

Die stärksten Signale kommen von Unternehmen, deren Produkte sich bereits für eine nutzungsbasierte Abrechnung eignen: APIs, Rechenleistung, Daten, Messaging und modulare digitale Dienste. Diese Organisationen zeigen die höchste Bereitschaft zu experimentieren, da ihr Geschäftsmodell bereits auf kleine, wiederkehrende Transaktionen ausgelegt ist.

Für Unternehmen mit nutzungsbasierten Modellen sind M2M Payments keine Spielerei. Sie sind die Monetarisierungsinfrastruktur, die die Abrechnung winziger Nutzungseinheiten kommerziell überhaupt erst rentabel macht. Sobald es wirtschaftlich praktikabel wird, Bruchteile von Cent pro API-Aufruf, Rechenleistungseinheit oder Datenabfrage zu berechnen, werden Preismodelle realisierbar, die bisher nur theoretisch funktionierten.

Ein geringeres Interesse zeigt sich hingegen bei traditionelleren Abonnementsystemen und in Branchen mit hohen Sicherheits- und Compliance-Anforderungen. Obwohl viele M2M-Zahlungen langfristig als strategisch wichtig einstufen, liegen ihre unmittelbaren Herausforderungen an anderer Stelle.

Für Abo-Geschäfte bedeutet der Wechsel von vorhersehbaren, wiederkehrenden Einnahmen hin zu nutzungsbasierter Abrechnung einen Wandel des Geschäftsmodells – und häufig auch eine veränderte Bewertung des Unternehmens durch Investoren.

Für regulierte und sensiblere Branchen sieht die Herausforderung wieder anders aus: Bevor sie sich mit Zahlungsnetzwerken befassen, konzentrieren sie sich auf Betrugsprävention, Haftungsfragen, Governance und die Beibehaltung einer angemessenen Kontrolle über autonome Käufe.

Was Early Adopter vom Rest des Marktes unterscheidet, ist letztlich das Ausmaß, in dem ihr bestehendes Geschäftsmodell angepasst werden müsste:

• Gruppe 1: Vollständig neue, nutzungsbasierte Unternehmen: Von Grund auf neu entwickelt, mit nutzungsbasierter Abrechnung und agentengesteuerten Workflows vom ersten Tag an. Heute noch kleiner, aber oft die besten Design-Partner, da ihre Architektur bereits auf maschinengesteuerte Prozesse ausgelegt ist.

• Gruppe 2: Nutzungsorientierte digitale Unternehmen: Unterstützen bereits nutzungsbasierte Preise oder experimentieren damit. Diese Unternehmen sind am ehesten die nächsten Anwender, da ihr Modell bereits zu geringwertigen, wiederkehrenden und API-gesteuerten Käufen passt.

• Gruppe 3: Abo- und Festpreis-Unternehmen: Erkennen den Trend, sind operational aber noch nicht bereit. Hürden sind Anpassungen des Preismodells, Bedenken hinsichtlich Vertrauen und Compliance, unklare Nachfrage oder die Abhängigkeit von breiteren Produkt- und Go-To-Market-Änderungen über den reinen Zahlungsverkehr hinaus. Einige haben sich bisher noch gar nicht aktiv mit M2M beschäftigt und sehen darin aktuell keine Priorität.

Thema 2: Netzwerke werden koexistieren, nicht konkurrieren

In vielen aktuellen Debatten werden Kreditkarten und Stablecoins als konkurrierende Alternativen dargestellt.

Die Rückmeldungen der Händler zeichnen ein anderes Bild. Anstatt dass ein System das andere ersetzt, werden verschiedene Zahlungsnetzwerke wahrscheinlich unterschiedliche Teile der Transaktion abdecken.

Unter dem Begriff der Zahlungsnetzwerke werden oft zwei getrennte Fragen vermischt: wie ein Agent finanziert und für Transaktionen autorisiert wird und wie der Händler letztendlich seine Abrechnung erhält. Das sind zwei verschiedene Aufgabenstellungen, und die optimale Antwort kann für beide Seiten unterschiedlich aussehen.

So betrachtet wird das Hybridmodell greifbarer. Agenten können über kartenbasierte Autorisierungen oder Stablecoin-Wallets bezahlen, während Händler die Abrechnung über Batch-Verarbeitung, direkte Stablecoin-Auszahlung oder über Zwischenhändler erhalten. Die Frage ist weniger, welches Netzwerk gewinnt, sondern welches Netzwerk für die jeweilige Phase der Transaktion am sinnvollsten ist.

Thema 3: Der Mehrwert liegt in der Steuerungsebene

Die Bedenken der Händler konzentrieren sich durchweg auf drei Bereiche. Keiner davon ist völlig neu für M2M Payments, aber alle treten deutlicher zu Tage, je autonomer die Transaktionen ablaufen.

1. Betrug, Haftung und Risikoverteilung

Händlern fehlt die Klarheit darüber, wer haftet, wenn ein Agent fehlerhaft agiert, beispielsweise, wenn er etwas kauft, das nicht der Absicht des Nutzers entsprach. Sie sorgen sich darum, Rückbuchungen und operative Kosten tragen zu müssen, selbst wenn der Fehler auf der Seite des Agenten lag.

Streitfälle könnten komplexer werden, da es weniger Belege für die explizite Zustimmung des Nutzers gibt und Szenarien nach dem Motto „Das war der Agent“ zunehmen. Mehrere Händler befürchten zudem einen Anstieg von Friendly Fraud, wenn sich Kunden weniger stark mit den Transaktionen verbunden fühlen.

Ein Händler brachte es auf den Punkt: „Frühe agentische Abläufe bergen das Risiko, genau die Betrugs- und Autorisierungsmuster wieder einzuführen, die wir jahrelang erfolgreich eliminiert haben.“

Ebenso bleiben Fragen rund um Kaufabsicht, Autorisierung und die konkrete Ausgestaltung offen: Entscheidet im Zweifel das Zahlungsnetzwerk oder eine andere Instanz?

2. Kontrollverlust über Discovery und Checkout

Wenn sich Agenten zwischen Kundschaft und Händler schalten, befürchten viele Unternehmen den Verlust von Einblicken darüber, wie Kaufentscheidungen getroffen werden, welche Angebote angezeigt werden und welche Daten für Risikobewertung und Personalisierung erhalten bleiben.

Protokolle, die nur minimale Datenfelder an den Händler übermitteln, entfernen Gerätesignale, Verhaltensdaten und kontextuelle Informationen. Genau auf diese Signale greifen heutige Risikomodelle jedoch zurück, was die Unterscheidung von legitimem und schädlichem Traffic erschwert.

3. Operative Herausforderungen und Governance

Händler betonten wiederholt die Notwendigkeit neuer Governance-Strukturen, statt bloß neuer Zahlungsnetzwerke: interne Aufgaben zum Aufbau von Agenten-Richtlinien, Berechtigungen und Monitoring: im Grunde eine Disziplin nach dem Prinzip „Know Your Agent“. Für Unternehmen ohne nutzungsbasiertes Geschäftsmodell wirft der Umstieg von Abonnements oder Festpreisen auf eine feingliedrige, agentengesteuerte Abrechnung Zudem Fragen zu Preisgestaltung, Prognosen und Reporting auf.

Jede dieser Sorgen weist weg vom reinen Zahlungsnetzwerk und hin zur Kernfrage: Nicht, ob die Zahlung durchgeführt werden kann, sondern wie sie gesteuert und überwacht wird.

Das klare Signal der Händler lautet: Die eigentliche Herausforderung ist nicht der Geldtransfer. Es sind die Verifizierung der Identität und die Durchsetzung von Ausgabenrichtlinien. Die Unternehmen, die im autonomen Commerce den größten Mehrwert schaffen werden, sind diejenigen, die zwei Fragen verlässlich beantworten können:

• „Ist dieser Agent wirklich der, der er vorgibt zu sein?“

• „Agiert diese Transaktion innerhalb der vorgegebenen Regeln?“

Bei all den Diskussionen über Netzwerke und Kontrolle sind die Fragen, die Händler am häufigsten stellen, oft grundlegender Natur.

Der erste Punkt ist die Auffindbarkeit (Discoverability).

Bevor ein Agent für etwas bezahlen kann, muss er es finden. Die meisten Händler arbeiten derzeit noch daran, ihre Seiten und Kataloge überhaupt maschinenlesbar zu machen. Hierauf richtet sich aktuell ein Großteil der Aufmerksamkeit: Nicht „Wie werden wir von einem Agenten bezahlt?“, sondern „Wie erfährt ein Agent überhaupt, was wir verkaufen?“.

Der zweite Punkt ist die Passung zum Monetarisierungsmodell.

Maschinengesteuerte Käufe setzen eine nutzungsbasierte Abrechnung voraus. Die meisten Händler sind jedoch nicht darauf ausgelegt. Der Wechsel von Abonnements oder Festpreisen zu einer Abrechnung pro Einheit wirft strategische Fragen auf: Passt das Modell zum Unternehmen? Wie sehen Preisgestaltung, Prognosen und Reporting aus? Und ist das Modell mit der bestehenden kaufmännischen Logik vereinbar? Für nutzungsbasierte Unternehmen ist das ein kleiner Schritt; für alle anderen ein strategischer Wandel, der geklärt werden muss, bevor M2M Payments überhaupt relevant werden.

Beide Punkte führen zur selben Erkenntnis.

Aus Sicht der Händler sind Protokolldiskussionen und neue Zahlungsnetzwerke Nebenschauplätze – solange Agenten nicht finden können, was verkauft wird, und solange das Geschäftsmodell nicht zu einer nutzungsbasierten Abrechnung im Maschinenmaßstab passt.

Machine-to-Machine Payments stehen erst am Anfang. Ein Großteil des heutigen Traffics ist simuliert oder experimentell – geprägt von Tests, Hackathons und Token-Aktivitäten – und stellt noch keine dauerhafte Nachfrage im Produktionsmaßstab dar. Für Händler ist es daher sinnvoll, M2M als ein entstehendes Muster zu betrachten, das beobachtet werden sollte, anstatt einem unreifen Markt sofort hinterherzulaufen. In diesem Kontext ist die Wahl des Zahlungsnetzwerks weniger entscheidend, als es scheint. Karten, Guthaben und Stablecoins werden voraussichtlich alle ihre Rolle spielen. Die eigentliche Aufgabe, die Händler beschreiben, lautet jedoch nicht: „Kann ein Agent Geld bewegen?“, sondern: „Können wir steuern, was Agenten tun?“. Der echte Hebel liegt in der Governance-Ebene: Wie Identität etabliert wird, welche Limits gesetzt werden, wie Kaufabsichten definiert und wie Ausgabenrichtlinien durchgesetzt werden, wenn Agenten im Namen von Personen oder Unternehmen handeln.

Für die meisten Händler ist die nützlichste Arbeit derzeit vorbereitender Natur.

Die Priorität liegt darin, Produkt und Architektur bereit für Agenten zu machen – indem zumindest Teile des Katalogs maschinenlesbar gestaltet werden, geprüft wird, wo nutzungsbasierte Preise sinnvoll sind, und klare interne Regeln dafür definiert werden, wie Agenten identifiziert, autorisiert und mit Budgets ausgestattet werden.

Das unmittelbare Risiko für die meisten Händler besteht nicht darin, einen reifenden Markt zu verpassen. Es besteht darin, sich nicht auf die Fragen der Governance und Infrastruktur vorzubereiten, die entscheidend werden, sobald die Kategorie im Alltag ankommt.