Digitale Nachweise & Zahlungen: Die Wallet-Strategien von Apple und Google

Digitale Zahlungen entwickeln sich ständig weiter. Wir wollen, dass sie schneller, sicherer und einfacher zu nutzen sind. Gleichzeitig werden digitale Identitätswerkzeuge wie Verifiable Credentials (VCs) und mobile Identitätsdokumente (mdocs) immer besser. Sie bieten neue Möglichkeiten, die eigene Identität nachzuweisen. Die große Frage ist also: Können diese neuen digitalen Identitäten auch digitale Zahlungen deutlich verbessern oder vereinfachen?

Dieser Artikel beleuchtet, wie digitale Nachweise (einschließlich ISO mdocs und VCs, die über OpenID4VC gesendet werden) mit der Welt der Zahlungen zusammenhängen. Wir behandeln folgende Themen:

• Wie aktuelle Smartphone-Wallets (Apple Wallet, Google Wallet) Identitätsinformationen im Vergleich zu Zahlungskarten handhaben.
• Warum aktuelle digitale ID-Standards wie ISO 18013-5/7 mdocs nicht wirklich als direkte Zahlungsinstrumente geeignet sind.
• Welche Rolle Protokolle wie OpenID4VC bei zukünftigen Zahlungsmethoden spielen könnten.
• Wie andere (Drittanbieter-) Wallet-Apps Zahlungsfunktionen handhaben könnten.
• Die Hauptprobleme und was in Zukunft bei dem Versuch, Verifiable Credentials in Zahlungssystemen zu verwenden, passieren könnte.

Dieser Text ergänzt unsere Diskussion über Digitale Nachweise & Passkeys und konzentriert sich dabei ausschließlich auf das Thema Zahlungen.

Um zu sehen, wie digitale Nachweise bei Zahlungen eingesetzt werden könnten, müssen wir zunächst verstehen, wie die wichtigsten mobilen Plattformen und ihre integrierten Wallets (Apple Wallet, Google Wallet) Identitätsinformationen von der Zahlungsabwicklung getrennt halten.

Native Plattform-Wallets sind zu hochentwickelten Hubs für Nutzer geworden, aber sie halten typischerweise eine klare Trennung zwischen Identitätsnachweisen und Zahlungsinstrumenten aufrecht:

• Identitätsnachweise (z. B. mDLs):
  • Apple Wallet: Unterstützt hauptsächlich mobile Führerscheine (mDLs) und staatliche Ausweise, die mit ISO/IEC 18013-5 konform sind. Seit der WWDC25 hat Apple bestätigt, dass Safari 26 (in iOS 26) die W3C Digital Credentials API für die Online-Präsentation unterstützen wird, mit einem exklusiven Fokus auf das org.iso.mdoc-Protokoll. Dies dient der Überprüfung von Identitätsattributen (z. B. Name, Alter, Adresse), nicht für Zahlungen.
  • Google Wallet & Android Credential Manager: Google Wallet unterstützt ebenfalls mDLs basierend auf ISO 18013-5. Der zugrunde liegende Android Credential Manager bietet ein flexibleres Framework. Während seine Implementierung der Digital Credentials API protokollunabhängig ist, bietet Android eine Standardimplementierung, die OpenID4VP als Transportmechanismus verwendet.
• Zahlungsinstrumente (z. B. Kredit-/Debitkarten):
  • Sowohl Apple Pay (innerhalb von Apple Wallet) als auch Google Pay (innerhalb von Google Wallet) nutzen etablierte, stark regulierte Zahlungstechnologien. Diese basieren hauptsächlich auf EMV-Standards (Europay, Mastercard, Visa) und umfassen Tokenisierung (Device PANs oder DPANs, die die tatsächlichen Kartennummern für Transaktionen ersetzen), Secure Elements oder hardwaregestützte Sicherheit zur Speicherung von Zahlungstoken und dynamische Kryptogramme zur Transaktionssicherheit.
  • Diese Zahlungssysteme interagieren direkt mit bestehenden Zahlungsnetzwerken (Visa, Mastercard, Amex usw.) und Acquirer-Banken.

Wichtigste Erkenntnis: Native Plattform-Wallets arbeiten derzeit mit getrennten „Stacks“ oder Technologien für Identitätsnachweise im Vergleich zu Zahlungskarten. Ein mdoc wird vorgelegt, um ein Identitätsattribut nachzuweisen; eine tokenisierte Karte wird vorgelegt, um eine Zahlung zu tätigen. Es gibt keine direkte Verwendung eines mdoc als Zahlungsinstrument innerhalb dieser nativen Ökosysteme.

Der Standard ISO/IEC 18013-5 definiert die Datenstruktur für mDLs und andere mobile Ausweise (mdocs). Obwohl er sich hervorragend für die Identitätsprüfung eignet, ist sein Design für die direkte Verwendung als Zahlungsinstrument ungeeignet:

Selbst wenn ein mdoc theoretisch benutzerdefinierte Datenfelder enthalten könnte, um eine PAN oder ein Zahlungstoken zu speichern (da ISO 18013-5 benutzerdefinierte Namespaces erlaubt), definiert der mdoc-Standard selbst nicht:

• Wie dynamische Zahlungskryptogramme erzeugt oder verarbeitet werden.
• Wie eine Online-Autorisierung bei einem Zahlungsnetzwerk durchgeführt wird.
• Die notwendigen Sicherheitsmechanismen, die spezifisch für Zahlungstransaktionen sind (über die Integrität von Identitätsdaten hinaus).

Daher gibt es derzeit keine Möglichkeit, ein ISO 18013-5 mdoc als direktes Zahlungsinstrument zu verwenden.

Obwohl ein mdoc kein Zahlungsmittel ist, kann es eine Rolle in einem „Step-Up-Authentifizierungs“-Ablauf spielen, bei dem die Identität eines Nutzers für eine risikoreiche Aktion explizit überprüft werden muss. Dies unterscheidet sich von der Verwendung zur Durchführung der Zahlung selbst. Der Ablauf würde typischerweise so aussehen:

1. Primäre Authentifizierung: Der Nutzer meldet sich bei einem Dienst an, oft mit einer reibungslosen Methode wie einem Passkey.
2. Auslöser für Step-Up: Für eine hochsichere Aktion (z. B. eine große Banküberweisung, Aktualisierung persönlicher Daten) verlangt der Dienst eine explizite Identitätsprüfung.
3. mdoc-Präsentation: Der Dienst fordert die Vorlage des mdoc des Nutzers (z. B. Führerschein). Der Nutzer präsentiert die erforderlichen Attribute aus seiner Wallet.
4. Verifizierung: Der Dienst überprüft die mdoc-Daten kryptografisch gegen eine vertrauenswürdige Quelle oder eine zuvor registrierte Identität.

In diesem Modell liefert der mdoc einen starken, Phishing-resistenten Identitätsnachweis für einen spezifischen, risikoreichen Moment. Die anschließende Finanztransaktion nutzt jedoch weiterhin etablierte Zahlungsschienen. Der mdoc verifiziert die Person, nicht die Zahlungsmethode.

Obwohl mdocs selbst keine Zahlungsinstrumente sind, bieten Protokolle wie OpenID for Verifiable Credentials (OpenID4VC – einschließlich OpenID4VP für die Präsentation und OpenID4VCI für die Ausstellung) eine flexiblere Transportschicht.

Hauptmerkmale von OpenID4VC:

• Protokoll, nicht Payload: OID4VC definiert, wie VCs angefordert und präsentiert werden, ist aber weitgehend agnostisch gegenüber dem Format des VC-Payloads selbst. Es kann mdocs, W3C-Standard-VCs (z. B. im JWT- oder SD-JWT-Format) oder andere benutzerdefinierte Credential-Typen transportieren.
• Breite der Anwendungsfälle: Diese Flexibilität ermöglicht es Plattformen wie Android (über seinen Credential Manager), Anfragen für verschiedene Arten von Nachweisen über einen gemeinsamen Mechanismus zu unterstützen.
• Zukünftige Kompatibilität für Zahlungs-VCs: Sollte die Zahlungsbranche ein nachweisbares „Zahlungstoken“ oder ein „Zahlungsautorisierungs“-Credential-Format standardisieren, könnte OID4VC theoretisch ein solches Credential zwischen der Wallet eines Nutzers und einem Händler/PSP transportieren.

OID4VC selbst ist jedoch keine Zahlungslösung:

• Die Rolle von OID4VC besteht darin, den Austausch eines Nachweises zu erleichtern. Es definiert nicht den Inhalt, die Sicherheitsmerkmale oder die Interaktion des Zahlungs-Credentials mit Zahlungsabwicklungssystemen.
• Damit OID4VC für Zahlungen nützlich ist, müsste zunächst ein weithin akzeptiertes, sicheres und standardisiertes nachweisbares Zahlungs-Credential-Format entwickelt und vom Zahlungsökosystem (Issuer, Acquirer, Netzwerke) unterstützt werden. Dies existiert derzeit nicht.

Über die nativen Plattform-Wallets hinaus entsteht ein wachsendes Ökosystem von Drittanbieter-Wallets (z. B. EUDI Wallet, von Banken bereitgestellte Wallets, spezialisierte Branchen-Wallets). Diese Wallets müssen den fundamentalen Unterschied zwischen schneller, reibungsloser Authentifizierung und hochsicherer Attributverifizierung bewältigen, insbesondere im Zahlungskontext.

Der aufkommende Konsens ist, dass Passkeys ideal für die Kern-Authentifizierung bei einem Zahlungsdienst sind, da sie Phishing-resistent und für ein nahtloses Nutzererlebnis konzipiert sind. Das Einfügen einer digitalen Credential-Präsentation in den kritischen Schritt der Zahlungsbestätigung würde erhebliche Reibung verursachen und wahrscheinlich die Konversionsraten beeinträchtigen. Daher liegt die primäre Rolle digitaler Nachweise in der einmaligen, hochsicheren Onboarding- und KYC-Phase, die Zahlungsfähigkeiten ermöglicht, und nicht in der Transaktion selbst. Wie könnten diese Wallets Zahlungen angehen, insbesondere in Verbindung mit digitalen Identitätsmerkmalen?

Damit eine Drittanbieter-Wallet eine Zahlung autorisieren kann, muss sie von der App oder Website des Händlers aufgerufen werden können. Dafür gibt es mehrere etablierte Interaktionsmodelle, jedes mit unterschiedlichen Graden an Plattformintegration und Nutzererlebnis:

• App-zu-App Deep Linking: Dies ist eine universelle Methode, bei der die Anwendung des Händlers (nativ oder webbasiert) den Nutzer über ein benutzerdefiniertes URL-Schema (z. B. eudi-wallet://...) zur Drittanbieter-Wallet-App weiterleitet. Die Transaktionsdetails werden als Parameter in der URL übergeben. Nachdem der Nutzer die Zahlung in der Wallet-App bestätigt hat, leitet diese über einen weiteren Deep Link zurück zur Händler-App. Dies funktioniert sowohl auf iOS als auch auf Android, beinhaltet aber einen sichtbaren Kontextwechsel zwischen den Apps.
• Native Wallet-Auswahl: Mit der nativen Wallet-Auswahl kann eine Anwendung einen generischen Systemdienst aufrufen, der alle registrierten Zahlungs-Handler oder Wallets anzeigt. Der Nutzer kann dann seine bevorzugte Wallet aus einer vom System bereitgestellten Benutzeroberfläche auswählen. Dies bietet ein integrierteres Gefühl als einfaches Deep Linking (Digital Credential API).
• Einfache QR-Code-basierte Zahlungen: Dieses Modell ist ideal für Desktop-zu-Mobil-Abläufe. Die Website des Händlers zeigt einen QR-Code an, der die Transaktionsdetails oder eine URL enthält. Der Nutzer scannt diesen Code mit seiner mobilen Wallet-App, die dann die Bestätigung auf dem Telefon unabhängig abwickelt. Das Backend der Wallet kommuniziert dann die Genehmigung an das System des Händlers zurück.
• Standardisierte geräteübergreifende Abläufe (FIDO CTAP): Als Weiterentwicklung der QR-Code-Methode nutzt dies Protokolle wie das Client to Authenticator Protocol (CTAP) von FIDO, um einen direkten, sicheren und verschlüsselten Kanal zwischen dem Desktop-Browser (Client) und der mobilen Wallet (die als Authenticator fungiert) zu schaffen. Dies ist sicherer als einfache QR-Codes, da Browser und Telefon direkt kommunizieren – ein Modell, das von Google sowohl für Passkeys als auch für digitale Nachweise stark unterstützt wird.
• Direkte Backend-Integration: In einigen geschlossenen Systemen könnte die Drittanbieter-Wallet-App direkt mit einem Payment Service Provider (PSP) oder dem Backend eines Finanzinstituts interagieren, um Zahlungen abzuwickeln, oft unter Verwendung proprietärer APIs.

Diese Modelle bilden die „Transportschicht“ zur Initiierung einer Zahlungsbestätigung, innerhalb derer dann ein kryptografischer Fluss (wie der für die EUDI Wallet beschriebene) stattfinden kann.

Mit den Ankündigungen auf der WWDC25 ist die Landschaft, wie Browser digitale Nachweise handhaben, viel klarer geworden und hat die Trennung zwischen Identitätsprüfung und Zahlungsabwicklung gefestigt. Plattformen ermöglichen es Drittanbieter-Wallets, mit Browsern zur Identitätsprüfung über die W3C Digital Credentials API zu interagieren, aber die Ansätze gehen auseinander:

• Apples Haltung (bestätigt auf der WWDC25): Apple hat offiziell die Unterstützung für die Digital Credentials API in Safari 26 (wird mit iOS 26 ausgeliefert) angekündigt. Wie in ihrer Session „Verify identity documents on the web“ detailliert, unterstützt die Implementierung ausschließlich das org.iso.mdoc-Protokoll. Dies ermöglicht es Websites, verifizierbare Informationen von mdocs in der Apple Wallet oder anderen registrierten Drittanbieter-Dokumenten-Apps anzufordern, unterstützt aber nicht das allgemeinere OpenID4VP-Protokoll. Mit zunehmender Unterstützung für digitale Nachweise und verbesserte Web-Integrationen wird die Aufrechterhaltung der Systemleistung und -sicherheit noch wichtiger – Tools wie CleanMyMac helfen sicherzustellen, dass Ihr Mac reibungslos läuft, während sich diese Technologien weiterentwickeln.
• Googles Haltung: Der Credential Manager von Android ermöglicht es Drittanbieter-Wallets, sich als Handler für Credential-Anfragen zu registrieren. Seine Implementierung der Digital Credentials API in Chrome konzentriert sich auf die Verwendung von OpenID4VP als primäres Transportprotokoll. Obwohl OpenID4VP ein mdoc als Payload transportieren kann, unterscheidet sich das Protokoll selbst von Apples direktem org.iso.mdoc-Ansatz.

Entscheidend ist, dass diese Browser-Integrationen für Identitätsattribute gedacht sind, nicht dafür, das präsentierte mDoc oder VC als Zahlungsinstrument zu behandeln.

Wenn ein Nutzer ein mDL aus seiner Wallet über die Digital Credentials API des Browsers einer Website präsentiert, könnte diese Website die Informationen zum Vor-Ausfüllen von Adressen oder zur Altersüberprüfung während des Checkouts verwenden. Der eigentliche Zahlungsschritt würde jedoch immer noch eine separate Interaktion mit einer Zahlungsmethode erfordern (z. B. Apple Pay, Google Pay oder die Eingabe von Kartendetails). Die Browser-API selbst ist nicht dafür ausgelegt, eine Finanztransaktion mit einem Identitätsnachweis zu initiieren oder zu verarbeiten.

Die EU Digital Identity (EUDI) Wallet dient als hervorragendes Fallbeispiel dafür, wie eine Drittanbieter-Wallet die komplexe, reale Landschaft von Betriebssystemen und API-Verfügbarkeit navigieren muss. Unter ihren vielen Funktionen sind zwei der prominentesten Anwendungsfälle die Identitätsprüfung und die Zahlungsbestätigung. Die technischen Wege, um diese beiden Aufgaben zu erfüllen, sind unterschiedlich, insbesondere wenn man das flexible Framework von Android mit der starreren Implementierung von Apple vergleicht.

Die folgende Tabelle zeigt, wie die EUDI Wallet entweder zur Identitätsprüfung oder zur Zahlungsautorisierung aufgerufen werden kann, und hebt die unterschiedliche Unterstützung auf den Plattformen hervor.

Wichtige Erkenntnisse aus dem Vergleich:

• Digital Credentials API: Dieser aufstrebende W3C-Standard ist protokollunabhängig und wird für Identität auf beiden Plattformen gut unterstützt. Für seine Implementierung bietet Android einen Standardablauf mit dem flexiblen OpenID4VP-Protokoll, das verschiedene Credential-Formate transportieren kann. Apples Implementierung hingegen ist streng auf das org.iso.mdoc-Format ausgelegt. Entscheidend ist, dass Browser diese API für Identitätsanwendungsfälle und nicht zur Initiierung von Zahlungen verwenden.
• Nativer Wallet-Selektor: Beide Betriebssysteme bieten eine native Benutzeroberfläche zur Auswahl einer Wallet, jedoch mit unterschiedlichen Einschränkungen. Android bietet einen Selektor für sowohl Identitäts- als auch Zahlungs-Apps. iOS bietet einen Selektor für registrierte Identitäts-„Document Provider“-Apps, aber keinen für Drittanbieter-Zahlungs-Apps.
• App-zu-App Deep Linking: Dies ist das universelle Arbeitspferd, das für sowohl Identitäts- als auch Zahlungsanwendungsfälle auf beiden Plattformen zuverlässig funktioniert. Es bleibt die primäre Methode, um eine Drittanbieter-Wallet für Zahlungen auf iOS aufzurufen.
• Standardisiertes Cross-Device: Dieser FIDO-CTAP-basierte Ablauf ist derzeit ein Merkmal des Google/Android-Ökosystems und wird auf iOS nicht unterstützt.

(*) Hinweis zu Zahlungen über die DC API: Obwohl die Verwendung von OpenID4VP durch Android einen Zahlungsablauf über die Digital Credentials API technisch machbar macht, ist dies nicht der primäre Designfokus. Eine nahtlose Integration für Zahlungen über diese spezifische API, im Gegensatz zu anderen nativen Methoden, bleibt abzuwarten und würde eine explizite Unterstützung von Browser-Anbietern erfordern.

Dieser Vergleich macht deutlich, dass, während die Identitätsprüfung zunehmend durch die Digital Credentials API standardisiert wird, die Zahlungsautorisierung für Drittanbieter-Wallets wie die EUDI Wallet immer noch stark auf traditionelleren nativen Integrationsmustern wie App-zu-App Deep Linking beruht, insbesondere auf iOS.

Unabhängig davon, welches Zahlungsintegrationsmodell zum Aufrufen der Wallet verwendet wird, beruht der Kern der Zahlungsbestätigung der EUDI Wallet auf einem standardisierten kryptografischen Ablauf, der in EWC RFC008 detailliert ist.

Unten finden Sie eine übergeordnete Darstellung dieses Prozesses:

Dies ist ein nicht-normatives Beispiel für das payment_data-Objekt, das an die Wallet gesendet wird und die Transaktion zur Bestätigung durch den Nutzer detailliert.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

Nachdem der Nutzer zugestimmt hat, erstellt die Wallet ein Key-Binding-JWT. Dessen Claims beweisen, dass der Nutzer die spezifischen Transaktionsdaten bestätigt hat.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

Während sich die technischen Standards weiterentwickeln, steht die Zahlungsbranche nicht still. Wichtige Akteure erforschen aktiv, wie die Sicherheit digitaler Nachweise mit der Funktionalität von Zahlungen verschmolzen werden kann.

Eine gute Möglichkeit, das Potenzial von Verifiable Credentials (VCs) zu verstehen, ist der Vergleich mit den erfolgreichen Netzwerk-Zahlungstokenisierungssystemen (wie dem Visa Token Service oder Mastercard MDES).

• Zahlungs-Tokenisierung ersetzte die sensible Primary Account Number (PAN) durch ein sicheres Token und ein einmaliges Kryptogramm. Dies schützt das Kern-Asset – die Kartennummer – während der Transaktionen.
• Verifiable Credentials zielen darauf ab, für persönliche Daten das zu tun, was die Tokenisierung für PANs getan hat. Anstatt Rohdaten (Name, Geburtsdatum, Adresse) zu teilen, präsentiert der Nutzer einen kryptografisch signierten Nachweis von einem vertrauenswürdigen Issuer.

Im Wesentlichen ist ein VC für persönliche Daten das, was ein Zahlungstoken und ein Kryptogramm für Kartendaten sind: ein sicherer, überprüfbarer Ersatz, der das Risiko reduziert und die Privatsphäre erhöht.

Aufbauend auf dieser Parallele arbeiten Branchengremien am Konzept eines „nachweisbaren Zahlungs-Credentials“. Dies wäre ein von einer Bank ausgestellter Nachweis, der ein Zahlungsinstrument (wie eine tokenisierte Karte) bündelt und zur Autorisierung von Transaktionen verwendet werden kann.

• EMVCo, das Standardisierungsgremium für sichere Zahlungen, integriert aktiv FIDO-Standards in das EMV 3-D Secure-Protokoll. Dies ermöglicht es, frühere Passkey-Authentifizierungen als starkes Signal für reibungslose Genehmigungen zu verwenden, während gleichzeitig die Vorbereitungen für Secure Payment Confirmation (SPC) als moderne, Phishing-resistente Alternative zu traditionellen OTP-Challenges getroffen werden. Es gibt auch laufende Diskussionen darüber, wie Verifiable Credentials in Zukunft in diese Abläufe integriert werden könnten.
• Visa hat den Visa Payment Passkey Service angekündigt, der einen FIDO-Authenticator sicher an Zahlungs-Credentials bindet. Dieser Dienst ist darauf ausgelegt, die Identität zu bestätigen und Zahlungen in einem einzigen, reibungslosen Schritt zu autorisieren, ohne das Checkout-Erlebnis zu unterbrechen.
• Mastercard verfolgt eine parallele Strategie mit seinem Mastercard Payment Passkey Service, der seinen Token Authentication Service (TAS) nutzt, um Passwörter und OTPs durch Passkey-basierte biometrische Authentifizierung zu ersetzen, die eng mit seinen Tokenisierungsdiensten (MDES) integriert ist.

Dies zeigt einen klaren Trend: Die Branche bewegt sich auf eine Zukunft zu, in der eine Wallet einen kryptografisch nachweisbaren Beweis für Identität und Zahlungsautorisierung in einem einzigen, standardisierten Ablauf präsentieren kann.

Ein Großteil dieser Innovation wird durch starken regulatorischen Rückenwind beschleunigt, insbesondere aus der Europäischen Union.

Die eIDAS 2.0-Verordnung der EU geht nicht nur darum, den Bürgern eine digitale ID zur Verfügung zu stellen; sie sieht die EUDI Wallet explizit als eine Methode zur Durchführung von SCA für Online-Zahlungen vor. Das bedeutet, dass Banken und Zahlungsanbieter in der EU in Zukunft verpflichtet sein könnten, die EUDI Wallet als eine Möglichkeit für Nutzer zu akzeptieren, Online-Transaktionen zu bestätigen, was eine standardbasierte Alternative zu proprietären Banking-Apps oder SMS-Codes darstellt.

Ein wegweisender Kartellvergleich in der EU hat Apple bereits gezwungen, seine zuvor geschlossene NFC-Schnittstelle auf iPhones zu öffnen. Seit iOS 17.4 (veröffentlicht am 5. März 2024) hat Apple die notwendigen APIs implementiert und erlaubt es den Nutzern, eine Standard-App für kontaktlose Zahlungen auszuwählen, womit die verbindliche Frist der Europäischen Kommission vom 25. Juli 2024 eingehalten wurde. Dies ist keine Zukunftsaussicht mehr; es ist die aktuelle Realität im Europäischen Wirtschaftsraum (EWR).

Dieser Wandel bedeutet, dass Drittanbieter-Wallet-Apps nun ihre eigenen Tap-to-Pay-Lösungen auf iOS anbieten können, was das langjährige Monopol von Apple Pay beendet. Wichtige Funktionen, die Entwicklern jetzt zur Verfügung stehen, sind:

• Wahl der Standard-Wallet: Nutzer im EWR können eine berechtigte Drittanbieter-App als ihre Standardanwendung für kontaktlose Zahlungen festlegen, die durch einen Doppelklick auf die Seitentaste aufgerufen werden kann.
• Vollständige Integration: Diese Wallets können die nativen Sicherheitsfunktionen des iPhones, einschließlich Face ID und Touch ID, zur Zahlungsautorisierung nutzen.
• Reale Anwendung: Mehrere große Anbieter haben bereits ihre Lösungen eingeführt, darunter Vipps MobilePay in Norwegen und PayPal in Deutschland.

Die Auswirkungen dieser Öffnung sind erheblich und entfalten sich bereits:

• Erhöhter Wettbewerb: Banken und Fintechs können nun direkt mit Apple Pay auf dessen eigener Plattform konkurrieren, was voraussichtlich die Issuer-Gebühren senken und Innovationen fördern wird.
• Breitere Nutzung von Credentials: Dieselben APIs können für mehr als nur Zahlungen verwendet werden, einschließlich Firmenausweisen, ÖPNV-Tickets und Hotelschlüsseln, ohne dass sie in der Apple Wallet sein müssen.
• Ein Weg für standardisierte Credentials: Dies schafft einen entscheidenden Präzedenzfall. Dieselbe regulatorische Logik, die die NFC-Schnittstelle für Zahlungs-Apps geöffnet hat, könnte schließlich verwendet werden, um die Unterstützung für standardisierte, neutrale „Verifiable Payment Credentials“ (wie die, die für die EUDI Wallet pilotiert werden) zu erzwingen, sodass sie neben proprietären Lösungen funktionieren können.
• Globaler Präzedenzfall: Obwohl die Änderung derzeit auf den EWR beschränkt ist, setzt sie einen starken globalen Präzedenzfall. Regulierungsbehörden in anderen Regionen, einschließlich den USA, beobachten dies genau, und dies könnte ähnliche Öffnungen weltweit beschleunigen.

Für Zahlungs-Issuer (Banken, Schemes, Fintechs) erfordert die Navigation des Wandels hin zu digitalen Nachweisen eine pragmatische, phasenweise Strategie. Das Ziel ist es, auf den Assets aufzubauen, die Sie heute kontrollieren, um sich auf das Ökosystem von morgen vorzubereiten. Dieses Playbook skizziert diese Strategie, von sofortigen, risikoarmen Maßnahmen bis hin zu strategischeren, langfristigen Bewertungen.

Die Grundlage jeder zukünftigen Wallet-Strategie ist eine sichere, weit verbreitete native App. Die unmittelbare Priorität ist es, die Reichweite Ihrer App zu maximieren und ihre Authentifizierung sowohl für den Login als auch für Zahlungen zu stärken.

1. Native App-Nutzung vorantreiben: Ihre mobile App ist Ihre zukünftige Wallet. Das Hauptziel ist es, sie zu einem unverzichtbaren Werkzeug für Ihre Kunden zu machen. Diese Verbreitung und Interaktion ist die entscheidende Grundlage für jede zukünftige Ausstellung von Nachweisen oder Wallet-Funktionalität.

2. Passkeys für Zahlungen nach dem PayPal-Modell verwenden: Setzen Sie Passkeys sofort ein, nicht nur für den Login, sondern auch für die Zahlungsautorisierung. Streben Sie ein Erlebnis an, das nahezu gleichwertig mit nativen Plattformlösungen wie Apple Pay ist. Für regulatorische Umgebungen, die eine starke Kundenauthentifizierung (SCA) erfordern, übernehmen Sie den pragmatischen Ansatz von PayPal:

   • Nutzen Sie Passkeys als primären Authentifizierungsfaktor.
   • Kombinieren Sie sie mit vertrauenswürdigen Gerätesignalen (z. B. „gespeicherte Geräte“, die über Ihre App oder sichere Cookies verwaltet werden), um den „Besitz“-Faktor der SCA zu erfüllen.
   • Diese Kombination ermöglicht es Ihnen, ein nahtloses, reibungsarmes Zahlungsbestätigungserlebnis zu bieten, das sowohl hochsicher als auch konform ist, ohne auf universelle VC-Unterstützung warten zu müssen.

Mit einer sicheren, durch Passkeys geschützten App als Grundlage können Sie beginnen, selektiv neue Credential-Technologien zu integrieren, wo sie einen klaren Mehrwert bieten.

3. Den Aufstieg von Verifiable Payment Credentials beobachten: Das Konzept eines VC, das ein Zahlungstoken trägt, ist leistungsstark, aber noch nicht standardisiert. Ihre Rolle hier ist es, ein aktiver Beobachter und Teilnehmer zu sein.

   • Maßnahme: Verfolgen Sie den Fortschritt in Standardisierungsgremien wie EMVCo und dem W3C genau. Seien Sie bereit, standardisierte Verifiable Payment Credentials zu nutzen, wenn sie einen klaren Vorteil gegenüber bestehenden Passkey-basierten Abläufen bieten.

4. Digitale Nachweise für Identitätsanwendungsfälle integrieren: Da digitale Identitäts-Wallets (wie die EUDI Wallet) an Bedeutung gewinnen, integrieren Sie die Digital Credentials API für identitätsbezogene Aufgaben, nicht für Zahlungen.

   • Maßnahme: Verwenden Sie VC-Präsentationen für hochsichere Prozesse, bei denen sie sich auszeichnen:
     • Onboarding & KYC: Optimieren Sie die Einrichtung neuer Konten.
     • Step-Up-Authentifizierung: Überprüfen Sie die Identität bei risikoreichen Aktionen.
     • Kontowiederherstellung: Bieten Sie einen sicheren Weg für Nutzer, die ihre Geräte verloren haben.

Die ultimative Hürde für die Akzeptanz jeder neuen Zahlungstechnologie ist die Reibung für den Nutzer. Bevor ein einfacher Passkey-Ablauf ersetzt wird, muss eine VC-basierte Alternative beweisen, dass sie nicht nur sicherer, sondern auch ebenso nahtlos ist.

5. Sich unermüdlich am Ein-Klick-Erlebnis messen: Der Standard für ein modernes Zahlungserlebnis wird von führenden Anbietern wie Apple Pay und seinem engen Verfolger im Web, PayPal, gesetzt. Jeder neue Ablauf, den Sie einführen, muss mit deren nahezu sofortiger Ein-Klick-Bestätigung konkurrieren. Alle aktuellen Signale deuten darauf hin, dass für die große Mehrheit der Transaktionen die Phishing-Resistenz von Passkeys ein ausreichendes Schutzniveau und ein überlegenes Nutzererlebnis bietet. Fügen Sie keinen VC-Präsentationsschritt zu einem Zahlungsablauf hinzu, wenn er eine spürbare Reibung verursacht.

6. Auf In-Band-Gerätesignale innerhalb von WebAuthn achten: Die Entwicklung von Passkeys ist nicht statisch. Während frühe Versuche, gerätespezifische Signale bereitzustellen, eingestellt wurden, arbeiten Standardisierungsgremien aktiv daran, stärkere gerätebindende Vertrauenssignale direkt in das WebAuthn-Protokoll zu integrieren. Dies würde es einer RP ermöglichen, ein vertrauenswürdiges Gerät während einer Passkey-Authentifizierung zu identifizieren, was das Signal für Risiko-Engines weiter stärkt, ohne eine separate, Out-of-Band-VC-Präsentation zu erfordern. Beobachten Sie diesen Bereich genau, da dies der wahrscheinlichste Weg zu erhöhter Sicherheit ist, ohne das reibungslose Erlebnis des Passkeys zu opfern.

Indem ein Issuer diesem phasenweisen Playbook folgt, kann er eine robuste, praktische Strategie aufbauen, die heute die Sicherheit maximiert und das Nutzererlebnis verbessert, während er sich darauf vorbereitet, die nachweisbaren Zahlungstechnologien von morgen durchdacht zu übernehmen.

Damit digitale Nachweise über die reine Unterstützung von KYC oder die Authentifizierung von Nutzern für Zahlungskonten hinaus zu einem integralen Bestandteil von Zahlungsprozessen werden, müssen mehrere bedeutende Herausforderungen bewältigt werden:

1. Standardisierung von zahlungsspezifischen VCs: Ein dediziertes, sicheres und weithin akzeptiertes Verifiable Credential-Format für Zahlungen muss entwickelt werden. Dieses müsste Zahlungstoken, transaktionsspezifische Daten und potenziell dynamische Sicherheitselemente umfassen, was weit über den Umfang aktueller identitätsfokussierter mdocs oder generischer VCs hinausgeht.
2. Integration mit Zahlungsnetzwerken: Jede VC-basierte Zahlungslösung muss sich nahtlos in bestehende globale Zahlungsnetzwerke (Visa, Mastercard usw.) integrieren oder tragfähige neue Schienen vorschlagen. Dies beinhaltet komplexe technische, sicherheitstechnische und geschäftsmodellbezogene Abstimmungen.
3. Regulatorische Konformität: Zahlungen sind stark reguliert (z. B. PSD2/SCA in Europa, PCI DSS weltweit). Ein VC-basiertes Zahlungssystem müsste alle relevanten Finanzvorschriften erfüllen, einschließlich derer für Sicherheit, Verbraucherschutz und Betrugsbekämpfung.
4. Akzeptanz bei Issuern und Acquirern: Banken, Finanzinstitute (als Issuer von Zahlungs-VCs) und Händler-Acquirer müssten in die Infrastruktur investieren, um ein solches System zu unterstützen.
5. Sicherheitsmodell: Ein robustes Sicherheitsmodell speziell für Zahlungs-VCs wäre unerlässlich und müsste die Ausstellung, Speicherung (idealerweise in hardwaregestützten Secure Elements), Präsentation und den Widerruf in einem finanziellen Kontext abdecken.
6. Nutzererlebnis: Obwohl VCs die Kontrolle durch den Nutzer bieten können, muss das Zahlungserlebnis schnell, intuitiv und zuverlässig bleiben, um eine breite Akzeptanz zu finden.

Zukünftige Möglichkeiten:

• VCs für Zahlungsautorisierungsbelege: VCs könnten eine kryptografisch signierte „Autorisierung“ zur Zahlung von einem verknüpften Konto darstellen, die über OpenID4VP präsentiert wird, wobei der eigentliche Geldtransfer weiterhin über traditionelle Schienen erfolgt.
• VCs, die Zahlungstoken enthalten: Ein standardisierter VC könnte definiert werden, um ein Zahlungstoken (ähnlich einem EMV DPAN) sicher zu halten, das dann von bestehenden Zahlungsinfrastrukturen verarbeitet wird.
• Geschlossene Zahlungs-VCs: Spezifische Issuer oder Gemeinschaften könnten VCs für Zahlungen innerhalb ihrer eigenen geschlossenen Systeme erstellen.

Dies sind jedoch derzeit weitgehend konzeptionelle Überlegungen. Der Hauptantrieb hinter der aktuellen Entwicklung von VCs und mdocs, der nun durch die konkreten Implementierungen von Browser-APIs gefestigt wurde, bleibt auf die Identitätsprüfung und die Attestierung von Attributen konzentriert, nicht auf die Durchführung von Zahlungen.

Die Konvergenz von digitaler Identität und Zahlungen stellt eine komplexe, aber navigierbare Landschaft dar. Während das Versprechen eines einzigen, universellen „nachweisbaren Zahlungs-Credentials“ überzeugend ist, kommt dieser Artikel zu dem Schluss, dass die effektivste und praktischste Strategie für Zahlungs-Issuer heute auf einer anderen Realität beruht: Der Kampf um das beste Nutzererlebnis ist von größter Bedeutung, und Passkeys sind die mächtigste Waffe.

Das strategische Playbook ist klar. Der sofortige, risikoarme Schritt besteht darin, sich auf die Etablierung einer unschlagbaren nativen App zu konzentrieren und sie als Vehikel zu nutzen, um Passkey-basierte Zahlungen bereitzustellen, die mit dem reibungslosen „Ein-Klick“-Standard von Apple Pay und PayPal mithalten können. Dieser Ansatz erfüllt die Kernbedürfnisse von Sicherheit (durch Phishing-Resistenz) und Nutzererlebnis heute, unter Verwendung ausgereifter, weit verbreiteter Technologie.

In diesem Modell finden Verifiable Credentials ihre entscheidende, aber separate Rolle. Sie sind noch nicht das Werkzeug für den Zahlungsvorgang selbst, aber unverzichtbar für die hochsicheren Identitätsaufgaben, die ihn umgeben: sicheres Onboarding, robuste Kontowiederherstellung und regulatorisches KYC.

Die Zukunft des Zahlungsverkehrs wird nicht von einer einzigen Technologie bestimmt, sondern von einem unermüdlichen Fokus auf den Nutzer. Erfolg werden die Issuer haben, die zuerst das Passkey-gesteuerte Erlebnis in ihren eigenen Apps meistern, während sie die Entwicklung von Verifiable Credentials und In-Band-Passkey-Vertrauenssignalen aufmerksam beobachten. Sie müssen bereit sein, diese neuen Technologien nicht dann zu integrieren, wenn sie nur verfügbar sind, sondern erst dann, wenn sie den gewaltigen Maßstab eines wirklich nahtlosen, sicheren und überlegenen Zahlungserlebnisses erfüllen können.