Passkeys für Zahlungsanbieter: So entwickelt man ein Drittanbieter-SDK

1. Einleitung: Warum brauchen Zahlungsanbieter Passkeys?#

Passkeys entwickeln sich zur effektivsten Methode für die Sicherung und Autorisierung von Online-Transaktionen. Sie verbessern Sicherheit und Komfort im Vergleich zur traditionellen Multi-Faktor-Authentifizierung (MFA) erheblich. Kürzlich hat PayPal Passkeys als primäre MFA-Lösung eingeführt und damit einen klaren Trend für Payment-Anbieter weltweit gesetzt.

Passkeys wurden jedoch ursprünglich für First-Party-Kontexte entwickelt. Das bedeutet, sie funktionieren optimal, wenn sich User direkt auf der Website oder in der App authentifizieren, der die Zugangsdaten gehören. Zahlungsanbieter agieren hingegen meist in Third-Party-Kontexten, wo ihre Dienste (wie Zahlungsformulare oder SDKs) in die Websites und Apps von Händlern eingebettet sind. Diese grundlegende Diskrepanz zwischen dem Design von Passkeys und dem Geschäftsmodell von Zahlungsanbietern führt zu kritischen Einschränkungen bei der nahtlosen Integration. Um diese Herausforderungen zu meistern, müssen wir zwei wichtige Fragen klären:

1. Was sind die aktuellen Einschränkungen bei der Nutzung von Passkeys in Third-Party-Kontexten für Zahlungsanbieter?
2. Wie können Zahlungsanbieter diese Hürden überwinden, um Passkey-Integrationen erfolgreich umzusetzen?

Wenn wir diese Fragen untersuchen, wird deutlich, dass die Bemühungen der Industrie, Passkeys an Third-Party-Kontexte anzupassen – insbesondere durch Webstandards wie Secure Payment Confirmation (SPC) – durch strategische Barrieren blockiert werden, die implizit von Apple ausgehen. Insbesondere Apples eingeschränkte Unterstützung für Cross-Origin Passkey-Erstellung in Safari und die fehlende Unterstützung des Secure Payment Confirmation Standards stellen ein erhebliches Hindernis dar. Dies erschwert die nahtlose Einführung der Passkey-Authentifizierung durch Drittanbieter im Zahlungsverkehr massiv. Diese Hürden zu verstehen und zu überwinden, ist für jeden Anbieter essenziell, der reibungslose und sichere Zahlungserlebnisse bieten möchte.

2. Vorteile von Passkeys im gesamten Zahlungsökosystem#

Passkeys bringen phishing-resistente, biometrische Logins in jede Ebene des Payment-Stacks. Die folgende Grafik veranschaulicht, wie jeder Akteur in der Wertschöpfungskette von der Passkey-Authentifizierung profitiert.

2.1 Passkeys für Händler (Merchants)#

Einfluss: Schnellerer Checkout, höhere Conversion, weniger Warenkorbabbrüche. Chance: Händler, die Passkeys über SDKs oder Redirect-Flows anbieten, können eine UX auf Apple Pay-Niveau erreichen und die Abhängigkeit von Passwörtern oder OTPs reduzieren – was zu mehr Vertrauen und Umsatz führt.

2.2 Passkeys für Karteninhaber / Kunden#

Einfluss: Nahtlose, passwortlose Authentifizierung über Geräte hinweg. Chance: Passkeys bieten eine bessere UX als OTPs oder SMS-Codes und eliminieren das Phishing-Risiko. Eine breite Akzeptanz könnte Passkeys zum neuen Standard für die Karteninhaber-Verifizierung machen.

2.3 Passkeys für Issuer (Kartenherausgebende Banken)#

Einfluss: Stärkere Betrugsprävention. Chance: Issuer können Passkey-basierte Step-Up-Authentifizierung in 3DS-Flows anbieten, was die Kosten für OTPs senkt und die Kundenzufriedenheit steigert.

2.4 Passkeys für Acquirer (Händlerbanken)#

Einfluss: Höhere Transaktionsakzeptanz und weniger fehlgeschlagene Authentifizierungen. Chance: Die Unterstützung von Passkeys durch PSPs kann die Ergebnisse für Händler verbessern und Reibungspunkte beim Checkout oder bei wiederkehrenden Zahlungen reduzieren.

2.5 Passkeys für Payment Service Provider (PSP) / Payment Gateways#

Einfluss: Reduzierter Betrug, bessere Händler-UX und verbesserte Compliance. Chance: Durch das Einbetten oder Weiterleiten von Passkey-Flows können PSPs eine Authentifizierung der nächsten Generation anbieten und gleichzeitig die Kompatibilität über Browser und native Apps hinweg wahren.

2.6 Passkeys für Payment Processors#

Einfluss: Optimierte Transaktionsfreigaben mit weniger abgelehnten Zahlungen. Chance: Unternehmen für Zahlungsabwicklung können die Passkey-Verifizierung in ihre APIs integrieren, um Risiken zu minimieren und biometrische SCA-Alternativen für konforme Abläufe zu unterstützen.

2.7 Passkeys für Tokenisierungs- & Wallet-Anbieter#

Einfluss: Sichere Speicherung von Anmeldeinformationen und reibungslose Re-Authentifizierung. Chance: Wallet-Anbieter wie Apple Pay und Google Pay nutzen bereits Passkey-ähnliche Flows.

3. Welche Zahlungsanbieter haben Passkeys bereits eingeführt?#

Bitte werfen Sie einen Blick auf unsere dedizierte Übersicht von Zahlungsanbietern, die Passkeys bereits nutzen.

4. Warum werden Industriestandards für Passkeys von Apple blockiert?#

Die Einführung von Passkeys durch Drittanbieter im Zahlungsverkehr stößt auf strategische Hindernisse, die primär durch Apples restriktive Richtlinien in Safari getrieben werden. Zwei wichtige Standardisierungsversuche wurden konsequent behindert:

• Secure Payment Confirmation (SPC)

• Passkey-Erstellung durch Drittanbieter in iFrames

4.1 Wo blockiert Apple die Secure Payment Confirmation (SPC)?#

Secure Payment Confirmation (SPC) stellt den bedeutendsten Vorstoß der Industrie dar – vorangetrieben vor allem von Google –, um die nahtlose, Cross-Origin-Nutzung von Passkeys speziell für sichere Zahlungsautorisierungen zu ermöglichen. SPC standardisiert, wie Zahlungsanbieter User über verschiedene Händler-Websites hinweg authentifizieren, ohne Sicherheit oder Benutzererfahrung zu beeinträchtigen. Apple hat jedoch die Unterstützung für SPC in Safari konsequent verweigert. Dies ist wahrscheinlich ein strategischer Schachzug, um sicherzustellen, dass Apple Pay die bevorzugte und reibungsloseste Zahlungslösung im eigenen Ökosystem bleibt. Apples Weigerung, SPC zu adaptieren, schränkt nicht nur den breiten Einsatz von Passkeys in Third-Party-Kontexten ein, sondern verzögert auch effektiv die breitere industrielle Akzeptanz standardisierter Zahlungsauthentifizierungen.

Lesen Sie diesen Blogbeitrag über SPC, wenn Sie mehr über die Details erfahren möchten.

4.2 Wie Safaris iFrame-Restriktionen die Passkey-Erstellung beeinträchtigen#

Eine weitere kritische Barriere ist Apples bewusste Einschränkung der Passkey-Erstellung innerhalb von Cross-Origin iFrames. Während Safari die Nutzung bestehender Passkeys zur Authentifizierung (navigator.credentials.get()) in einem Third-Party-iFrame erlaubt, wird die Registrierung neuer Passkeys (navigator.credentials.create()) in solchen Kontexten explizit blockiert.

Diese Einschränkung trifft Zahlungsanbieter hart, die darauf angewiesen sind, neue Passkeys nahtlos während des Checkout-Prozesses beim Händler zu erstellen. Folglich sind Anbieter gezwungen, entweder auf Redirect-basierte Ansätze auszuweichen oder sich auf bestehende Passkeys zu verlassen, die zuvor direkt auf ihren eigenen Domains erstellt wurden. Diese Entscheidung von Apple beeinträchtigt direkt die Praktikabilität und Flüssigkeit von Händlerintegrationen und schafft einen signifikanten Reibungspunkt für Verbraucher und Anbieter gleichermaßen.

5. Aufbau eines Third-Party Passkey Payment SDKs für das Web#

5.1 Strategie A: Einbetten eines Cross-Origin iFrame (Vor- & Nachteile)#

Bei diesem Ansatz bindet der Händler Ihr Zahlungsformular in einem <iframe> ein, das von Ihrer Domain als Zahlungsanbieter bereitgestellt wird – zum Beispiel https://pay.provider.com. Der User bleibt auf der Domain des Händlers (z. B. https://www.mystore.com), sieht Ihre Zahlungs-UI im eingebetteten iFrame und authentifiziert sich mit einem Passkey, der an die Relying Party ID pay.provider.com gebunden ist.

Wichtige Punkte:

• Cross-Origin: Da der iFrame auf einer anderen Domain liegt, müssen Sie Berechtigungsrichtlinien (Permission Policies) für publickey-credentials-get und publickey-credentials-create konfigurieren, um Passkey-Operationen innerhalb des iFrames zu erlauben.

• Einschränkung bei der Erstellung: Einige Browser (insbesondere ältere Versionen und Safari) erlauben nach wie vor keine Passkey-Erstellung in Cross-Origin-iFrames. Die Authentifizierung (navigator.credentials.get()) wird breiter unterstützt, aber die Registrierung (navigator.credentials.create()) kann in bestimmten Umgebungen, vor allem in Safari, fehlschlagen.

• User Activation: Passkey-Flows erfordern typischerweise eine „transient activation“ (z. B. einen direkten Klick auf einen Button durch den User). Stellen Sie sicher, dass Ihre iFrame-Schnittstelle die Passkey-Zeremonie durch ein vom Benutzer initiiertes Ereignis auslöst.

• Sicherheit & UX: Der iFrame-Ansatz bietet ein flüssiges, eingebettetes Checkout-Erlebnis. Wenn jedoch der Browser eines Users Third-Party-Cookies oder lokalen Speicher blockiert, kann dies den Passkey-Flow stören.

5.2 Strategie B: Redirect-basierter Ansatz für breitere Kompatibilität#

Bei einem Redirect-Flow senden Sie den User von der Händler-Domain zu Ihrer Zahlungs-Domain oder öffnen einen neuen Tab/ein neues Fenster, das auf eine URL wie https://pay.provider.com/checkout zeigt. Passkeys werden dann direkt auf Ihrer Domain in einem First-Party-Kontext erstellt oder verwendet.

Wichtige Punkte:

• First-Party Einfachheit: Der gesamte Passkey-Workflow (Erstellung, Authentifizierung) findet auf der Domain des Zahlungsanbieters statt, sodass keine Cross-Origin-Einschränkungen greifen. Alle gängigen Browser unterstützen Passkey-Erstellung und Login in First-Party-Kontexten.

• Redirect UX: Der User verlässt die Händlerseite (oder sieht ein Pop-up), um die Authentifizierung abzuschließen. Das kann weniger nahtlos wirken, vereinfacht aber die Passkey-Architektur und reduziert die Komplexität von Cross-Origin-Problemen.

• Fallback für inkompatible Browser: Sie können ein sauberes „Graceful Degradation“ anbieten, wenn Passkeys nicht verfügbar sind (z. B. in älteren Browsern), indem Sie alternative Login-Methoden auf Ihrer Zahlungs-Domain bereitstellen, ohne zusätzliche Cross-Origin-Berechtigungen verwalten zu müssen.

6. Third-Party Passkey Payment SDK für native Apps#

Die Integration von Passkeys in native mobile Apps stellt im Vergleich zu Web-Szenarien einzigartige Herausforderungen dar. Native Apps für Händler (sowohl auf iOS als auch auf Android) betten Zahlungsabläufe oft mittels WebViews ein, um eine nahtlose User Experience zu gewährleisten. Die Implementierung von Third-Party-Passkey-Authentifizierung in diesen eingebetteten Kontexten ist jedoch aufgrund strenger Browser-Origin-Richtlinien und plattformspezifischer Einschränkungen problematisch.

6.1 Warum Passkeys von Anbietern nicht direkt in nativen Händler-Apps genutzt werden können#

Passkeys sind inhärent an eine spezifische Domain (die „Relying Party ID“) gebunden. Dies ist ein zentrales Sicherheitsprinzip, das sicherstellt, dass Zugangsdaten nicht auf fremden Websites oder Apps missbraucht werden können. Wenn ein Zahlungsanbieter Passkeys unter seiner eigenen Domain erstellt – z. B. pay.provider.com – sind diese Passkeys strikt an diese Domain gebunden, sowohl unter iOS als auch unter Android. Folglich kann die native App eines Händlers (die natürlich unter der eigenen App-ID und Domain des Händlers läuft) die Passkeys des Anbieters nicht direkt als „First-Party“-Credential abrufen. Dies würde das Cross-Origin-Sharing privater Schlüssel erfordern, was die Betriebssysteme und WebAuthn-Spezifikationen explizit untersagen, um Phishing und Diebstahl von Zugangsdaten zu verhindern.

Aus Sicht des Geräts ist die native App des Händlers ein anderer „Origin“ als die Domain des Zahlungsanbieters. Der Versuch, sich nativ gegen Credentials zu authentifizieren, die für einen separaten Origin registriert sind, würde das grundlegende Origin-gebundene Sicherheitsmodell von Passkeys brechen. Genau aus diesem Grund hängt die Nutzung von Third-Party-Passkeys im Händlerkontext von einem Systembrowser oder einer systembasierten WebView ab (wie ASWebAuthenticationSession auf iOS oder Chrome Custom Tabs auf Android). Diese speziellen Flows bewahren den ursprünglichen Domain-Kontext des Anbieters – und stellen sicher, dass Passkeys sicher an den Origin gebunden bleiben – während User sich dennoch innerhalb der App des Händlers beim Zahlungsanbieter authentifizieren können. In den folgenden Abschnitten untersuchen wir, wie das funktioniert.

6.2 Herausforderungen mit eingebetteten WebViews: Warum sie Passkeys „kaputt machen“#

Eingebettete WebViews (z. B. WKWebView auf iOS oder Androids WebView) sind sehr beliebt, weil sie es Apps ermöglichen, Webinhalte direkt in ihre nativen Schnittstellen zu integrieren, was eine enge Integration und konsistente UX bietet. Diese eingebetteten Umgebungen sind jedoch beim Umgang mit Third-Party-Passkeys aufgrund von Origin- und Sicherheitsrichtlinien stark eingeschränkt:

• Origin Mismatch: Passkeys verlassen sich strikt auf Domain-Origins für die sichere Handhabung von Zugangsdaten. Eine eingebettete WebView operiert unter der Domain des Inhalts, den sie anzeigt (oft die des Händlers), was es schwierig oder unmöglich macht, Passkeys zu erstellen oder zu authentifizieren, die explizit an die Domain eines externen Zahlungsanbieters gebunden sind.

• Plattform-Sicherheitsbeschränkungen: Sowohl Apple (iOS) als auch Google (Android) haben die Fähigkeiten eingebetteter WebViews für die Authentifizierung zunehmend eingeschränkt, insbesondere beim Umgang mit sicheren Credentials. Diese Einschränkungen dienen dem Schutz der Privatsphäre und Sicherheit, machen die Implementierung von Third-Party-Passkeys jedoch deutlich komplizierter.

Insgesamt sind eingebettete WebViews zwar aus UX-Perspektive für Händler attraktiv, führen aber zu erheblichen praktischen Einschränkungen bei der Implementierung robuster Third-Party-Passkey-Flows.

6.3 Nutzung von System WebViews oder Redirects für Third-Party Passkeys#

Angesichts der Einschränkungen eingebetteter WebViews nutzen Zahlungsanbieter typischerweise eine von zwei alternativen Strategien, um Third-Party-Passkeys zuverlässig in nativen mobilen Apps zu implementieren:

6.3.1 Nutzung der System WebView#

iOS (ASWebAuthenticationSession):

Apple stellt ASWebAuthenticationSession als sichere, browserähnliche Umgebung außerhalb des Kontexts der Host-Anwendung bereit. Sie teilt den Cookie-Speicher mit dem Standard-Safari-Browser und unterstützt Third-Party-Passkeys zuverlässig, da die Credentials mit der Origin-Domain des Zahlungsanbieters übereinstimmen.

Das folgende Beispiel zeigt die Funktionalität „Mit PayPal bezahlen“ innerhalb der BOSS Native App. Es zeigt, wie eine ASWebAuthenticationSession System-WebView geöffnet wird, die ihren Status mit Safari-Cookies teilt, sodass der Passkey-Dialog sofort starten kann.

Android (Chrome Custom Tabs):

Ähnlich bieten Chrome Custom Tabs auf Android eine fast browsergleiche Umgebung, die konsistente Passkey-Erstellung und -Authentifizierung ermöglicht. Wie ASWebAuthenticationSession laufen Custom Tabs separat vom App-Kontext des Händlers und gewährleisten so die Integrität von Domain und Credentials.

Sehen Sie hier das gleiche Beispiel aus der BOSS Native App auf Android:

6.3.2 Redirect zum Standard-Browser#

Ein weiterer Ansatz besteht darin, User aus der nativen App heraus in den Standard-Webbrowser des Mobilgeräts (Safari auf iOS, Chrome auf Android) umzuleiten. Dies stellt sicher, dass der Zahlungsfluss – und damit das Passkey-Management – vollständig in einem vertrauenswürdigen First-Party-Kontext stattfindet, der mit der Domain des Zahlungsanbieters verknüpft ist. User kehren nach erfolgreicher Authentifizierung oder Zahlungsabschluss zur Händler-App zurück. Diese Option ist für Kunden sehr unbequem, da sie die App verlassen müssen.

Beide Lösungen erfordern, dass User vorübergehend die native App-Umgebung des Händlers verlassen. Obwohl dies etwas weniger nahtlos ist als eingebettete Lösungen, verbessern diese Ansätze die Kompatibilität, Sicherheit und Zuverlässigkeit von Third-Party-Passkey-Operationen erheblich.

Letztendlich müssen Zahlungsanbieter, die native SDKs entwickeln, sorgfältig zwischen User Experience und praktischen technischen Einschränkungen abwägen. Trotz der Präferenz der Händler für vollständig eingebettete Erlebnisse bleibt die Nutzung von System WebViews oder die Weiterleitung an externe Browser die Best Practice für eine sichere, verlässliche Third-Party-Passkey-Authentifizierung in nativen Apps.

7. iFrame vs. Redirect: Welcher Ansatz für den Passkey-Checkout?#

Die Wahl zwischen einem eingebetteten (iFrame) Ansatz und einem Redirect-basierten Ansatz für die Integration von Third-Party-Passkeys in Zahlungs-SDKs erfordert eine Abwägung der Vor- und Nachteile in Bezug auf User Experience, Browser-Kompatibilität, technische Komplexität und Händlerpräferenzen.

7.1 Detaillierte Vergleichstabelle: Embedded vs. Redirect#

Beide Lösungen haben deutliche Vor- und Nachteile, die Zahlungsanbieter basierend auf ihrem Zielmarkt, der gewünschten UX und der technischen Infrastruktur sorgfältig prüfen sollten.

7.2 Zusammenfassung: Den besten Flow für Ihr Zahlungs-SDK wählen#

Der eingebettete (iFrame) Ansatz bietet eine nahtlose, händlergebrandete User Experience, die für Händler sehr attraktiv ist, aber durch eingeschränkte Browser-Kompatibilität behindert wird – insbesondere durch Safaris Weigerung, Cross-Origin Passkey-Erstellung zu erlauben. Diese Einschränkung zwingt Händler und Anbieter zu komplexen Workarounds, die oft die Funktionalität beeinträchtigen oder zu unvollständigem Support für die Passkey-Registrierung führen.

Im Gegensatz dazu bietet der Redirect-Ansatz umfassende Kompatibilität über Browser und native mobile Plattformen hinweg, indem er in einem First-Party-Domain-Kontext operiert. Er vereinfacht die Integration erheblich, verbessert die Zuverlässigkeit und gewährleistet volle Unterstützung für Passkey-Erstellung und -Authentifizierung. Der Hauptnachteil ist die potenzielle Reibung durch das Wegleiten der User von der Website oder App des Händlers, obwohl dies durch sorgfältiges UX-Design, klare Kommunikation oder Integrationen mit vertrauenswürdigen Plattformen wie Corbado abgemildert werden kann.

Angesichts dieser Überlegungen ist oft ein hybrider Ansatz ideal, der es Zahlungsanbietern ermöglicht, das eingebettete iFrame-Modell zu nutzen, wenn der Browser des Users dies unterstützt, und ansonsten elegant auf einen Redirect-Ansatz zurückzufallen (Fallback). Diese kombinierte Strategie maximiert Kompatibilität, Händlerattraktivität und Kundenzufriedenheit über diverse Umgebungen hinweg.

8. Best Practices & Empfehlungen für Cross-Origin Passkey SDKs#

Die Implementierung eines Third-Party Passkey Payment SDKs erfordert ein Gleichgewicht zwischen User Experience, Browser-Kompatibilität, Einschränkungen nativer Apps, Analytics und Sicherheit – besonders angesichts der Apple-spezifischen Hürden (z. B. Blockieren von Cross-Origin Passkey-Erstellung, fehlender SPC-Support). Im Folgenden finden Sie wichtige Empfehlungen, um das bestmögliche Ergebnis bei der Integration von Passkeys in Web- oder native Zahlungsflüsse zu erzielen.

8.1 Wie man einen SDK-Ansatz für Passkey-Flows aufsetzt#

Aufgrund des variierenden Browser-Supports und inkonsistenten Verhaltens von Apple ist die Unterstützung sowohl eines eingebetteten (iFrame-basierten) als auch eines Redirect-Ansatzes entscheidend:

• iFrame Checkout (Embedded)

  • Bietet ein nahtloses On-Page-Erlebnis für moderne Browser, die Cross-Origin Passkey-Operationen erlauben (primär für Authentifizierung).

  • Es muss die korrekte Permissions-Policy für publickey-credentials-get/publickey-credentials-create gesetzt werden.

  • Beachten Sie, dass Safari und einige ältere Browser die Cross-Origin Passkey-Erstellung in iFrames blockieren.

• Redirect Flow

  • Unterstützt zuverlässig sowohl Passkey-Registrierung als auch Login in einem First-Party-Kontext.

  • Etwas mehr Reibung durch den zusätzlichen Redirect oder das Pop-up, aber universell sicherer für Cross-Browser-Kompatibilität.

  • Idealer Fallback für Safari, das derzeit keine Third-Party Passkey-Erstellung in iFrames erlaubt.

Indem Sie beide Ansätze anbieten, können Sie dynamisch entscheiden – oder Händler entscheiden lassen –, welcher genutzt werden soll, um die Kompatibilität für alle Nutzerumgebungen zu maximieren.

8.2 Erkennung von Browser-Fähigkeiten (Safari vs. Chrome vs. Edge vs. Firefox)#

Die genaue Erkennung von Browser-Fähigkeiten bleibt eine Herausforderung aufgrund der reduzierten Granularität des User-Agents und des inkonsistenten Supports für Client Hints auf den Plattformen.

8.2.1 Komplexität beim Parsen des User-Agents#

Traditionelles Parsen wird zunehmend unzuverlässig, da Browser die Details in User-Agent-Strings reduzieren, um die Privatsphäre der Nutzer zu schützen. Die Unterscheidung wesentlicher Details – wie Windows 10 vs. Windows 11, genaue macOS-Versionen oder CPU-Architekturen – ist allein über den User-Agent oft schwierig oder unmöglich.

8.2.2 Inkonsistenter Support für Client Hints#

Während Client Hints Daten mit hoher Entropie auf eine datenschutzkonforme Weise bereitstellen, werden sie nur von Chromium-basierten Browsern vollständig unterstützt. Safari und Firefox bieten keinen Client Hint Support, was die präzise Feature-Erkennung auf Apple-Geräten stark einschränkt.

8.2.3 Einschränkungen bei Embedded und Native Apps:#

Eingebettete WebViews beschränken typischerweise den Zugriff auf detaillierte Geräteinformationen und unterstützen selten Client Hints. Diese Einschränkung macht die Erkennung von Passkey-Fähigkeiten besonders in nativen App-Kontexten herausfordernd.

Angesichts dieser Einschränkungen erfordert die zuverlässige Erkennung von Cross-Origin Passkey-Support – insbesondere in Third-Party Payment SDKs – eine sorgfältige Kombination aus dynamischen Client Hint Abfragen (wo verfügbar), Fallback-Heuristiken für User-Agents und konservativem Standardverhalten für Browser wie Safari und Firefox.

8.3 Vorsichtiger Umgang mit nativen Apps: Embedded WebView vs. System WebView#

Native Händler-Apps betten Webinhalte oft in WKWebView (iOS) oder Android WebView ein, die für Passkeys sehr restriktiv sind. Gängige Strategien umfassen:

• System-Browser-Sitzungen: Nutzen Sie ASWebAuthenticationSession (iOS) oder Custom Tabs (Android), um die Passkey-Erstellung/-Anmeldung in einen sicheren „First-Party“-Browserkontext zu verlagern.

• Redirect zum Standard-Browser: Ein weniger nahtloser, aber hochgradig zuverlässiger Ansatz, um die Domain-Integrität für Passkey-Operationen sicherzustellen.

8.4 Sicherstellung von Sicherheit & Compliance (PCI)#

Als Zahlungsanbieter sind starke Sicherheit und regulatorische Compliance (PCI, PSD2 SCA, etc.) entscheidend:

• Header & Content Security: Implementieren Sie strikte Permissions-Policy Header und robuste CSP-Regeln für Cross-Origin Flows.

• Logging & Monitoring: Protokollieren Sie Passkey-Erstellungs- und Nutzungsereignisse gründlich zur Betrugsprävention und für Compliance-Audits.

• Minimale PII-Speicherung: Mappen Sie User auf Passkeys mittels gehashter Identifikatoren, um die Exposition unter DSGVO oder ähnlichen Datenschutzgesetzen zu reduzieren.

• Audit Trails: Protokollieren Sie jedes Passkey-Erstellungs- und Authentifizierungsereignis, um Anomalien zu erkennen und Audits zu bestehen.

8.5 Kontinuierliches Testen & Monitoring von Passkeys#

Passkeys entwickeln sich ständig weiter, daher benötigen Sie fortlaufende Überprüfungen:

• Cross-Browser & Cross-OS Testing: Automatisieren Sie Tests in Safari, Chrome, Edge, Firefox und wichtigen mobilen OS-Versionen.

• Häufige Updates: Verfolgen Sie Änderungen in W3C WebAuthn-Spezifikationen, Richtlinien der FIDO Alliance oder SPC-Vorschlägen.

• User Feedback & Fehlerraten: Protokollieren Sie Passkey-Fehler (Erstellung oder Login), um Probleme schnell zu beheben, insbesondere für Apple-basierte User.

8.6 Essenzielle Passkey-KPIs: Tracking von Erstellung & Login#

Ein robustes KPI-Framework hilft Ihnen nachzuvollziehen, ob Ihre Third-Party Passkey-Integration die Sicherheit und User Experience wirklich verbessert. Das Dashboard unten fasst die sechs wichtigsten Metriken zusammen, die jeder Zahlungsanbieter überwachen sollte, zusammen mit Zielbereichen für eine gesunde Adoption.

Auch wenn es in diesem Artikel um die Implementierung von SDKs geht, ist es wichtig zu bedenken, dass die Passkey Adoption auch in diesem Anwendungsfall der Schlüssel ist. Erstellungs- und Nutzungsraten von Passkeys erfordern sorgfältige Analyse und Optimierung.

8.6.1 Passkey Akzeptanzrate (Acceptance Rate)#

• Definition: Prozentsatz der User, die erfolgreich einen Passkey erstellen, wenn sie dazu aufgefordert werden (z. B. beim Checkout oder Account-Setup).

• Warum es wichtig ist: Eine hohe Akzeptanzrate bedeutet, dass Ihr Onboarding/Nudge-Flow für Passkeys überzeugend und reibungsfrei ist.

• Ziel: Sie sollten eine Rate von 50–80 % anstreben.

8.6.2 Erfolgsrate der Passkey-Erstellung (Creation Success Rate)#

• Definition: Wie viele User, die den Erstellungsprozess beginnen („Passkey erstellen“ klicken), schließen diesen ohne Abbruch oder Fehler ab?

• Warum es wichtig ist: Zeigt an, wie gut Ihr Cross-Origin- oder Redirect-Flow technisch funktioniert.

• Ziel: Idealerweise erreichen Sie hier Werte von ~95–100 %, sobald sich ein User dafür entscheidet.

8.6.3 Passkey Nutzungsrate (Usage Rate)#

• Definition: Der Prozentsatz der gesamten Zahlungsautorisierungen (oder Logins), die via Passkeys erfolgen, im Gegensatz zu Fallback-Methoden.

• Warum es wichtig ist: Die Erstellung ist bedeutungslos, wenn User auf alte Methoden zurückfallen.

• Ziel: Eine Rate von 50–80 % signalisiert eine starke Passkey Adoption.

8.6.4 Erfolgsrate beim Passkey-Login (Login Success Rate)#

• Definition: Prozentsatz der Passkey-Login-Versuche, die ohne Fehler oder Fallback erfolgreich sind.

• Warum es wichtig ist: Ein Spiegelbild Ihrer Usability in der Praxis.

• Ziel: Typischerweise sollten Sie 90–95 % überschreiten, um Passkeys als „reibungsfrei“ bezeichnen zu können.

8.6.5 Fallback-Nutzung (Fallback Usage)#

• Definition: Wie oft scheitern User mitten in der Passkey-Zeremonie und wechseln zu Passwort oder OTP?

• Warum es wichtig ist: Hohe Fallback-Nutzung deutet auf technische oder UX-Hürden hin, die verhindern, dass Passkeys Legacy-Methoden ersetzen.

• Ziel: Idealerweise liegt die Fallback-Nutzung unter 1–5 %.

8.6.6 Conversion & Betrugs-Metriken#

Für Zahlungsanbieter ist messbar, ob Passkeys Betrug reduzieren, den Checkout beschleunigen oder Warenkorbabbrüche senken. Kombinieren Sie Passkey-Nutzungsdaten mit Zahlungs-Conversions oder 3-D Secure Erfolgsmetriken für einen ganzheitlichen Blick.

Das Monitoring dieser KPIs hilft Ihnen, Umgebungen oder User Journeys zu identifizieren, die Verbesserungen benötigen – z. B. wenn Safari iOS aufgrund von Cross-Origin-Blocks eine höhere Abbruchrate hat, können Sie diese User systematisch auf einen Redirect-Flow leiten.

9. Wie Corbado Zahlungsanbietern zum Passkey-Erfolg verhilft#

9.1 Nahtlose Passkey-Erstellung: Bank-, Plattform- & Händler-Umgebungen#

Eine der kritischsten Herausforderungen beim Bau eines Third-Party Passkey SDKs ist die Orchestrierung eines reibungslosen und konsistenten Erstellungs-Flows – dort, wo User ihre Passkeys tatsächlich registrieren. Egal ob dies im Portal einer Bank, in den Account-Einstellungen des Zahlungsanbieters oder direkt auf der Checkout-Seite eines Händlers passiert: Die Kernschritte der Passkey-Registrierung sind sehr ähnlich. Folglich ändert sich der Ansatz zur Passkey-Erstellung nicht grundlegend, ob Sie den Flow in einem iFrame einbetten oder den User auf eine First-Party-Seite umleiten; was zählt, ist die Bereitstellung klarer, nutzerfreundlicher Screens, das Management von Cross-Origin-Einschränkungen und das Tracking essenzieller Metriken, die zeigen, wie effektiv User Passkeys annehmen. Unten sind die Schlüsselaspekte eines Best-Practice Passkey-Erstellungs-Flows und wie Corbado diese unterstützt:

9.1.1 Einheitliche Erstellungs-Screens & UI-Komponenten#

Unabhängig davon, wo ein User aufgefordert wird, einen Passkey zu erstellen – sei es in einer Online-Banking-Umgebung, der eigenen Website/App des Zahlungsanbieters oder beim Händler-Checkout – bietet Corbado vorgefertigte, anpassbare Komponenten für User Prompts, Erfolgsbestätigungen und Fehlerbehandlung.

Diese Komponenten gewährleisten ein konsistentes „Look and Feel“, erlauben aber gleichzeitig White-Label-Branding, sodass jede Bank oder jeder Händler bei Bedarf eigene Designelemente beibehalten kann.

Sehen Sie hier die UI-Komponente für den Passkey-Erstellungs-Screen im VicRoads-Design:

9.1.2 Zentralisiertes Tracking & Analytics#

Corbado sammelt und vereinheitlicht Daten von allen Erstellungs-Endpunkten:

• Bank-Websites oder -Apps, wo Passkeys initial angeboten werden.

• Die persönlichen Kontoeinstellungen des Zahlungsanbieters (wo User Credentials verwalten).

• Händler-Checkout-Seiten, die optional Passkey-Erstellung „on the fly“ erlauben.

Dieser vereinheitlichte Ansatz macht es einfach, die Passkey-Erstellungsrate, den Erstellungserfolg, Absprungpunkte und technische Fehler zu messen – egal welcher Kanal die Passkey-Registrierung initiiert.

9.1.3 KPIs & A/B-Tests#

Corbado bietet A/B-Testing-Features, um Bildschirmanweisungen, Button-Texte und das Timing von Prompts zu optimieren. Subtile Änderungen im Wording (z. B. „Erstellen Sie jetzt einen Passkey – nie wieder Passwörter!“ vs. „Sichern Sie Ihre nächste Zahlung mit einem Passkey!“) führen oft zu signifikanten Unterschieden in der Nutzerakzeptanz.

Basierend auf den Ergebnissen der A/B-Tests können folgende KPIs optimiert werden:

• Erstellungsrate: Prozentsatz der User, die nach Aufforderung erfolgreich einen Passkey einrichten.

• Erfolg der Erstellung: Der Anteil der User, die die Zeremonie ohne Abbruch oder Fehler beenden.

• Fallback-Nutzung: Die Rate, mit der User die Passkey-Erstellung zugunsten älterer Login-Methoden überspringen.

• Conversion Impact: Für Händler messbar, ob die Passkey-Erstellung beim Checkout Warenkorbabbrüche reduziert.

9.1.4 Flexibler Erstellungs-Kontext: Bank, Zahlungsanbieter oder Händler#

User können Passkeys in folgenden Kontexten erstellen:

• Bank-Kontext: Erstellungs-Flows, die ausgelöst werden, nachdem sich ein User bei seiner Bank eingeloggt hat, unter Nutzung des Vertrauens und der Vertrautheit der Banking-Umgebung.

• Kontoeinstellungen des Zahlungsanbieters: User richten Passkeys direkt im Bereich „Mein Profil“ oder „Sicherheit“ auf der Domain des Zahlungsanbieters ein.

• Händler-Checkout: Aufforderung im letzten Zahlungsschritt, besonders wenn der User noch keinen Passkey erstellt hat. Dies kann eingebettet (iFrame) oder via Redirect erfolgen.

In jedem Szenario folgt die zugrundeliegende Passkey-Zeremonie denselben Schritten – Nutzerbestätigung, Biometrie/PIN-Abfrage und Credential-Registrierung. Corbados SDK stellt sicher, dass Cross-Origin-Einschränkungen (bei Einbettung) oder First-Party-Domain-Kontext (bei Redirect) im Hintergrund nahtlos gehandhabt werden.

9.1.5 Konsistente Metadaten & Identifikator-Verknüpfung#

Corbado verknüpft jeden neuen Passkey mit dem passenden User-Identifikator – sei es „bankPrefix_userId“ oder eine interne User-Referenz im System des Zahlungsanbieters – sodass jede spätere Nutzung dem korrekten Benutzerkonto zugeordnet werden kann.

Diese Metadaten sind auch für fortgeschrittene Analysen entscheidend: zum Beispiel um zu sehen, wie RBCs Passkey-Erstellungs-Kampagnen im Vergleich zu TDs abschneiden, oder wie sich Erstellungsraten zwischen Händler-Checkouts und direkten „Kontoeinstellungen“-Flows unterscheiden.

9.1.6 Adaptive UI & Fehlerbehandlung#

Dieselbe Corbado SDK-Logik kann sich daran anpassen, ob Cross-Origin Passkey-Erstellung erlaubt ist (in modernem Chrome oder Edge) oder ob elegant auf einen Redirect für Safari gewechselt werden muss.

Eingebautes Error-Reporting hilft zu identifizieren, ob eine Teilmenge von Usern konstant bei der Passkey-Erstellung scheitert (z. B. ältere iOS-Versionen, Firmen-Windows-Geräte), sodass das Produktteam Anweisungen oder Fallback-Strategien verfeinern kann.

9.1.7 Corbados tiefe Erfahrung mit Passkey-Erstellungs-Flows#

Unser Team hat umfangreiche Experimente zur Passkey-Erstellung mit Enterprise-Kunden durchgeführt und gelernt, welche Phrasen, Button-Platzierungen und Timings die besten Adoptionsraten erzielen.

Wir integrieren diese Best Practices in jeden Erstellungs-Screen, erlauben aber dennoch volle Anpassbarkeit für Branding und Compliance-Anforderungen.

Insgesamt ist die Passkey-Erstellung die wichtigste Phase, um eine hohe Adoption sicherzustellen: Selbst der eleganteste Passkey Login Flow nützt nichts, wenn User niemals Credentials registrieren. Durch das Angebot einheitlicher, trackbarer Erstellungs-Screens über alle möglichen Kanäle – Bank, Domain des Zahlungsanbieters oder Händler-Checkout – und deren Instrumentierung mit KPI-Analytics und A/B-Tests, hilft Corbado Zahlungsanbietern, eine wirklich skalierbare Passkey Adoption zu treiben, die das Nutzererlebnis nativer Lösungen wie Apple Pay widerspiegelt.

9.2 Maximierung der Passkey-Nutzung für einen Apple Pay-ähnlichen Checkout#

Sobald ein User einen Passkey erstellt hat, ist der nächste Schritt sicherzustellen, dass er diesen Passkey tatsächlich für schnelle, reibungslose Zahlungen nutzt – ähnlich wie Apple Pay einen Zahlungsfluss präsentiert.

Bei Corbado haben wir einen „Passkey Intelligence“-Mechanismus entwickelt, der automatisch erkennt, wenn die Umgebung eines Users wahrscheinlich einen gültigen Passkey enthält, was ein echtes One-Tap Zahlungserlebnis ermöglicht. Unten sind die Kernelemente, die dies möglich machen.

9.2.1 OneTap Flow: Keine erneute Eingabe von Zugangsdaten#

Wenn ein wiederkehrender User erkannt wird, zeigt Corbados Frontend einen dedizierten Button (z. B. „Mit Passkey bezahlen“) anstatt zur Eingabe von Fallback-Credentials zu zwingen.

Ein Tippen auf diesen Button löst den WebAuthn get() Flow (oder nativen Passkey-Prompt) aus und lässt den User sich sofort via Biometrie/PIN authentifizieren – keine zusätzlichen Schritte oder Formulareingaben erforderlich.

9.2.2 Passkey Intelligence: Umgebungserkennung & Scoring#

Corbados SDK sammelt Signale (z. B. Local Storage Cookies, frühere erfolgreiche Passkey-Nutzung, Umgebungserkennungen), um vorherzusagen, ob das aktuelle Gerät + Browser wahrscheinlich einen gültigen Passkey für diesen User hat.

Wenn Cookies gelöscht oder nicht verfügbar sind, greift Corbado auf zusätzliche Heuristiken zurück (z. B. existierende bekannte Umgebung des Users, User Hints vom Händler), um zu entscheiden, ob es sicher ist, einen Passkey-Flow automatisch zu starten.

Wenn unzureichende Beweise für einen Passkey vorliegen, bietet die UI elegant Fallback-Flows an oder fordert den User auf zu bestätigen, dass er einen Passkey besitzt.

9.2.3 Keine PII-Speicherung, aber kontextsensitiv#

Corbado speichert keine persönlich identifizierbaren Informationen (PII) wie volle E-Mails oder Namen.

Stattdessen kann der Händler einen gehashten oder maskierten Identifikator übergeben (z. B. einen E-Mail-Hash oder interne User ID). Corbado nutzt diesen, um potenzielle Passkey-Registrierungen nachzuschlagen und entscheidet dann, ob eine Passkey-Authentifizierung gestartet oder auf einen generischeren Ansatz zurückgegriffen wird. Falls vom Zahlungsanbieter unterstützt, können wir die vom Händler bereitgestellten Informationen nutzen, um die interne User ID nachzuschlagen.

Dies gewährleistet Datenschutz und ermöglicht dennoch hochpräzises Umgebungs-Matching.

9.2.4 Fallback-Logik & Automatische Wiederherstellung#

In Szenarien, in denen der Passkey des Users existiert haben könnte, aber nicht erkannt werden kann (z. B. Cookies gelöscht, neues Gerät), analysiert Corbados Passkey Intelligence sorgfältig, ob ein Auto-Start des Passkey-Prompts Sinn macht.

Stattdessen würde der User alternative Fallback-Flows oder eine „Passkey von einem anderen Gerät scannen“-Option sehen, während ein schneller Weg zurück zur Passkey-Nutzung erhalten bleibt, falls der User manuell bestätigt, dass er einen besitzt.

9.2.5 Erweitertes Tracking & Coverage Insights#

Jedes Mal, wenn Corbado entscheidet, einen One-Tap Passkey-Prompt zu initiieren oder zu überspringen, wird diese Entscheidung protokolliert. Im Laufe der Zeit können Sie präzise sehen, welche Browser oder Gerätetypen die höchste Passkey-Abdeckung liefern vs. jene, die häufig auf Fallback zurückgreifen.

Diese Analytics-Feedbackschleife erlaubt es Ihnen, unterperformende Umgebungen (z. B. spezifische iOS- oder Android-Versionen) oder User-Segmente zu identifizieren, wo die Passkey-Nutzung niedrig bleibt – sodass Sie Onboarding- oder Edukationsstrategien verfeinern können.

9.2.6 Einheitliches One-Tap-Erlebnis über Use Cases hinweg#

Unabhängig davon, ob der User von einer Passkey-Erstellungs-Kampagne der Bank kommt oder direkt beim Checkout des Händlers landet, bleibt die One-Tap-Logik konsistent.

Corbado stellt sicher, dass, wenn ein Passkey gefunden wird (basierend auf Domain-Cookies, Local Storage Tokens oder Passkey Intelligence Signalen), dem User sofort der reibungsloseste Login-/Zahlungs-Flow präsentiert wird.

Zusammenfassung

Kurz gesagt: Die One-Tap Passkey-Nutzung ist der ultimative Payoff für die Erstellung von Passkeys. Durch die Nutzung von Passkey Intelligence – eine Mischung aus Umgebungserkennung, minimaler PII-Nutzung und Fallback-Logik – stellt Corbado sicher, dass Usern die Passkey-Authentifizierung nur dann präsentiert wird, wenn sie wirklich erfolgversprechend ist. Dies reduziert fehlgeschlagene Versuche drastisch, vermeidet Nutzerfrustration und fördert die gewohnheitsmäßige Passkey-Nutzung, was in einem One-Tap-Zahlungsfluss gipfelt, der mit dem Komfort von Apple Pay oder anderen nativen Zahlungserlebnissen konkurriert.

9.3 Umfangreiche Analytics für Passkey-Erstellungs- & Login-KPIs#

Über das bloße Aktivieren von Passkeys hinaus ist es entscheidend zu verstehen, wie effektiv sie über verschiedene Geräte, Browser und User Journeys hinweg angenommen und genutzt werden. Zahlungsanbieter benötigen harte Daten darüber, ob Passkeys tatsächlich Reibung reduzieren, Betrug verringern und die Conversion verbessern. Basierend auf den Best Practices des Buy vs. Build Passkey Guide bietet Corbado eine umfangreiche Analytics-Ebene, mit der Sie die Passkey-Performance in Echtzeit tracken, segmentieren und optimieren können.

Unten sind die wichtigsten Highlights.

9.3.1 Einheitlicher Passkey Funnel: Erstellung → Nutzung#

Corbado organisiert alle Passkey-Events in einem Trichter (Funnel): vom Moment, in dem ein User aufgefordert wird, einen Passkey zu erstellen, über die erfolgreiche Registrierung bis hin zu nachfolgenden Logins/Zahlungen (Passkey-Nutzung).

Diese Funnel-Visualisierung ermöglicht es Ihnen zu sehen, wo User abspringen – z. B. wie viele niemals die Erstellung starten, wie viele mitten in der Zeremonie abbrechen oder wie viele beim Login auf Fallback-Methoden zurückgreifen.

9.3.2 Kern-KPIs aus dem Buy vs. Build Passkey Guide#

Basierend auf unserer umfangreichen Erfahrung bei der Implementierung von Passkeys für Unternehmen konzentrieren wir uns auf Metriken, die direkten Einfluss auf ROI und Kundenzufriedenheit haben:

• Passkey Akzeptanzrate: Wie viele User, die einen Erstellungs-Prompt sehen, schließen die Passkey-Registrierung tatsächlich ab?

• Erfolgsrate der Passkey-Erstellung: Von denen, die die Zeremonie beginnen („Passkey erstellen“ klicken), welcher Prozentsatz schließt ohne Fehler oder Abbruch ab?

• Passkey Nutzungsrate: Wie oft wählen wiederkehrende User tatsächlich Passkeys für die tägliche Authentifizierung oder Zahlung, statt Passwörter oder OTP?

• Erfolgsrate beim Passkey-Login: Der Prozentsatz der Passkey-Versuche, die ohne Fallback oder Nutzerfrust gelingen.

• Fallback-Nutzung: Wie viele User initiieren einen Passkey-Flow, kehren aber zu älteren Methoden zurück? Dies signalisiert potenzielle UX- oder technische Barrieren.

9.3.3 Granulare OS & Browser Segmentierung#

Corbado taggt jedes Event automatisch mit Betriebssystem (Windows, macOS, iOS, Android) und Browser (Chrome, Safari, Edge, Firefox, etc.).

Mit dieser Segmentierung können Sie sehen, ob zum Beispiel iOS Safari eine höhere Passkey-Abbruchrate hat oder ob Windows Chrome eine bessere Passkey-Adoption liefert.

Diese Daten helfen Ihnen auch, Fallback-Strategien zu verfeinern – besonders wenn Apples Cross-Origin-Einschränkungen Ihre Nutzerbasis stärker betreffen als erwartet.

9.3.4 Dynamisches Reporting & Echtzeit-Dashboards#

Wir bieten Dashboard-Ansichten für jede Stufe des Passkey-Funnels: Erstellungs-Prompts, erfolgreiche Registrierungen, User-Logins, Fallback-Nutzung.

Echtzeit-Charts lassen Produktmanager Trends schnell erkennen (z. B. wenn ein neues OS-Update Passkey-Flows stört).

Automatisierte Warnungen können Ihr Team benachrichtigen, wenn Passkey-Erfolgsraten signifikant fallen – sodass Sie umgehend einen neuen Browser-Bug oder Konfigurationsfehler untersuchen können.

9.3.5 Debugging & Prozess-Logs#

Jeder Passkey-Flow (von Erstellung bis Login) wird mit zeitgestempelten Schritt-für-Schritt-Events protokolliert, was eine tiefe forensische Analyse ermöglicht.

Sie können schnell nach User-Hash, Session-ID oder Geräte-Signatur suchen, um genau zu sehen, wo ein User Probleme hatte oder welcher Fehlercode zurückgegeben wurde.

Dies ist kritisch für Rollouts im großen Maßstab, wo Sie sich nicht auf anekdotische Support-Tickets verlassen können, sondern präzise Daten benötigen, um Nutzerprobleme zu lösen.

9.3.6 Funnel-Optimierung mit A/B-Tests#

Corbados Analytics-Plattform unterstützt A/B-Tests, die in den Passkey-Funnel integriert sind: Testen Sie verschiedene CTA-Texte, Erstellungs-Prompts, Fallback-Nachrichten oder die Platzierung von „Passkey erstellen“-Buttons im Checkout-Flow.

Metriken wie „Passkey Akzeptanzrate“ oder „Fallback-Rate“ können Seite an Seite für jede Variante gemessen werden.

Dieser Ansatz gewährleistet kontinuierliche Verbesserung und spiegelt den Erfolg führender Passkey-Adoptierer wider, die ihre Flows im Laufe der Zeit verfeinern.

9.3.7 Flexibler Datenzugriff & Integration#

Während Corbados Dashboards eine visuelle Out-of-the-Box-Schnittstelle bieten, können Sie wichtige Datenpunkte (z. B. Erfolg der Passkey-Erstellung, Logins) auch exportieren oder per Webhook in Ihre BI- oder SIEM-Tools senden.

Dies ermöglicht Zahlungsanbietern, Passkey-KPIs in breitere Analytics-Suiten zu integrieren – und den ROI von Passkeys neben anderen Sicherheits-, Marketing- oder operativen Metriken zu tracken.

Zusammenfassung

Indem Sie jeden Schritt der Passkey-Reise messen und visualisieren – über OS/Browser-Kombinationen, Erstellungs-Flows und Login-Szenarien hinweg – gibt Ihnen Corbado die Einsichten, die nötig sind, um Ihr Passkey-Angebot kontinuierlich zu verfeinern. Diese Analysen bestätigen nicht nur, dass Passkeys aktiviert sind; sie beweisen, ob User sie tatsächlich in großem Maßstab annehmen, identifizieren Reibungspunkte und helfen Ihnen, die Nutzungsraten an den Punkt zu bringen, an dem Passkeys Passwörter für sichere, reibungslose Zahlungen wirklich ersetzen.

9.4 Multi-Device Sync & „Intelligenz“ für hohe Adoption#

Für Zahlungsanbieter reicht es oft nicht aus, einfach einen Passkey pro User zu erstellen, um ein wirklich nahtloses Authentifizierungserlebnis zu liefern. In der Realität wechseln User häufig Geräte – vom Laptop bei der Arbeit zum persönlichen Smartphone, Tablet und sogar gemeinsam genutzten Familiencomputern. Sicherzustellen, dass jedes Gerät einen gültigen Passkey für denselben Account hat, ist kritisch, um Reibung zu reduzieren und den Rückfall auf Passwörter zu verhindern. Apple Pay erreicht dies, indem es den iCloud Account über alle iCloud-verbundenen Geräte nutzen kann.

Unten sehen Sie, wie Corbado hilft, Multi-Device-Coverage über den gesamten Nutzerlebenszyklus hinweg aufrechtzuerhalten.

9.4.1 Erste Passkey-Erstellung vs. zusätzliche Geräte#

• Primäre Passkey-Erstellungs-Screens: Corbado konzentriert sich zunächst darauf, dass jeder User mindestens einen Passkey registriert – den „primären“ Passkey – wo immer er zuerst auf Ihren Zahlungsfluss trifft (z. B. beim Checkout, im Online-Portal einer Bank oder in Ihren Kontoeinstellungen).

• Sekundäre Passkey-Erstellungs-Screens: Nachdem ein User seinen ersten Passkey erfolgreich registriert hat, können nachfolgende Logins auf anderen Geräten automatisch einen kurzen „Dieses Gerät hinzufügen“-Flow anstoßen. Dies stellt sicher, dass der User schnell reibungslosen Passkey-Zugriff auf allen relevanten Geräten erhält, ohne erneut ein Passwort einzugeben oder zu Fallback-Methoden wechseln zu müssen.

9.4.2 Hybrid Auth für Geräte-„Heilung“#

Selbst wenn ein User einen Passkey auf einem Gerät hat, könnte er auf einem zweiten Gerät ohne lokalen Passkey erscheinen (aufgrund frischer OS-Installationen, Cookie-Löschungen oder einfach weil dort noch nie ein Passkey erstellt wurde).

Corbados Ansatz nutzt oft einen hybriden Schritt: Der User kann sich mit einem existierenden Passkey auf seinem Smartphone oder einer Fallback-Methode einloggen und dann sofort die Lücke „heilen“, indem er einen Passkey auf dem aktuellen Gerät erstellt.

Dieser Selbstreparaturprozess hilft, die Abdeckung hochzuhalten und eliminiert wiederholte Fallback-Nutzung in der Zukunft.

9.4.3 Erkennen & Anleiten von Usern zum Hinzufügen fehlender Geräte#

Durch Cross-Device-Signale und Corbados „Passkey Intelligence“ kann das System erkennen, wenn ein User mit existierendem Passkey zu einem nicht registrierten Gerät gewechselt ist.

Wenn Ihre UX-Strategie auf maximale Abdeckung abzielt, kann Corbado automatisch fragen: „Möchten Sie auf diesem Gerät einen Passkey hinzufügen, damit Sie beim nächsten Mal keinen Fallback benötigen?“

User können dies überspringen, wenn sie an einem Einweg-Gerät sind, schätzen aber typischerweise den Komfort des Passkey-basierten biometrischen Logins, sobald er erklärt wird.

9.4.4 Adaptive UI Flows#

Corbados SDK bietet unterschiedliche Screen-Flows für „erste Passkey-Erstellung“ (d. h. das allererste Mal, dass ein User ein Credential registriert) und „sekundäre Geräte“-Erstellung.

Das Messaging kann variieren: z. B. „Sichern Sie dieses neue Gerät mit einem Passkey“ vs. „Richten Sie Ihren ersten Passkey ein.“

Dies sorgt für Klarheit bei Endnutzern, die den Unterschied zwischen initialer Anmeldung und der Erweiterung der Abdeckung auf zusätzliche Geräte verstehen.

9.4.5 Umgang mit Fehlpaarungen & Fehlern#

Manchmal kann die Passkey-Erstellung mitten in der Zeremonie fehlschlagen oder das OS des Users ist veraltet. In solchen Szenarien zeichnet Corbado den Teilversuch auf und schlägt elegant mögliche Lösungen vor (Redirect, manueller Fallback oder Cross-Device QR Flow).

Der User kann beim nächsten Login-Versuch immer noch versuchen, einen Passkey auf diesem Gerät hinzuzufügen, oder sich auf einen existierenden Passkey von einem anderen Gerät verlassen.

9.4.6 Laufende Coverage-Metriken#

Corbados Analytics zeigen nicht nur, wie viele User initial einen Passkey erstellt haben, sondern auch, wie viele Passkeys auf mehrere Geräte ausgeweitet haben.

Sie können Geräteabdeckungsraten tracken (z. B. 1 Gerät vs. 2 oder mehr) und sehen, wie dies mit reduzierter Fallback-Nutzung oder verbessertem Zahlungserfolg korreliert.

Dies hilft Ihrem Team, User Education, App-Prompts oder bankbasierte Enrollment-Flows zu priorisieren, um die Multi-Device Passkey-Durchdringung zu erhöhen.

Zusammenfassung: Warum Multi-Device Coverage wichtig ist

Ohne konsistente Abdeckung über alle Nutzergeräte hinweg riskieren Sie, dass User jedes Mal auf Fallback-Authentifizierungsmaßnahmen gezwungen werden, wenn sie an einem „Nicht-Passkey“-Gerät sind. Dies bricht das reibungslose Erlebnis und hält operative Kosten hoch (z. B. SMS-Gebühren, Support-Overhead). Durch das Angebot sekundärer Passkey-Erstellungs-Screens, hybrider Fallback-Heilung und umgebungsgesteuerter Prompts stellt Corbado sicher, dass jeder User schließlich Passkeys auf allen genutzten Geräten pflegen kann – was eine höhere Gesamtadoption treibt und diese frustrierenden Fallback-Momente minimiert.

9.5 Beschleunigte Time-to-Market: Warum ganzheitliche Lösungen zählen#

Eines der größten Missverständnisse beim Bau eines Third-Party Passkey SDKs ist, dass der schwierigste Teil die Implementierung der WebAuthn-Aufrufe ist (z. B. navigator.credentials.create() oder navigator.credentials.get()).

In der Realität ist das der „einfache“ Teil – ein oder zwei API-Calls, um die Basis-Zeremonie auszulösen. Die wahre Komplexität und der echte Erfolgsfaktor liegen darin, eine Adoption im großen Maßstab sicherzustellen und ein volles Ökosystem um diese API-Calls herum zu bauen.

Unten sind die wichtigsten Punkte – untermauert durch den Buy vs. Build Passkey Guide –, die hervorheben, warum minimale, rein auf die Zeremonie fokussierte Implementierungen oft scheitern, echte Ergebnisse zu liefern.

9.5.1 Unbekannte Unbekannte & Jenseits der Zeremonie#

• Implementierung der Zeremonie: Das Erstellen oder Authentifizieren eines Passkeys erfordert meist nur wenige Zeilen JavaScript, um navigator.credentials.create() oder navigator.credentials.get() aufzurufen.

• Echte Komplexität: Sicherzustellen, dass der Passkey-Flow über viele Browser hinweg funktioniert, Fehler elegant handhabt und Fallbacks für ältere Systeme bietet. Sie benötigen zudem robustes Session-Management, Fehler-Logging, Analytics, Strategien zur Geräteabdeckung und mehr.

• Unvorhergesehene Fallstricke: Sobald Sie sich über eine „Tech Demo“ von Passkeys hinausbewegen, entdecken Sie Randfälle wie Cross-Origin-Blocks, Einschränkungen eingebetteter WebViews und Komplexitäten bei der Multi-Device-Synchronisation. Das sind die „unbekannten Unbekannten“, die naive In-House-Entwicklungen entgleisen lassen.

9.5.2 Adoption ist das wahre Ziel#

• Zeremonie vs. Adoption: Selbst wenn Sie eine perfekte WebAuthn-Zeremonie haben, wird eine niedrige Nutzerakzeptanz (z. B. <5% Passkey-Nutzungsrate) nur minimale Sicherheits- oder UX-Vorteile bringen.

• Ganzheitlicher Ansatz: Ein erfolgreicher Passkey-Rollout verlangt alles von überzeugenden User Prompts und A/B-getestetem Copywriting bis hin zu Multi-Device Coverage Flows, Fallback-Handling und kontinuierlichen Analytics – weit über die Basis-Zeremonie-Calls hinaus.

• Erkenntnisse aus dem Buy vs. Build Guide: Der Guide betont, dass das Treiben der Passkey Adoption – nicht nur das Aktivieren von Passkeys – letztendlich den ROI bestimmt. Wenn User sich nicht registrieren und Passkeys aktiv nutzen, steckt das Projekt effektiv bei „MFA 2.0“ fest, ohne Verbesserung der Conversion-Rate.

9.5.3 Risiken einer „Do It Yourself“ Minimal-Implementierung#

• Unvollständiges Fallback & Fehler-Handling: Fehlende fortgeschrittene Fallback-Logik oder Echtzeit-Debugging können zu Nutzer-Aussperrungen und höheren Supportkosten führen.

• Fragmentierte Multi-Device Coverage: Ohne Plan für das Synchronisieren zusätzlicher Geräte oder das „Heilen“ von Passkey-Lücken fallen User auf Passwörter zurück, wann immer sie die Plattform wechseln.

• Begrenzte Analytics & A/B-Tests: Fehlende Daten zu Passkey-Erstellungs-Funnels oder Umgebungsnutzung bedeuten, dass Sie die Adoption nicht systematisch verbessern oder neue Browser-Macken schnell beheben können.

9.5.4 Ganzheitliche Lösungen: Mehr als nur eine API#

• Vorgefertigte UI & Best Practices: Statt nur Zeremonie-Endpunkte offenzulegen, bündelt eine richtige Lösung (wie Corbado) White-Label-Screens, Fallback-Flows, Fehlerbehandlung und Cross-Device Coverage.

• Adaptive Intelligenz & Logging: Automatisches Erkennen wahrscheinlicher Passkey-Präsenz, Anleiten von Usern zum Erstellen oder Reparieren fehlender Passkeys und Erfassen granularer Event-Logs.

• Adoption-fokussierte „Unbekannte Unbekannte“: Viele Details – wie E-Mail-basierter Fallback oder der Umgang mit Firmengeräten – sind nicht offensichtlich, bis User in echten Deployments darauf stoßen.

9.5.5 Empfehlung, den Buy vs. Build Guide zu lesen#

• Tieferer Einblick in Adoptionsstrategie: Der Buy vs. Build Passkey Guide beleuchtet, wie man Kosten, Time-to-Market und die versteckten Komplexitäten einer robusten Passkey-Lösung ausbalanciert.

• Real-World Benchmarks: Erfahren Sie, wie Rollouts im großen Maßstab von großen Banken und E-Commerce-Anbietern die unbekannten Unbekannten überwanden, die auftauchen, nachdem Sie die „simple“ Zeremonie-Logik programmiert haben.

• Nachhaltiger Erfolg: Die Investition in eine etablierte Plattform mit bewährten Adoptions-Mustern stellt sicher, dass Sie das Rad nicht neu erfinden – und dabei teure Überraschungen erleben.

Zusammenfassend

Das bloße Verknüpfen der WebAuthn-Zeremonie reicht nicht aus, um eine bedeutsame Passkey Adoption zu erreichen. Echter Erfolg hängt von der Orchestrierung von End-to-End-Flows ab – wie Fallbacks, Analytics, Multi-Device-Erweiterungen und A/B-getesteten User Journeys. Indem Sie die nuancierten Komplexitäten jenseits von „nur der Zeremonie“ adressieren, können Sie Ihr Passkey-Projekt von einer technischen Kuriosität in eine wirklich reibungslose, breit genutzte und kostensparende Authentifizierungslösung verwandeln.

9.6 Flexibles Hosting & Deployment (Multi-AZ, Region-Agnostic)#

Zusätzlich zu den Komplexitäten rund um Cross-Origin Flows, Nutzerakzeptanz und Passkey-Lifecycle-Management sind Hosting- und Deployment-Überlegungen kritisch für jede Passkey-Lösung im großen Maßstab. Zahlungsanbieter haben oft mit strikter Compliance, Datenresidenz-Anforderungen und Resilienz-Vorgaben zu tun, die über Regionen hinweg stark variieren können. Unten sehen Sie, wie Corbado (oder ähnlich robuste Lösungen) diese Bedenken adressiert:

9.6.1 Regions-agnostische Cloud Deployments#

Um Datensouveränität oder regulatorische Rahmenbedingungen (z. B. DSGVO in Europa, PIPEDA in Kanada oder NIST/HIPAA in den USA) einzuhalten, müssen einige Anbieter Daten innerhalb spezifischer geografischer Grenzen halten.

Eine regions-agnostische Architektur stellt sicher, dass der Passkey-Dienst in jeder gewünschten AWS-Region bereitgestellt werden kann, um lokale Compliance-Mandate zu erfüllen, ohne Leistung oder Skalierbarkeit zu opfern.

Diese Flexibilität ist besonders wichtig, wenn Ihre Nutzerbasis mehrere Länder umfasst, die jeweils unterschiedliche Datenverarbeitungsregeln durchsetzen.

9.6.2 Multi-AZ (Availability Zone) Hochverfügbarkeit#

Für kritische Zahlungsauthentifizierungs-Flows ist Ausfallzeit keine Option. Corbado setzt Multi-AZ-Deployments ein und verteilt Schlüsselkomponenten über mehrere Verfügbarkeitszonen.

Dieses Setup hilft sicherzustellen, dass, wenn eine AZ einen Ausfall oder Verbindungsprobleme hat, Ihre Passkey-Infrastruktur in anderen Zonen online bleibt – sodass User sich weiterhin authentifizieren können.

Das Ergebnis ist ein resilienteres System, das strenge SLAs für Finanzdienstleistungen und E-Commerce-Seiten erfüllt, wo selbst kurze Ausfallzeiten zu signifikanten Umsatzeinbußen führen können.

9.6.3 Stand-Alone oder Hybrid Managed Hosting#

Einige Zahlungsanbieter bevorzugen ein privates dediziertes Cluster – sei es für engere Datenisolation, eigene Compliance-Checks oder tiefere Kontrolle über Patches und Updates.

Eine flexible Lösung kann beide Extreme unterstützen:

• SaaS / Multi-Tenant: Schnell zu implementieren, geringere Kosten, gut geeignet für viele mittelgroße Deployments.

• Dedicated Cloud Instance: Ein separates Konto und eine Datenbankinstanz in Ihrer gewählten Region, für diejenigen, die zusätzliche Isolation oder Compliance benötigen.

9.6.4 Skalierbare & Elastische Infrastruktur#

Passkeys müssen sprunghafte Workloads bewältigen: Riesige Traffic-Anstiege (z. B. Feiertags-Shopping-Peaks oder Event-Ticket-Verkäufe) können Systeme mit fester Kapazität überlasten.

Ein modernes Passkey-Backend skaliert horizontal in Echtzeit und fügt Recheninstanzen basierend auf Nutzungsmustern hinzu oder entfernt sie. Dieses Auto-Scaling gewährleistet konsistente Leistung ohne manuelles Eingreifen.

9.6.5 Sicherheit & Compliance Tools#

Industriestandards wie PCI-DSS, PSD2 SCA oder ISO 27001 gelten oft für Zahlungsanbieter. Ein robuster Passkey-Provider integriert typischerweise bekannte Compliance-Frameworks „out of the box“:

• Verschlüsselung at Rest und in Transit: Sichern Sie Daten mit starkem TLS und serverseitiger oder clientseitiger Verschlüsselung für gespeicherte Credentials.

• Logging und Audit Trails: Detaillierte Logs für jede Passkey-Operation, geeignet für Regulierungsbehörden oder Vorfalluntersuchungen.

• Regelmäßiges Sicherheits-Patching: Automatisches OS- und Container-Patching, um Sicherheitslücken fernzuhalten, besonders relevant in einer flüssigen Multi-AZ-Umgebung.

9.6.6 Disaster Recovery & Geo-Redundanz#

Echte Resilienz reicht über eine einzelne Region hinaus. Einige Anbieter schreiben Cross-Region-Replikation vor, um die Geschäftskontinuität bei großflächigen Katastrophen aufrechtzuerhalten.

Geo-Redundanz kann Passkey-Daten in einer anderen Region oder einem anderen Kontinent replizieren, um sicherzustellen, dass der Ausfall einer gesamten Region die Authentifizierungsflüsse nicht stoppt.

Zusammenfassung: Multi-AZ und Region-Independent

Die Wahl einer Passkey-Lösung, die einfach skaliert, sich geografisch anpasst und sowohl lokalen Ausfällen als auch großflächigen Katastrophen widersteht, ist essenziell für moderne Zahlungsanbieter – besonders jene, die in mehreren Ländern oder unter strikter Compliance operieren. Durch die Unterstützung von Multi-AZ-Deployments und regions-agnostischen Konfigurationen stellt Corbado (oder vergleichbare Lösungen) sicher, dass Passkey-Dienste für Zahlungen sowohl verfügbar als auch konform bleiben, egal wo Ihre User oder Daten liegen.

10. Fazit: Apples Barrieren überwinden & Passkeys nutzen#

Passkeys repräsentieren tatsächlich die nächste Generation sicherer, nutzerfreundlicher Authentifizierung. Dennoch stehen Zahlungsanbieter vor einzigartigen Herausforderungen, die das traditionelle WebAuthn-Design nicht direkt adressiert. Diese Einschränkungen sind am stärksten ausgeprägt in:

1. Safaris Weigerung, Cross-Origin Passkey-Erstellung zu erlauben (insbesondere in iFrames), was entweder einen Redirect-basierten Ansatz oder das Verlassen auf zuvor erstellte Passkeys erzwingt.

2. Apples fehlende Unterstützung für Secure Payment Confirmation (SPC), was einen reibungslosen, standardisierten Zahlungsfluss über Browser und Plattformen hinweg verhindert.

Nichtsdestotrotz bleiben Passkeys essenziell für Zahlungsanbieter, die ein Apple Pay–ähnliches Checkout-Erlebnis bieten wollen: gestrafft, sicher und herrlich einfach für Endnutzer. Unten sehen Sie, wie diese Herausforderungen adressiert werden können und wie Corbado hilft.

10.1 Schlüsselfragen beantwortet: Cross-Origin & SPC Einschränkungen#

1. Was sind die aktuellen Einschränkungen bei der Nutzung von Passkeys in Third-Party-Kontexten für Zahlungsanbieter?

• Cross-Origin Restriktionen: Safari (und einige ältere Browser) blockieren navigator.credentials.create(), wenn es via iFrame eingebettet ist. Das bedeutet, Sie können in einem Händler-eingebetteten Flow auf diesen Browsern nicht nahtlos neue Passkeys erstellen.

• Fehlender SPC Support: Apples Weigerung, SPC zu adoptieren, limitiert die Fähigkeit, Cross-Origin Zahlungsbestätigungen zu standardisieren, was Anbieter zwingt, separate Ansätze für Safari vs. Chrome/Edge zu pflegen.

• WebView & Native App Beschränkungen: Eingebettete WebViews brechen oft Passkey-Flows, was System-Browser-Sessions oder andere spezialisierte Ansätze erfordert, um Domain-Origin-Abgleich zu managen.

• Fragmentierte Geräteabdeckung: Selbst wenn der User einen Passkey auf einem Gerät oder Browser erstellt, könnte ihm die Abdeckung auf anderen fehlen, was Fallback-Nutzung verursacht.

2. Wie können Zahlungsanbieter diese Hürden überwinden, um Passkey-Integrationen erfolgreich umzusetzen?

• Nutzen Sie eine hybride (iFrame + Redirect) Strategie:

  • iFrame für Browser, die Cross-Origin Passkeys voll unterstützen, für eine nahtlose eingebettete UI.

  • Redirect als Fallback für Safari oder inkompatible Setups, um sicherzustellen, dass robuste Passkey-Erstellung immer möglich ist.

• System WebView oder Browser Redirect in nativen Apps:

  • Statt iFrames in Händler-Apps einzubetten, wechseln Sie zu ASWebAuthenticationSession (iOS) oder Chrome Custom Tabs (Android), um die Domain-Kontinuität zu wahren.

  • Adoption-fokussiertes Toolkit: Bieten Sie überzeugende Passkey-Erstellungs-Prompts, Multi-Device Coverage Flows und Fallback-„Heilungs“-Schritte, um die Nutzung hochzuhalten.

  • Advanced Analytics & A/B-Tests:

    • Messen Sie kontinuierlich Passkey-Erfolgs-/Fallback-Raten, Umgebungsabdeckung und User-Feedback, um Ihre Flows zu verfeinern.

    • Nutzen Sie Passkey Intelligence, um Passkeys automatisch nur dann zu präsentieren, wenn Erfolg wahrscheinlich ist.

10.2 Wie Corbado die Lücke für Zahlungsanbieter schließt#

In diesem Guide haben wir hervorgehoben, dass das bloße Verknüpfen von navigator.credentials.create() nicht ausreicht. Echter Erfolg hängt von hoher Passkey-Adoption, konsistenter User Experience und resilienter Multi-Device Coverage ab. Genau hier zeichnet sich Corbado aus:

• Einheitlicher Support für iFrame & Redirect: Corbados SDK erkennt automatisch, ob ein eingebetteter Passkey-Flow machbar ist (z. B. auf Chrome oder Edge) oder ob ein Redirect notwendig ist (z. B. Safari). Dies maximiert die Kompatibilität, ohne dass Händler mehrere Codepfade pflegen müssen.

  • One-Tap Zahlungserlebnis: Mit Passkey Intelligence erkennt Corbado sofort, ob die Umgebung eines Users wahrscheinlich einen gültigen Passkey hat – und löst einen reibungslosen „Mit Passkey bezahlen“ Flow aus. Dieser Ansatz ähnelt Apples One-Tap-Checkout und steigert die alltägliche Passkey-Nutzung, statt sie auf einen selten genutzten MFA-Schritt zu reduzieren.

  • Robuste Multi-Device Coverage: Corbado bietet spezielle Flows für die initiale Passkey-Erstellung versus sekundäre Passkey-Erweiterungen, sodass jeder User schnell Abdeckung für neue Geräte hinzufügen kann, nachdem er sich via Fallback oder Cross-Device QR eingeloggt hat.

  • Full-Stack Adoptions-Fokus: Durch integrierte Analytics, A/B-Tests und Fehlerbehandlung hilft Corbado Anbietern, Reibungspunkte zu identifizieren und die Passkey-Akzeptanz systematisch zu optimieren. Dies erstreckt sich von den ersten Passkey-Prompts der Banken bis zu den Checkout-Erlebnissen der Händler.

  • Flexibles, konformes Hosting: Corbados Multi-AZ, regions-agnostische Deployments stehen im Einklang mit strenger Zahlungsindustrie-Compliance (PCI DSS, PSD2 SCA, etc.) und gewährleisten Verfügbarkeit und Einhaltung von Datenresidenzregeln weltweit.

10.3 Fazit: Ein reibungsloses und skalierbares Passkey-Erlebnis bauen#

Während Apples restriktive Richtlinien unvermeidbare Reibung erzeugen, können Zahlungsanbieter dennoch erfolgreich Third-Party Passkeys implementieren, indem sie:

1. Den eingebetteten Ansatz (iFrame) mit Redirect-Fallback kombinieren.

2. Spezialisierte System WebViews oder externe Browser-Flows für native Apps adoptieren.

3. Sich auf robuste Adoptionsstrategien fokussieren: Multi-Device Coverage, Fallback-„Heilung“, fortgeschrittene Analytics und A/B-Tests.

Corbado bringt all diese Elemente zusammen und bietet eine Enterprise-Passkey-Plattform, die Passkey-Enrollment, One-Tap-Nutzung, Analytics-getriebene Optimierung und Hosting im globalen Maßstab abdeckt. Das Ergebnis: Ein wirklich reibungsloses Erlebnis wie Apple Pay für Ihren eigenen Zahlungsdienst, das sowohl erhöhte Sicherheit als auch eine überlegene User Journey liefert.