In deinem Magento-B2B-Portal melden sich Einkäufer heute mit Benutzername, Passwort und vielleicht einem zweiten Faktor an. Mit Mastercard Agent Pay kommt eine Frage dazu, die dieses Modell auf den Kopf stellt: Wie authentifizierst du einen Einkäufer, der gar kein Mensch ist, sondern ein KI-Agent, der im Auftrag eines Unternehmens bestellt? Mastercard hat darauf am 29. April 2025 eine konkrete technische Antwort gegeben. Dieser Beitrag erklärt, was sich an der Authentifizierung ändert, welche drei Bausteine dahinterstecken und was du in deinem Magento-Portal dafür vorbereiten solltest.
Warum Passwort und 2FA für KI-Agenten nicht mehr passen
Der klassische Login ist auf einen Menschen ausgelegt. Jemand tippt Zugangsdaten ein, bestätigt eine Push-Benachrichtigung, klickt „Bestellung abschließen”. Jeder Schritt setzt voraus, dass am anderen Ende eine Person sitzt, die reagieren kann.
Ein autonomer Einkaufs-Agent passt da nicht hinein. Er ruft keine Storefront auf, er liest keine SMS, und er soll Routinebestellungen gerade ohne menschliches Eingreifen abwickeln. Ein Passwort-Feld, in das nie ein Mensch tippt, ist kein Sicherheitsmerkmal — es ist eine Angriffsfläche. Genauso wenig hilft eine 2FA, die niemand bestätigt.
Damit verschiebt sich die Kernfrage. Sie lautet nicht mehr „Ist das Passwort korrekt?”, sondern: Ist das ein registrierter, vertrauenswürdiger Agent — und hat ihn jemand mit den nötigen Befugnissen autorisiert? Genau hier setzt Mastercard Agent Pay an. Es ist nicht das einzige Modell am Markt — Visa verfolgt mit dem Trusted Agent Protocol (TAP) einen vergleichbaren Ansatz, Google mit kryptografisch signierten Mandaten unter AP2. Mastercard bringt aber etwas mit, das im Zahlungsverkehr seit Jahren erprobt ist: Tokenisierung.
Mastercard Agent Pay: Authentifizierung über Agentic Tokens statt Login
Im Kern ist Mastercard Agent Pay ein Framework, mit dem verifizierte KI-Agenten im Namen eines Käufers bezahlen — über sogenannte Agentic Tokens. Diese Tokens sind keine Neuerfindung, sondern eine Erweiterung des Mastercard Digital Enablement Service (MDES), derselben Tokenisierungs-Infrastruktur, die schon kontaktloses Bezahlen, Card-on-File und Mastercard Payment Passkeys absichert.
Das Prinzip: Statt einer rohen Kartennummer wird ein kryptografisch gesichertes, dynamisches Token erzeugt. Dieses Token ist gebunden an einen bestimmten Agenten, einen definierten Händler-Rahmen und eine konkrete Einwilligung (Consent). Ein Modell wie ChatGPT oder Microsoft Copilot kann damit einen Checkout abschließen, ohne die echte Kartennummer je zu sehen. Jede Transaktion bleibt nachvollziehbar und authentifiziert.
Für dich als Shopbetreiber ändert sich damit die Vertrauensbasis. Bisher hast du dich darauf verlassen, dass ein Login korrekt war. Künftig bekommst du ein netzwerkseitig verifiziertes Token, das dir sagt: Dieser Agent ist registriert, und er ist für genau diesen Betrag bei genau diesem Händler autorisiert. Die Authentifizierung wandert vom Frontend deines Portals in die Zahlungsschicht — und wird dadurch prüfbar, statt nur plausibel.
Die drei Bausteine: Intent, Tokenisierung, Agent-Identität
Mastercard beschreibt das Framework über drei Säulen. Sie sind die eigentliche Antwort auf die Frage, wie ein Agent authentifiziert wird:
| Baustein | Was er beantwortet | Wie er technisch greift |
|---|---|---|
| Intent | Wollte der Mensch das wirklich? | Einwilligung wird erfasst und verifiziert, oft über Biometrie (On-Device) und Mastercard Payment Passkeys |
| Tokenisierung | Ist die Zahlung sicher und rückverfolgbar? | Agentic Token aus MDES, gebunden an Agent, Händler-Scope und Consent — ohne rohe Kartendaten |
| Agent-Identität | Ist das überhaupt ein legitimer Agent? | Nur registrierte und verifizierte Agenten dürfen transagieren; jede Transaktion ist über Netzwerk-Token zuordenbar |
Besonders der erste Punkt ist für den B2B-Kontext entscheidend. Mastercard formuliert es so, dass die Absicht des Nutzers nicht angenommen, sondern verifiziert wird. Der Mensch legt einmalig einen Rahmen fest — etwa Ausgabe-Limits, erlaubte Händler und ein Ablauffenster — und der Agent handelt nur innerhalb dieser Leitplanken autonom. Das ist im Prinzip dasselbe Muster, das du aus genehmigungspflichtigen B2B-Bestellungen in Magento kennst: ein vorab definiertes Mandat, innerhalb dessen ohne weitere Rückfrage bestellt werden darf.
Was sich in deinem Magento-B2B-Portal ändert
Mastercard Agent Pay regelt die Zahlung — aber damit der Agent bei dir überhaupt sauber bestellen kann, muss dein Portal mitspielen. Drei Bereiche werden konkret berührt:
1) Identität statt Login. Du brauchst eine Vorstellung davon, wie ein „Agenten-Account” zu einem realen Unternehmenskonto gehört. Magentos B2B-Features liefern dafür die Grundlage: Über Unternehmenshierarchien (Company Accounts) lässt sich ein Agent als eingeschränkte Rolle unter dem Firmenkonto abbilden — mit eigenen Berechtigungen, aber denselben Rahmenverträgen und Preislisten wie der menschliche Einkäufer.
2) Maschinenlesbare Schnittstellen. Ein Agent klickt sich nicht durch Kategorien, er fragt Daten ab. Sauber gepflegte Produktattribute, Verfügbarkeiten und kundenspezifische Preise müssen über eine API erreichbar sein — sei es über GraphQL als Schlüssel für Agentic Commerce oder über eigene REST-Endpoints für individuelle Anforderungen. Liefert dein Shop hier inkonsistente Daten, bricht ein gewissenhafter Agent die Transaktion ab, bevor das Token überhaupt zum Einsatz kommt.
3) Unterscheidung gut/böse. Wenn legitime Kauf-Agenten zur Norm werden, brauchst du im Backend einen Weg, sie von schädlichen Bots zu trennen. Ein verifizierter Agentic Token ist dabei ein starkes Signal — aber er ersetzt nicht die Frage, wie du im Magento-Backend zwischen legitimen Agenten und böswilligen Bots unterscheidest. Beide Ebenen — Zahlungs-Token und Shop-seitige Bot-Erkennung — greifen ineinander.
DSRP und DTVC: Wie der Token im Checkout ankommt
Für die Praxis am interessantesten ist, wie das Token bei dir landet. Mastercard sieht zwei Wege vor — und der zweite ist explizit für Händler gedacht, die nicht sofort tief integrieren wollen.
- DSRP (Digital Secure Remote Payment) ist der Weg mit voller Sicherheit. Er setzt voraus, dass dein Checkout die angereicherten Token-Daten verarbeiten kann. Hier kommt die gesamte Metadaten-Kette zum Tragen, mit der Mastercard die Transaktion absichert und für die Betrugserkennung anreichert.
- DTVC (Dynamic Token Verification Code) ist der No-Code-Fallback. Der verifizierte Agent trägt einen dynamischen Code in die bestehenden Kartenfelder deines Checkouts ein — formatiert wie eine normale Kartenzahlung. Dein Shop muss dafür zunächst nichts umbauen.
Das ist für den österreichischen Mittelstand eine pragmatische Nachricht: Du musst nicht am Tag eins die volle Agentic-Infrastruktur stehen haben, um überhaupt teilzunehmen. Mastercard arbeitet zudem in der FIDO Payments Working Group an portablen, datensparsamen Verifiable Credentials und hält Integrationswege zu Agenten-Protokollen wie MCP, A2A und ACP offen. Das Framework ist also bewusst nicht als geschlossenes System gebaut.
Trotzdem gilt: Der No-Code-Weg ist der Einstieg, nicht das Ziel. Sicherheit und Datenschutz musst du eigenständig mitdenken — gerade weil hier Zahlungs- und Identitätsdaten von Agenten durch dein System laufen. Was dabei Magento-Betreiber bei KI-Agenten und Datenschutz beachten müssen, gehört in jede Planung von Anfang an hinein.
Was du als nächstes tun kannst
Du musst Mastercard Agent Pay heute nicht produktiv schalten, um vorbereitet zu sein. Drei Schritte, die sich jetzt lohnen:
- Identitätsmodell klären. Schau dir an, wie deine B2B-Kunden in Magento abgebildet sind. Gibt es Company Accounts mit Rollen, oder hängt alles an Einzel-Logins? Ein sauberes Rollenmodell ist die Voraussetzung dafür, später einen Agenten kontrolliert einzubinden.
- API-Fitness prüfen. Liefert dein Shop kundenspezifische Preise, Lagerstände und Produktdaten verlässlich über GraphQL oder REST? Das ist der Punkt, an dem agentenfähige Portale sich von reinen Storefronts trennen.
- Authentifizierungs-Audit anfragen. Wir schauen uns an, wo dein Magento-Portal zwischen klassischem Login und agentenbasierter Authentifizierung steht — und was ein realistischer erster Schritt ist. Kontakt: office@copex.io oder direkt über die Kontaktseite.
Wie wir Identität, Rollen und maschinenlesbare Schnittstellen konkret aufsetzen, zeigen unsere Service-Seiten zu Magento-Schnittstellen, Magento-Entwicklung und Magento-Sicherheit.
Die Authentifizierung im B2B-Handel verschiebt sich gerade von „Wer bist du?” zu „Was darfst du innerhalb welcher Grenzen tun?”. Mastercard Agent Pay liefert dafür den Zahlungs-Baustein — den Rest baust du in deinem Magento-Portal. Wer beides zusammendenkt, ist vorbereitet, wenn der erste Agent an deinem Checkout anklopft.
