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

Passkeys entwickeln sich zur effektivsten Methode, um Online-Transaktionen zu sichern und zu autorisieren. Sie verbessern die Sicherheit und den Komfort im Vergleich zur herkömmlichen Multi-Faktor-Authentifizierung (MFA) erheblich. Kürzlich hat PayPal Passkeys als primäre, eigenständige MFA-Lösung eingeführt und damit einen klaren Trend für Zahlungsanbieter weltweit gesetzt.

Allerdings wurden Passkeys ursprünglich für Erstanbieter-Kontexte entwickelt. Das bedeutet, sie funktionieren am besten, wenn sich Nutzer direkt auf der Website oder in der App authentifizieren, der die Anmeldedaten gehören. Zahlungsanbieter agieren hingegen typischerweise in Drittanbieter-Kontexten, in denen 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 den operativen Modellen von Zahlungsanbietern führt zu erheblichen Einschränkungen für eine nahtlose Integration. Um diese Herausforderungen zu bewältigen, müssen wir zwei entscheidende Fragen untersuchen:

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

Bei der Untersuchung dieser Fragen wird sich zeigen, dass die laufenden Bemühungen der Branche, Passkeys an Drittanbieter-Kontexte anzupassen – insbesondere durch Webstandards wie Secure Payment Confirmation (SPC) – durch strategische Barrieren blockiert werden, die implizit von Apple auferlegt werden. Insbesondere Apples eingeschränkte Unterstützung für die Cross-Origin-Passkey-Erstellung in Safari und die fehlende Unterstützung des Secure Payment Confirmation-Standards stellen eine erhebliche Hürde dar. Dies erschwert die nahtlose Einführung der Passkey-basierten Authentifizierung durch Drittanbieter-Zahlungsdienstleister. Das Verstehen und Überwinden dieser Hürden ist für jeden Anbieter unerlässlich, der reibungslose und sichere Zahlungserlebnisse bieten möchte.

Passkeys bringen Phishing-resistente, biometrische Logins auf jede Ebene des Payment-Stacks. Im Folgenden wird aufgeschlüsselt, wie jeder Akteur in der Zahlungswertschöpfungskette von der Integration der Passkey-Authentifizierung profitieren kann.

Auswirkung: Schnellerer Checkout, höhere Konversionsraten, weniger Warenkorbabbrüche. Chance: Händler, die Passkeys über SDKs oder Redirect-Flows anbieten, können eine User Experience auf dem Niveau von Apple Pay nachahmen und die Abhängigkeit von Passwörtern oder OTPs verringern – was zu mehr Vertrauen und höheren Umsätzen führt.

Auswirkung: Nahtlose, passwortlose Authentifizierung über alle 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 Verifizierung von Karteninhabern machen.

Auswirkung: Stärkere Betrugsprävention. Chance: Issuer können eine Passkey-basierte Step-up-Authentifizierung in 3DS-Flows anbieten, was die OTP-Kosten senkt und die Nutzerzufriedenheit verbessert.

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

Auswirkung: Weniger 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 bereitstellen und gleichzeitig die Kompatibilität über Browser und native Apps hinweg gewährleisten.

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

Auswirkung: Sichere Speicherung von Anmeldedaten und reibungslose Wiederauthentifizierung. Chance: Wallet-Anbieter wie Apple Pay und Google Pay verwenden bereits Passkey-ähnliche Abläufe.

Im Folgenden werfen wir einen kurzen Blick auf große Zahlungs- und Kreditkartenanbieter und analysieren, ob und wie sie Passkeys implementiert haben:

Mastercard hat offiziell seinen Payment Passkey Service eingeführt, der ein passwortloses Authentifizierungserlebnis bietet, das in EMV 3DS-Flows eingebettet ist. Nutzer können Passkeys erstellen und verwenden, die an die Authentifizierungsdomain von Mastercard gebunden sind (z. B. verify.mastercard.com), was einen sicheren, biometrischen Login bei teilnehmenden Händlern ermöglicht. Diese Einführung stellt einen wichtigen Schritt in Richtung Phishing-resistenter, PSD2-konformer Authentifizierung in der Zahlungsbranche dar. Mehr lesen: Mastercard Passkeys

Visa hat seinen Visa Payment Passkey Service eingeführt und Passkeys in den „Click to Pay“-Flow integriert. Indem es Nutzern ermöglicht, sich nahtlos mit Biometrie anstelle von Passwörtern oder OTPs zu authentifizieren, zielt Visa darauf ab, das Online-Checkout-Erlebnis mit verbesserter Sicherheit und Nutzerfreundlichkeit zu modernisieren. Mehr lesen: VISA Passkeys

American Express hat noch kein öffentliches Passkey-Angebot eingeführt. Als Vorstandsmitglied der FIDO Alliance ist es jedoch wahrscheinlich, dass American Express in naher Zukunft eine Passkey-basierte Authentifizierungslösung im Einklang mit den breiteren Branchentrends einführen wird.

PayPal war einer der ersten Zahlungsanbieter, der Passkeys eingeführt hat. Ihre Implementierung unterstützt den nahtlosen biometrischen Login für Privat- und Geschäftskonten über alle Geräte hinweg. Der Passkey ist an die Domain von PayPal gebunden und bereits in vielen Regionen verfügbar. Ihre Implementierung hat jedoch noch Verbesserungspotenzial, insbesondere bei Multi-Device-Flows und der Plattformerkennung. Mehr lesen: PayPal Passkeys

Klarna hat die Passkey-Unterstützung noch nicht offiziell eingeführt. Nach unseren Beobachtungen verlässt sich Klarna stark auf eingebettete WebViews in seiner App und den Checkout-SDKs. Da Safari und iOS die Erstellung von Passkeys in iFrames / WebViews einschränken, könnte dies ein Grund sein, warum Klarna bisher keine Passkeys eingeführt hat.

Square hat den Passkey-Login für sein Entwickler-Dashboard und seine Verwaltungskonsole eingeführt, was einen sicheren, passwortlosen Zugriff auf interne Tools ermöglicht. Es wurde jedoch keine Ankündigung bezüglich der Passkey-Unterstützung in Zahlungsabläufen oder APIs für Endnutzer oder Händler gemacht.

Stripe hat den Passkey-Login für sein Dashboard eingeführt, sodass sich Entwickler mit Biometrie authentifizieren können. Passkeys für Stripe Checkout oder Elements sind noch nicht verfügbar. Angesichts der starken Befürwortung von Redirect-basierten Flows durch Stripe ist es wahrscheinlich, dass Passkeys – falls sie in Zahlungen implementiert werden – derselben Redirect-Architektur folgen würden.

Bisher hat BILL keine öffentlichen Ankündigungen oder Produktupdates im Zusammenhang mit Passkeys zur Authentifizierung gemacht.

Remitly hat keine Pläne oder öffentlichen Informationen über die Implementierung der Passkey-Authentifizierung in seinen Diensten bekannt gegeben.

Es gibt keine öffentlichen Berichte oder Produktdokumentationen, die darauf hindeuten, dass Payoneer Passkey-basierte Login- oder Transaktionsabläufe eingeführt hat oder testet.

Adyen hat Passkeys noch nicht in seine Authentifizierungs- oder Zahlungsabläufe eingeführt. Keine öffentliche Erklärung oder Entwicklerdokumentation erwähnt die Passkey-Unterstützung.

Worldpay hat bisher keine Unterstützung für Passkeys angekündigt. Ihr Authentifizierungs-Stack basiert weiterhin auf traditionellen Methoden wie Passwörtern, OTPs und 3DS-basierten Flows.

Checkout.com hat die Passkey-Unterstützung noch nicht öffentlich eingeführt. Es gibt keine Entwickler-Updates, Blog-Beiträge oder offiziellen Ankündigungen zur Einführung von Passkeys.

AliPay hat Passkeys nicht offiziell eingeführt. Angesichts des wachsenden Trends zur biometrischen Authentifizierung in chinesischen Zahlungsökosystemen könnte eine Einführung in Zukunft erfolgen, aber keine aktuelle Dokumentation bestätigt dies.

Mollie hat keine öffentlichen Erklärungen oder Produktupdates bezüglich der Einführung von Passkeys in seinen Authentifizierungs- oder Checkout-Systemen gemacht.

Amazon hat die Passkey-Unterstützung für Nutzer-Logins auf seiner Hauptplattform eingeführt. Die Ausweitung dieser Technologie auf Amazon Pay wäre ein natürlicher nächster Schritt, zumal viele Nutzer bereits einen bei Amazon registrierten Passkey haben, was das Onboarding der Nutzer beim Checkout erheblich vereinfachen würde.

Braintree, ein PayPal-Unternehmen, hat die Passkey-Authentifizierung noch nicht offiziell eingeführt. Ihre aktuelle Dokumentation erwähnt Passkeys nicht im Zusammenhang mit Nutzer-Logins oder Händler-APIs.

Link, die Ein-Klick-Checkout-Lösung von Stripe, hat Passkeys eingeführt und könnte als Grundlage für die Passkey-Strategie von Stripe bei Verbraucher-Zahlungen dienen. Stripe hat jedoch die Passkey-Unterstützung für Link oder spezifische Pläne für die Einführung nicht offiziell angekündigt.

Afterpay hat keine Erklärungen oder Funktionen im Zusammenhang mit der Passkey-Unterstützung veröffentlicht. Wie bei Klarna ist ihre Checkout-Integration stark App-basiert, was aufgrund von Einschränkungen durch eingebettete WebViews technische Hürden für die Einführung von Passkeys darstellen könnte.

Die Einführung von Passkeys durch Drittanbieter-Zahlungsdienstleister stößt auf strategische Hindernisse, die hauptsächlich durch die restriktive Politik von Apple in Safari verursacht werden. Zwei entscheidende Standardisierungsversuche wurden konsequent behindert:

• Secure Payment Confirmation (SPC)
• Erstellung von Drittanbieter-Passkeys in iFrames

Secure Payment Confirmation (SPC) stellt die bedeutendste Anstrengung der Branche dar – hauptsächlich von Google vorangetrieben –, um eine nahtlose, Cross-Origin-Nutzung von Passkeys zu ermöglichen, die speziell auf sichere Zahlungsautorisierungen zugeschnitten ist. SPC standardisiert, wie Zahlungsanbieter Nutzer über mehrere Händlerseiten hinweg authentifizieren, ohne die Sicherheit oder das Nutzererlebnis zu beeinträchtigen. Apple hat jedoch konsequent die Unterstützung für SPC in Safari verweigert, wahrscheinlich als strategischer Schachzug, um sicherzustellen, dass Apple Pay die bevorzugte, reibungsloseste Zahlungslösung in seinem Ökosystem bleibt. Apples Weigerung, SPC zu übernehmen, begrenzt nicht nur den weit verbreiteten Einsatz von Passkeys in Drittanbieter-Kontexten, sondern verzögert auch effektiv die breitere Einführung standardisierter Zahlungsauthentifizierung in der Branche.

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

Eine weitere kritische Hürde ist Apples bewusste Einschränkung der Passkey-Erstellung in Cross-Origin-iFrames. Während Safari die Verwendung bestehender Passkeys zur Authentifizierung (navigator.credentials.get()) in einem Drittanbieter-iFrame erlaubt, blockiert es explizit die Registrierung von Passkeys (navigator.credentials.create()) in solchen Kontexten.

Diese Einschränkung behindert Zahlungsanbieter erheblich, 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 den Fluss von Händlerintegrationen und schafft einen erheblichen Reibungspunkt für Verbraucher und Anbieter gleichermaßen.

Bei diesem Ansatz bindet der Händler Ihr Zahlungsformular in einen <iframe> ein, der von Ihrer Zahlungsanbieter-Domain bereitgestellt wird – zum Beispiel https://pay.provider.com. Der Nutzer 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.

Kernaussagen:

• Cross-Origin: Da sich der iFrame auf einer anderen Domain befindet, müssen Sie Berechtigungsrichtlinien 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 immer noch 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, insbesondere in Safari, fehlschlagen.

• Nutzeraktivierung: Passkey-Flows erfordern typischerweise eine „transiente Aktivierung“ (z. B. einen direkten Klick des Nutzers auf eine Schaltfläche). Stellen Sie sicher, dass Ihre iFrame-Schnittstelle die Passkey-Zeremonie innerhalb eines vom Nutzer initiierten Ereignisses auslöst.

• Sicherheit & UX: Der iFrame-Ansatz bietet ein reibungsloses, integriertes Checkout-Erlebnis. Wenn jedoch der Browser eines Nutzers Drittanbieter-Cookies oder den lokalen Speicher blockiert oder einschränkt, kann dies den Passkey-Flow stören.

Bei einem Redirect-basierten Flow leiten Sie den Nutzer von der Domain des Händlers zu Ihrer Zahlungsdomain weiter oder öffnen einen neuen Tab/ein neues Fenster, das auf etwas wie https://pay.provider.com/checkout verweist. Passkeys werden dann direkt auf Ihrer Domain in einem Erstanbieter-Kontext erstellt oder verwendet.

Kernaussagen:

• Erstanbieter-Einfachheit: Der gesamte Passkey-Workflow (Erstellung, Authentifizierung) findet auf der Domain des Zahlungsanbieters statt, sodass es keine Cross-Origin-Beschränkungen gibt. Alle gängigen Browser unterstützen die Erstellung und den Login mit Passkeys in Erstanbieter-Kontexten.

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

• Fallback für inkompatible Browser: Sie können einen geordneten Rückfall (Graceful Degradation) bereitstellen, wenn Passkeys nicht verfügbar sind (z. B. in älteren Browsern), indem Sie alternative Anmeldemethoden auf Ihrer Zahlungsdomain anbieten, ohne zusätzliches Cross-Origin-Berechtigungsmanagement zu benötigen.

Die Integration von Passkeys in native mobile Apps stellt im Vergleich zu webbasierten Szenarien einzigartige Herausforderungen dar. Native Apps für Händler (sowohl auf iOS als auch auf Android) betten Zahlungsvorgänge oft mithilfe von WebViews in die Anwendung ein, um ein nahtloses Nutzererlebnis zu gewährleisten. Die Implementierung der Drittanbieter-Passkey-Authentifizierung in diesen eingebetteten Kontexten kann jedoch aufgrund strenger Browser-Origin-Richtlinien und plattformspezifischer Einschränkungen problematisch sein.

Passkeys sind von Natur aus an eine bestimmte Domain (die „Relying Party ID“) gebunden, was ein zentrales Sicherheitsprinzip ist, das sicherstellt, dass Anmeldedaten nicht über nicht zusammengehörige Websites oder Apps hinweg missbraucht werden können. Wenn ein Zahlungsanbieter Passkeys unter seiner eigenen Domain erstellt – z. B. pay.provider.com –, sind diese Passkeys sowohl auf iOS als auch auf Android streng auf diese Domain beschränkt. Folglich kann die native App eines Händlers (die natürlich unter der eigenen App-Kennung und Domain des Händlers läuft) die Passkeys des Anbieters nicht direkt als „Erstanbieter“-Anmeldedaten aufrufen. Dies würde eine Cross-Origin-Freigabe von privaten Schlüsseln erfordern, was die Betriebssysteme und WebAuthn-Spezifikationen explizit verbieten, um Phishing und den Diebstahl von Anmeldedaten 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 mit Anmeldedaten zu authentifizieren, die für einen separaten Origin registriert sind, würde das grundlegende, an den Origin gebundene Sicherheitsmodell von Passkeys verletzen. Genau aus diesem Grund hängt die Verwendung von Drittanbieter-Passkeys in einem Händlerkontext von einem Systembrowser oder einer systembasierten WebView (wie ASWebAuthenticationSession auf iOS oder Chrome Custom Tabs auf Android) ab. Diese speziellen Abläufe bewahren den ursprünglichen Domain-Kontext des Anbieters – und stellen sicher, dass Passkeys sicher an den Origin gebunden bleiben –, während sie den Nutzern dennoch ermöglichen, sich innerhalb der App eines Händlers beim Zahlungsanbieter zu authentifizieren. In den folgenden Abschnitten werden wir untersuchen, wie das funktioniert.

Eingebettete WebViews (z. B. WKWebView auf iOS oder Androids WebView) sind sehr beliebt, da sie es Apps ermöglichen, Webinhalte direkt in ihre nativen Oberflächen einzubetten, was eine enge Integration und UX-Konsistenz bietet. Diese eingebetteten Umgebungen sind jedoch bei der Handhabung von Drittanbieter-Passkeys aufgrund von Origin- und Sicherheitsrichtlinien erheblich eingeschränkt:

• Origin-Konflikt: Passkeys verlassen sich strikt auf Domain-Origins für die sichere Handhabung von Anmeldedaten. Eine eingebettete WebView läuft 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 Drittanbieter-Zahlungsdienstleisters gebunden sind.

• Plattformsicherheitsbeschränkungen: Sowohl Apple (iOS) als auch Google (Android) haben die Authentifizierungsfähigkeiten von eingebetteten WebViews zunehmend eingeschränkt, insbesondere im Umgang mit sicheren Anmeldedaten. Diese Einschränkungen sollen die Privatsphäre der Nutzer und die Sicherheit schützen, machen die Implementierung von Drittanbieter-Passkeys aber deutlich komplizierter.

Insgesamt sind eingebettete WebViews aus UX-Sicht für Händler zwar attraktiv, führen aber zu erheblichen praktischen Einschränkungen bei der Implementierung robuster Drittanbieter-Passkey-Authentifizierungsabläufe.

Angesichts der Einschränkungen, die mit eingebetteten WebViews verbunden sind, wenden Zahlungsanbieter in der Regel eine von zwei alternativen Strategien an, um Drittanbieter-Passkeys in nativen mobilen Apps zuverlässig zu implementieren:

iOS (ASWebAuthenticationSession):

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

Das folgende Beispiel zeigt die „Check out with PayPal“-Funktionalität innerhalb der nativen BOSS-App. Es zeigt, wie eine ASWebAuthenticationSession System-WebView geöffnet wird, die ihren Zustand mit Safari-Cookies teilt, sodass der Passkey-Dialog sofort gestartet werden kann.

Android (Chrome Custom Tabs):

Ähnlich bieten Androids Custom Tabs eine browsernahe Umgebung, die eine konsistente Erstellung und Authentifizierung von Passkeys ermöglicht. Wie ASWebAuthenticationSession laufen Custom Tabs getrennt vom App-Kontext des Händlers und gewährleisten so die Integrität von Domain und Anmeldedaten.

Sehen Sie hier dasselbe Beispiel aus der nativen BOSS-App auf Android:

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

Beide Lösungen erfordern einen vorübergehenden Wechsel der Nutzer aus der nativen App-Umgebung des Händlers. Obwohl diese Ansätze im Vergleich zu eingebetteten Lösungen etwas weniger nahtlos sind, verbessern sie die Kompatibilität, Sicherheit und Zuverlässigkeit von Drittanbieter-Passkey-Operationen erheblich.

Letztendlich müssen Zahlungsanbieter, die native SDKs entwickeln, die Überlegungen zum Nutzererlebnis sorgfältig mit den praktischen technischen Einschränkungen abwägen. Trotz der Präferenzen der Händler für vollständig eingebettete Erlebnisse bleibt die Nutzung von System-WebViews oder externen Browser-Weiterleitungen die beste Vorgehensweise, um eine sichere und zuverlässige Drittanbieter-Passkey-Authentifizierung in nativen Apps zu gewährleisten.

Die Wahl zwischen einem eingebetteten (iFrame) und einem Redirect-basierten Ansatz zur Integration von Drittanbieter-Passkeys in Zahlungs-SDKs erfordert eine Abwägung von Kompromissen in den Bereichen Nutzererlebnis, Browserkompatibilität, technische Komplexität und Händlerpräferenzen.

Beide Lösungen haben deutliche Vor- und Nachteile, die Zahlungsanbieter sorgfältig auf der Grundlage ihres Zielmarktes, der gewünschten UX und der technischen Infrastruktur abwägen sollten.

Der eingebettete (iFrame) Ansatz bietet ein nahtloses, auf den Händler gebrandetes Nutzererlebnis, das für Händler sehr attraktiv ist, wird aber durch die begrenzte Browserkompatibilität behindert, insbesondere durch die Weigerung von Safari, die Cross-Origin-Passkey-Erstellung zu erlauben. Diese Einschränkung zwingt Händler und Anbieter zu komplexen, auf Workarounds basierenden Lösungen, die oft die Funktionalität beeinträchtigen oder zu einer unvollständigen Unterstützung der Passkey-Registrierung führen.

Im Gegensatz dazu bietet der Redirect-Ansatz eine umfassende Kompatibilität über Browser und native mobile Plattformen hinweg, da er in einem Erstanbieter-Domain-Kontext arbeitet. Er vereinfacht die Integration erheblich, verbessert die Zuverlässigkeit und gewährleistet die volle Unterstützung für die Erstellung und Authentifizierung von Passkeys. Der Hauptnachteil ist die potenzielle Reibung, die durch die Weiterleitung der Nutzer von der Website oder App des Händlers weg entsteht, obwohl dies durch sorgfältiges UX-Design, klar kommunizierte Erwartungen oder Integrationen mit vertrauenswürdigen Plattformen wie Corbado gemildert 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 Nutzers es unterstützt, und andernfalls auf einen Redirect-Ansatz zurückzugreifen. Diese kombinierte Strategie maximiert die Kompatibilität, die Attraktivität für Händler und die Kundenzufriedenheit in verschiedenen Umgebungen.

Die Implementierung eines Drittanbieter-Passkey-Zahlungs-SDKs erfordert ein Gleichgewicht zwischen Nutzererlebnis, Browserkompatibilität, Einschränkungen nativer Apps, Analysen und Sicherheit – insbesondere angesichts Apple-spezifischer Hürden (z. B. Blockierung der Cross-Origin-Passkey-Erstellung, fehlende SPC-Unterstützung). Im Folgenden finden Sie wichtige Empfehlungen, um das bestmögliche Ergebnis bei der Integration von Passkeys in Web- oder native Zahlungsabläufe zu gewährleisten.

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

• iFrame-Checkout (eingebettet)

  • Bietet ein nahtloses, seiteninternes Erlebnis für moderne Browser, die Cross-Origin-Passkey-Operationen erlauben (hauptsächlich zur Authentifizierung).

  • Muss die korrekte Permissions-Policy für publickey-credentials-get/publickey-credentials-create setzen.

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

• Redirect-Flow

  • Unterstützt zuverlässig sowohl die Registrierung als auch den Login mit Passkeys in einem Erstanbieter-Kontext.

  • Etwas mehr Reibung durch die zusätzliche Weiterleitung oder das Pop-up, aber universell sicherer für die browserübergreifende Kompatibilität.

  • Idealer Fallback für Safari, der derzeit keine Drittanbieter-Passkey-Erstellung in iFrames erlaubt.

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

Die genaue Erkennung von Browser-Fähigkeiten bleibt aufgrund der reduzierten Granularität des User-Agent und der inkonsistenten Unterstützung von Client Hints über Plattformen hinweg eine Herausforderung.

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

Obwohl Client Hints Daten mit hoher Entropie auf datenschutzfreundliche Weise bereitstellen, unterstützen nur Chromium-basierte Browser sie vollständig. Safari und Firefox bieten keine Client-Hint-Unterstützung, was die präzise Funktionserkennung auf Apple-Geräten stark einschränkt.

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

Angesichts dieser Einschränkungen erfordert die zuverlässige Erkennung der Cross-Origin-Passkey-Unterstützung – insbesondere in Drittanbieter-Zahlungs-SDKs – eine sorgfältige Kombination aus dynamischen Client-Hint-Abfragen (sofern verfügbar), Fallback-User-Agent-Heuristiken und konservativen Standardverhalten für Browser wie Safari und Firefox.

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: Verwenden Sie ASWebAuthenticationSession (iOS) oder Custom Tabs (Android), um die Erstellung/den Login mit Passkeys in einen sicheren „Erstanbieter“-Browserkontext zu verlagern.

• Weiterleitung zum Standardbrowser: Ein weniger nahtloser, aber sehr zuverlässiger Ansatz, um die Domain-Integrität für Passkey-Operationen zu gewährleisten.

Als Zahlungsanbieter sind starke Sicherheit und die Einhaltung gesetzlicher Vorschriften (PCI, PSD2 SCA usw.) entscheidend:

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

• Protokollierung & Überwachung: Protokollieren Sie die Erstellungs- und Nutzungsereignisse von Passkeys gründlich zur Betrugsprävention und für Compliance-Audits.

• Minimale Speicherung von PII: Ordnen Sie Nutzer Passkeys mithilfe von gehashten Kennungen zu, um die Exposition unter GDPR oder ähnlichen Datenschutzgesetzen zu reduzieren.

• Audit-Trails: Protokollieren Sie jedes Erstellungs- und Authentifizierungsereignis von Passkeys, um Anomalien zu erkennen und Compliance-Audits zu erfüllen.

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

• Browser- & Betriebssystemübergreifendes Testen: Automatisieren Sie Tests in Safari, Chrome, Edge, Firefox und den wichtigsten mobilen Betriebssystemversionen.

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

• Nutzerfeedback & Fehlerraten: Protokollieren Sie Passkey-Fehler (Erstellung oder Login), um Probleme schnell zu beheben, insbesondere bei Apple-basierten Nutzern.

Ein robustes KPI-Framework hilft Ihnen zu verfolgen, ob Ihre Drittanbieter-Passkey-Integration die Sicherheit und das Nutzererlebnis wirklich verbessert. Auch wenn es in diesem Artikel um die Implementierung von SDKs geht, ist es wichtig zu bedenken, dass die Akzeptanz von Passkeys auch in diesem Anwendungsfall entscheidend ist. Die Erstellungs- und Nutzungsrate von Passkeys erfordert eine sorgfältige Analyse und Optimierung.

• Definition: Prozentsatz der Nutzer, die erfolgreich einen Passkey erstellen, wenn sie dazu aufgefordert werden (z. B. beim Checkout oder bei der Kontoeinrichtung).

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

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

• Definition: Von den Nutzern, die die Erstellungszeremonie beginnen (auf „Passkey erstellen“ klicken), wie viele schließen sie ohne Abbruch oder Fehler ab?

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

• Ziel: Idealerweise haben Sie eine Zahl von ~95–100 %, sobald ein Nutzer sich dafür entscheidet.

• Definition: Der Prozentsatz der gesamten Zahlungsautorisierungen (oder Logins), die über Passkeys im Gegensatz zu Fallback-Methoden durchgeführt werden.

• Warum es wichtig ist: Die Erstellung ist bedeutungslos, wenn Nutzer auf ältere Methoden zurückgreifen.

• Ziel: Eine Rate von 50–80 % signalisiert eine starke Akzeptanz von Passkeys.

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

• Warum es wichtig ist: Ein Spiegelbild Ihrer realen Benutzerfreundlichkeit.

• Ziel: Typischerweise sollten Sie 90–95 % überschreiten, um Passkeys als „reibungslos“ zu betrachten.

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

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

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

Für Zahlungsanbieter: Messen Sie, ob Passkeys Betrug reduzieren, den Checkout beschleunigen oder Warenkorbabbrüche senken. Kombinieren Sie Passkey-Nutzungsdaten mit Zahlungskonversions- oder 3-D Secure-Erfolgsmetriken für eine ganzheitliche Sicht.

Die Überwachung dieser KPIs hilft Ihnen, genau zu bestimmen, welche Umgebungen oder Nutzerreisen verbessert werden müssen – z. B. wenn Safari auf iOS eine höhere Abbruchrate aufgrund von Cross-Origin-Blockaden aufweist, können Sie diese Nutzer systematisch zu einem Redirect-Flow leiten.

Eine der kritischsten Herausforderungen beim Aufbau eines Drittanbieter-Passkey-SDKs ist die Orchestrierung eines reibungslosen und konsistenten Erstellungsablaufs – bei dem die Nutzer tatsächlich ihre Passkeys registrieren. Ob dies im Portal einer Bank, in den Kontoeinstellungen des Zahlungsanbieters selbst oder direkt auf der Checkout-Seite eines Händlers geschieht, die Kernschritte der Passkey-Registrierung sind sehr ähnlich. Folglich ändert sich der Ansatz zur Passkey-Erstellung nicht grundlegend, je nachdem, ob Sie den Flow in einen iFrame einbetten oder den Nutzer auf eine Erstanbieter-Seite umleiten; am wichtigsten ist es, klare, benutzerfreundliche Bildschirme bereitzustellen, Cross-Origin-Einschränkungen zu verwalten und die wesentlichen Metriken zu verfolgen, die zeigen, wie effektiv Nutzer Passkeys annehmen. Im Folgenden sind die Schlüsselaspekte eines Best-Practice-Passkey-Erstellungsablaufs und wie Corbado sie unterstützt:

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

Diese Komponenten gewährleisten ein einheitliches Erscheinungsbild und ermöglichen gleichzeitig ein White-Label-Branding, sodass jede Bank oder jeder Händler bei Bedarf seine einzigartigen Designelemente beibehalten kann.

Sehen Sie sich die folgende UI-Komponente für den Passkey-Erstellungsbildschirm im Design von VicRoads an:

Corbado sammelt und vereinheitlicht Daten von allen Erstellungsendpunkten:

• Bank-Websites oder -Apps, auf denen Passkeys ursprünglich angeboten werden.

• Die persönlichen Kontoeinstellungen des Zahlungsanbieters (wo Nutzer Anmeldedaten verwalten können).

• Händler-Checkout-Seiten, die optional die Erstellung von Passkeys „on the fly“ ermöglichen.

Dieser einheitliche Ansatz macht es einfach, die Passkey-Erstellungsrate, die Erfolgsrate bei der Erstellung, die Abbruchpunkte der Nutzer und alle technischen Fehler zu messen – unabhängig davon, welcher Kanal die Passkey-Registrierung initiiert.

Corbado bietet A/B-Testfunktionen, um Anweisungen auf dem Bildschirm, Schaltflächentexte und das Timing von Aufforderungen zu optimieren. Feine Änderungen in der Formulierung (z. B. „Passkey jetzt erstellen – keine Passwörter mehr!“ vs. „Sichern Sie Ihre nächste Zahlung mit einem Passkey!“) führen oft zu signifikanten Unterschieden in der Nutzerakzeptanz.

Basierend auf den Ergebnissen des A/B-Tests können die folgenden KPIs optimiert werden:

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

• Erfolgsrate bei der Erstellung: Der Anteil der Nutzer, die die Zeremonie ohne Abbruch oder Fehler beenden.

• Fallback-Nutzung: Die Rate, mit der Nutzer die Passkey-Erstellung zugunsten älterer Anmeldemethoden überspringen.

• Auswirkung auf die Konversion: Für Händler: Messen Sie, ob die Erstellung von Passkeys beim Checkout die Warenkorbabbrüche reduziert.

Nutzer können Passkeys in den folgenden Kontexten erstellen:

• Bank-Kontext: Erstellungsabläufe, die ausgelöst werden, nachdem sich ein Nutzer bei seiner Bank eingeloggt hat, und die das Vertrauen und die Vertrautheit der Banking-Umgebung nutzen.

• Kontoeinstellungen des Zahlungsanbieters: Nutzer richten Passkeys direkt in ihren „Mein Profil“- oder „Sicherheit“-Einstellungen auf der Domain des Zahlungsanbieters ein.

• Händler-Checkout: Aufforderung im letzten Zahlungsschritt, insbesondere wenn der Nutzer zuvor keinen Passkey erstellt hat. Dies kann eingebettet (iFrame) oder per Redirect erfolgen.

In jedem Szenario folgt die zugrunde liegende Passkey-Zeremonie denselben Schritten – Nutzerbestätigung, biometrische/PIN-Aufforderung und Registrierung der Anmeldedaten. Das SDK von Corbado stellt sicher, dass Cross-Origin-Einschränkungen (falls eingebettet) oder der Erstanbieter-Domain-Kontext (falls weitergeleitet) nahtlos im Hintergrund gehandhabt werden.

Corbado verknüpft jeden neuen Passkey mit der entsprechenden Nutzerkennung – sei es „bankPrefix_userId“ oder eine interne Nutzerreferenz im System des Zahlungsanbieters –, sodass jede nachfolgende Nutzung auf das richtige Nutzerkonto zurückverfolgt werden kann.

Diese Metadaten sind auch für fortgeschrittene Analysen entscheidend: zum Beispiel, um zu sehen, wie die Passkey-Erstellungskampagnen von RBC im Vergleich zu denen von TD abschneiden oder wie sich die Erstellungsraten zwischen Händler-Checkouts und direkten „Kontoeinstellungen“-Flows unterscheiden.

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

Die integrierte Fehlerberichterstattung hilft zu erkennen, ob eine Teilgruppe von Nutzern durchweg bei der Passkey-Erstellung scheitert (z. B. ältere iOS-Versionen, firmeneigene Windows-Geräte), sodass das Produktteam Anweisungen oder Fallback-Strategien verfeinern kann.

Unser Team hat umfangreiche Experimente zur Passkey-Erstellung mit Unternehmenskunden durchgeführt und gelernt, welche Formulierungen, Schaltflächenplatzierungen und Timings die besten Akzeptanzraten erzielen.

Wir integrieren diese Best Practices in jeden Erstellungsbildschirm, während wir gleichzeitig eine vollständige Anpassung für Branding- und Compliance-Anforderungen ermöglichen.

Insgesamt ist die Passkey-Erstellung die wichtigste Phase, um eine hohe Akzeptanz zu gewährleisten: Selbst der eleganteste Passkey-Login-Flow nützt nichts, wenn die Nutzer niemals Anmeldedaten registrieren. Indem Corbado einheitliche, nachverfolgbare Erstellungsbildschirme über alle möglichen Kanäle – Bank, Zahlungsanbieter-Domain oder Händler-Checkout – anbietet und diese mit KPI-Analysen und A/B-Tests instrumentiert, hilft Corbado Zahlungsanbietern, eine wirklich skalierbare Passkey-Akzeptanz voranzutreiben, die das Nutzererlebnis nativer Lösungen wie Apple Pay widerspiegelt.

Sobald ein Nutzer einen Passkey erstellt hat, besteht der nächste Schritt darin, sicherzustellen, dass er diesen Passkey tatsächlich für schnelle, reibungslose Zahlungen verwendet, wie es Apple Pay in einem Apple Pay-Zahlungsablauf präsentiert.

Bei Corbado haben wir einen „Passkey Intelligence“-Mechanismus entwickelt, der automatisch erkennt, wann die Umgebung eines Nutzers wahrscheinlich einen gültigen Passkey enthält, und so ein echtes One-Tap-Zahlungserlebnis ermöglicht. Im Folgenden sind die Kernelemente aufgeführt, die dies möglich machen.

Wenn ein wiederkehrender Nutzer erkannt wird, zeigt das Frontend von Corbado eine dedizierte Schaltfläche an (z. B. „Mit Passkey bezahlen“), anstatt die Eingabe von Fallback-Anmeldedaten zu erzwingen.

Ein Tippen auf diese Schaltfläche löst den WebAuthn get()-Flow (oder die native Passkey-Aufforderung) aus, sodass sich der Nutzer sofort per Biometrie/PIN authentifizieren kann – keine zusätzlichen Schritte oder Formulareingaben erforderlich.

Das SDK von Corbado sammelt Signale (z. B. Cookies im lokalen Speicher, frühere erfolgreiche Passkey-Nutzung, Umgebungserkennungen), um vorherzusagen, ob das aktuelle Gerät + Browser wahrscheinlich einen gültigen Passkey für diesen Nutzer hat.

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

Wenn nicht genügend Beweise für das Vorhandensein eines Passkeys vorliegen, bietet die Benutzeroberfläche elegant Fallback-Flows an oder fordert den Nutzer auf, zu bestätigen, dass er einen Passkey hat.

Corbado speichert keine personenbezogenen Daten (PII) wie vollständige E-Mails oder Namen.

Stattdessen kann der Händler eine gehashte oder maskierte Kennung übergeben (z. B. einen E-Mail-Hash oder eine interne User ID). Corbado verwendet diese, um nach potenziellen Passkey-Registrierungen zu suchen und entscheidet dann, ob eine Passkey-Authentifizierung gestartet oder auf einen allgemeineren Ansatz zurückgegriffen werden soll. Wenn vom Zahlungsanbieter unterstützt, können wir die vom Händler bereitgestellten Informationen nachschlagen, um die interne User ID zu finden.

Dies gewährleistet die Privatsphäre der Nutzer und ermöglicht gleichzeitig eine hochpräzise Umgebungszuordnung.

In Szenarien, in denen der Passkey des Nutzers möglicherweise existierte, aber nicht erkannt werden kann (z. B. Cookies gelöscht, neues Gerät), analysiert die Passkey Intelligence von Corbado sorgfältig, ob es sinnvoll ist, eine Passkey-Aufforderung automatisch zu starten.

Stattdessen würde der Nutzer alternative Fallback-Flows oder eine Option „Passkey von einem anderen Gerät scannen“ sehen, während gleichzeitig ein schneller Weg zurück zur Passkey-Nutzung erhalten bleibt, wenn der Nutzer manuell bestätigen kann, dass er einen hat.

Jedes Mal, wenn Corbado sich entscheidet, eine One-Tap-Passkey-Aufforderung zu initiieren oder zu überspringen, wird diese Entscheidung protokolliert. Im Laufe der Zeit können Sie genau sehen, welche Browser oder Gerätetypen die höchste Passkey-Abdeckung erzielen und welche häufig auf Fallbacks zurückgreifen.

Diese Analyse-Feedbackschleife ermöglicht es Ihnen, leistungsschwache Umgebungen (z. B. bestimmte iOS- oder Android-Versionen) oder Nutzersegmente zu identifizieren, in denen die Passkey-Nutzung niedrig bleibt – sodass Sie Onboarding- oder Aufklärungsstrategien verfeinern können.

Unabhängig davon, ob der Nutzer von der Passkey-Erstellungskampagne einer Bank oder direkt vom Checkout eines Händlers kommt, bleibt die One-Tap-Logik konsistent.

Corbado stellt sicher, dass, wenn ein Passkey gefunden wird (basierend auf Domain-Cookies, lokalen Speichertokens oder Passkey Intelligence-Signalen), dem Nutzer sofort der reibungsloseste Login-/Zahlungsablauf präsentiert wird.

Zusammenfassung

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

Über die reine Aktivierung von Passkeys hinaus ist es entscheidend zu verstehen, wie effektiv sie auf verschiedenen Geräten, Browsern und Nutzerreisen angenommen und verwendet werden. Zahlungsanbieter benötigen harte Daten darüber, ob Passkeys wirklich die Reibung reduzieren, Betrug eindämmen und die Konversion verbessern. Basierend auf den Best Practices des Buy vs. Build Passkey Guide bietet Corbado eine umfassende Analyseschicht, mit der Sie die Leistung von Passkeys in Echtzeit verfolgen, segmentieren und optimieren können.

Im Folgenden sind die wichtigsten Highlights aufgeführt.

Corbado organisiert alle Passkey-Ereignisse in einem Funnel: von dem Moment, in dem ein Nutzer 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 Nutzer abspringen – z. B. wie viele die Erstellung nie beginnen, wie viele mitten in der Zeremonie abbrechen oder wie viele beim Login auf Fallback-Methoden zurückgreifen.

Basierend auf unserer umfangreichen Erfahrung bei der Unterstützung von Unternehmen bei der Implementierung von Passkeys konzentrieren wir uns auf Metriken, die sich direkt auf den ROI und die Nutzerzufriedenheit auswirken:

• Passkey-Akzeptanzrate: Wie viele Nutzer, die eine Erstellungsaufforderung sehen, schließen die Passkey-Registrierung tatsächlich ab?

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

• Passkey-Nutzungsrate: Wie oft wählen wiederkehrende Nutzer tatsächlich Passkeys für die tägliche Authentifizierung oder Zahlung anstelle von Passwörtern oder OTP?

• Erfolgsrate beim Passkey-Login: Der Prozentsatz der Passkey-Versuche, die ohne Fallback oder Nutzerfrustration erfolgreich sind.

• Fallback-Nutzung: Wie viele Nutzer initiieren einen Passkey-Flow, greifen aber auf ältere Methoden zurück? Dies deutet auf potenzielle UX- oder technische Hürden hin.

Corbado versieht jedes Ereignis automatisch mit dem Betriebssystem (Windows, macOS, iOS, Android) und dem Browser (Chrome, Safari, Edge, Firefox usw.).

Mit dieser Segmentierung können Sie sehen, ob beispielsweise iOS Safari eine höhere Abbruchrate bei Passkeys aufweist oder ob Windows Chrome eine bessere Passkey-Akzeptanz erzielt.

Diese Daten helfen Ihnen auch, Fallback-Strategien zu verfeinern – insbesondere, wenn die Cross-Origin-Beschränkungen von Apple Ihre Nutzerbasis stärker als erwartet betreffen.

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

Echtzeit-Diagramme ermöglichen es Produktmanagern, Trends schnell zu erkennen (z. B. wenn ein neues Betriebssystem-Update die Passkey-Flows unterbricht).

Automatisierte Benachrichtigungen können Ihr Team informieren, wenn die Erfolgsraten von Passkeys erheblich sinken – sodass Sie umgehend einen neuen Browser-Bug oder ein Konfigurationsproblem untersuchen können.

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

Sie können schnell nach Nutzer-Hash, Sitzungs-ID oder Gerätesignatur suchen, um genau zu sehen, wo ein Nutzer Schwierigkeiten hatte oder welcher Fehlercode zurückgegeben wurde.

Dies ist entscheidend für groß angelegte Rollouts, bei denen Sie sich nicht auf anekdotische Support-Tickets verlassen können, sondern präzise Daten zur Lösung von Nutzerproblemen benötigen.

Die Analyseplattform von Corbado unterstützt A/B-Tests, die in den Passkey-Funnel integriert sind: Testen Sie verschiedene CTA-Texte, Erstellungsaufforderungen, Fallback-Nachrichten oder die Platzierung von „Passkey erstellen“-Schaltflächen im Checkout-Flow.

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

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

Während die Dashboards von Corbado eine sofort einsatzbereite visuelle Oberfläche bieten, können Sie auch wichtige Datenpunkte (z. B. Erfolg bei der Passkey-Erstellung, Logins) exportieren oder per Webhook in Ihre BI- oder SIEM-Tools integrieren.

Dies ermöglicht es Zahlungsanbietern, Passkey-KPIs in breitere Analyse-Suiten zu integrieren – und den ROI von Passkeys neben anderen Sicherheits-, Marketing- oder Betriebsmetriken zu verfolgen.

Zusammenfassung

Indem jeder Schritt der Passkey-Reise gemessen und visualisiert wird – über Betriebssystem-/Browser-Kombinationen, Erstellungsabläufe und Login-Szenarien hinweg – gibt Ihnen Corbado die Einblicke, die Sie benötigen, um Ihr Passkey-Angebot kontinuierlich zu verfeinern. Diese Analysen bestätigen nicht nur, dass Passkeys aktiviert sind; sie beweisen, ob die Nutzer sie tatsächlich in großem Umfang annehmen, identifizieren Reibungspunkte und helfen Ihnen, die Nutzungsraten so zu steigern, dass Passkeys Passwörter für sichere, reibungslose Zahlungen wirklich ersetzen.

Für Zahlungsanbieter reicht es oft nicht aus, nur einen Passkey pro Nutzer zu erstellen, um ein wirklich nahtloses Authentifizierungserlebnis zu bieten. In der Realität wechseln Nutzer häufig die Geräte – von Laptops bei der Arbeit zu persönlichen Smartphones, Tablets und sogar gemeinsam genutzten Familiencomputern. Sicherzustellen, dass jedes Gerät einen gültigen Passkey für dasselbe Konto hat, ist entscheidend, um Reibung zu reduzieren und den Rückgriff auf Passwörter zu verhindern. Apple Pay erreicht dies, indem es das iCloud-Konto über alle mit iCloud verbundenen Geräte nutzen kann.

Im Folgenden wird beschrieben, wie Corbado dabei hilft, die Abdeckung über mehrere Geräte während des gesamten Nutzerlebenszyklus aufrechtzuerhalten.

• Primäre Passkey-Erstellungsbildschirme: Corbado konzentriert sich zunächst darauf, jeden Nutzer dazu zu bringen, mindestens einen Passkey zu registrieren – den „primären“ Passkey –, wo immer er zum ersten Mal auf Ihren Zahlungsablauf stößt (z. B. beim Checkout, im Online-Portal einer Bank oder in Ihren Kontoeinstellungen).

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

Selbst wenn ein Nutzer einen Passkey auf einem Gerät hat, kann er auf einem zweiten Gerät ohne lokalen Passkey erscheinen (aufgrund von Neuinstallationen des Betriebssystems, gelöschten Cookies oder einfach, weil auf diesem Gerät nie ein Passkey erstellt wurde).

Der Ansatz von Corbado verwendet oft einen hybriden Schritt: Der Nutzer kann sich mit einem bestehenden Passkey auf seinem Telefon oder einer Fallback-Methode anmelden und dann die Lücke sofort „heilen“, indem er einen Passkey auf dem aktuellen Gerät erstellt.

Dieser Selbstreparaturprozess hilft, die Abdeckung hoch zu halten und wiederholte Fallback-Nutzung in der Zukunft zu eliminieren.

Durch geräteübergreifende Signale und die „Passkey Intelligence“ von Corbado kann das System erkennen, wenn ein Nutzer mit einem bestehenden Passkey auf ein nicht registriertes Gerät gewechselt hat.

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

Nutzer können dies überspringen, wenn sie sich auf einem einmalig genutzten Gerät befinden, schätzen aber in der Regel den Komfort des biometrischen Logins mit Passkey, sobald er erklärt wurde.

Das SDK von Corbado bietet unterschiedliche Bildschirmabläufe für die „erste Passkey-Erstellung“ (d. h. das allererste Mal, dass der Nutzer eine Anmeldeinformation registriert) und die Erstellung auf einem „sekundären Gerät“.

Die Botschaften können sich unterscheiden: z. B. „Sichern Sie dieses neue Gerät mit einem Passkey“ vs. „Richten Sie Ihren ersten Passkey ein.“

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

Manchmal kann die Passkey-Erstellung mitten in der Zeremonie fehlschlagen oder das Betriebssystem des Nutzers ist veraltet. In diesen Szenarien zeichnet Corbado den teilweisen Versuch auf und schlägt elegant mögliche Abhilfemaßnahmen vor (Redirect, manueller Fallback oder geräteübergreifender QR-Flow).

Der Nutzer kann jederzeit versuchen, beim nächsten Anmeldeversuch einen Passkey auf diesem Gerät hinzuzufügen, oder sich auf einen bestehenden Passkey von einem anderen Gerät verlassen.

Die Analysen von Corbado zeigen nicht nur, wie viele Nutzer anfangs einen Passkey erstellt haben, sondern auch, wie viele Passkeys auf mehrere Geräte ausgeweitet haben.

Sie können die Geräteabdeckungsraten verfolgen (z. B. 1 Gerät vs. 2 oder mehr) und sehen, wie dies mit einer reduzierten Fallback-Nutzung oder einem verbesserten Zahlungserfolg korreliert.

Dies hilft Ihrem Team, die Nutzeraufklärung, App-Aufforderungen oder bankbasierte Anmeldeabläufe zu priorisieren, um die Durchdringung von Passkeys auf mehreren Geräten zu erhöhen.

Zusammenfassung: Warum die Abdeckung über mehrere Geräte wichtig ist

Ohne eine konsistente Abdeckung über alle Nutzergeräte hinweg riskieren Sie, dass Nutzer immer dann auf Fallback-Authentifizierungsmethoden zurückgreifen müssen, wenn sie sich auf einem „Nicht-Passkey“-Gerät befinden. Dies unterbricht das reibungslose Erlebnis und hält die Betriebskosten hoch (z. B. SMS-Gebühren, Support-Aufwand). Indem Corbado sekundäre Passkey-Erstellungsbildschirme, hybride Fallback-Heilung und umgebungsgesteuerte Aufforderungen anbietet, stellt es sicher, dass jeder Nutzer schließlich Passkeys auf allen von ihm genutzten Geräten pflegen kann – was zu einer höheren Gesamtdurchdringung führt und diese frustrierenden Fallback-Momente minimiert.

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

In Wirklichkeit ist dies der „einfache“ Teil – ein oder zwei API-Aufrufe, um die grundlegende Zeremonie auszulösen. Die wahre Komplexität und der eigentliche Erfolgsfaktor liegen darin, eine groß angelegte Akzeptanz sicherzustellen und ein vollständiges Ökosystem um diese API-Aufrufe herum aufzubauen.

Im Folgenden sind die wichtigsten Punkte aufgeführt – untermauert durch den Buy vs. Build Passkey Guide –, die verdeutlichen, warum minimale, nur auf die Zeremonie ausgerichtete Implementierungen oft keine realen Ergebnisse liefern.

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

• Wahre Komplexität: Sicherstellen, dass der Passkey-Flow über viele Browser hinweg funktioniert, Fehler elegant behandelt und einen Fallback für ältere Systeme bietet. Sie benötigen auch ein robustes Sitzungsmanagement, Fehlerprotokollierung, Analysen, Strategien zur Geräteabdeckung und mehr.

• Unvorhergesehene Fallstricke: Sobald Sie über eine „Tech-Demo“ von Passkeys hinausgehen, entdecken Sie Grenzfälle wie Cross-Origin-Blockaden, Einschränkungen durch eingebettete WebViews und Komplexitäten bei der Synchronisierung über mehrere Geräte. Dies sind die unbekannten Unbekannten, die naive Eigenentwicklungen zum Scheitern bringen.

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

• Ganzheitlicher Ansatz: Ein erfolgreicher Passkey-Rollout erfordert alles von überzeugenden Nutzeraufforderungen und A/B-getesteten Texten bis hin zu Abdeckungsabläufen für mehrere Geräte, Fallback-Handhabung und kontinuierlichen Analysen – weit über die grundlegenden Zeremonie-Aufrufe hinaus.

• Erkenntnisse aus dem Buy vs. Build Guide: Der Guide betont, dass die Förderung der Passkey-Akzeptanz – nicht nur die Aktivierung von Passkeys – letztendlich den ROI bestimmt. Wenn Nutzer sich nicht anmelden und Passkeys aktiv nutzen, stagniert das Projekt praktisch bei „MFA 2.0“ ohne Verbesserung der Konversionsrate.

• Unvollständige Fallback- & Fehlerbehandlung: Fehlende fortgeschrittene Fallback-Logik oder Echtzeit-Debugging kann zu Nutzersperrungen und höheren Supportkosten führen.

• Fragmentierte Abdeckung über mehrere Geräte: Ohne einen Plan zur Synchronisierung zusätzlicher Geräte oder zur „Heilung“ von Passkey-Lücken greifen Nutzer bei jedem Plattformwechsel auf Passwörter zurück.

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

• Vorgefertigte UI & Best Practices: Anstatt nur Zeremonie-Endpunkte bereitzustellen, bündelt eine richtige Lösung (wie Corbado) White-Label-Bildschirme, Fallback-Flows, Fehlerbehandlung und Abdeckung über mehrere Geräte.

• Adaptive Intelligenz & Protokollierung: Automatisches Erkennen der wahrscheinlichen Anwesenheit eines Passkeys, Anleiten der Nutzer zur Erstellung oder Behebung fehlender Passkeys und Erfassen granularer Ereignisprotokolle.

• Akzeptanzorientierte „unbekannte Unbekannte“: Viele Details – wie E-Mail-basierter Fallback oder der Umgang mit Firmengeräten – werden erst offensichtlich, wenn Nutzer in realen Implementierungen darauf stoßen.

• Tieferer Einblick in die Akzeptanzstrategie: Der Buy vs. Build Passkey Guide zeigt, wie man Kosten, Markteinführungszeit und die versteckten Komplexitäten einer robusten Passkey-Lösung ausbalanciert.

• Reale Benchmarks: Erfahren Sie, wie groß angelegte Rollouts von großen Banken und E-Commerce-Anbietern die unbekannten Unbekannten überwunden haben, die auftreten, nachdem Sie die „einfache“ Zeremonie-Logik programmiert haben.

• Nachhaltiger Erfolg: Die Investition in eine etablierte Plattform mit bewährten Akzeptanzmustern stellt sicher, dass Sie nicht das Rad neu erfinden müssen – und dabei kostspielige Überraschungen erleben.

Zusammenfassend

Die reine Verdrahtung der WebAuthn-Zeremonie reicht nicht aus, um eine sinnvolle Passkey-Akzeptanz zu erreichen. Wahrer Erfolg hängt von der Orchestrierung von End-to-End-Flows ab – wie Fallbacks, Analysen, Erweiterungen für mehrere Geräte und A/B-getestete Nutzerreisen. Indem Sie die nuancierten Komplexitäten jenseits der „reinen Zeremonie“ angehen, können Sie Ihr Passkey-Projekt von einer technischen Kuriosität in eine wirklich reibungslose, weit verbreitete und kostensparende Authentifizierungslösung verwandeln.

Zusätzlich zu den Komplexitäten rund um Cross-Origin-Flows, Nutzerakzeptanz und Passkey-Lebenszyklusmanagement sind Hosting- und Bereitstellungsüberlegungen für jede groß angelegte Passkey-Lösung von entscheidender Bedeutung. Zahlungsanbieter haben oft mit strengen Compliance-, Datenresidenz- und Ausfallsicherheitsanforderungen zu tun, die je nach Region erheblich variieren können. Im Folgenden wird beschrieben, wie Corbado (oder ähnlich robuste Lösungen) diese Bedenken adressiert:

Um Datenhoheit oder regulatorische Rahmenbedingungen (z. B. DSGVO in Europa, PIPEDA in Kanada oder NIST/HIPAA in den Vereinigten Staaten) einzuhalten, müssen einige Anbieter Daten innerhalb bestimmter geografischer Grenzen halten.

Eine regionsunabhängige Architektur stellt sicher, dass der Passkey-Dienst in jeder gewünschten AWS-Region bereitgestellt werden kann und lokale Compliance-Vorgaben erfüllt, ohne Leistung oder Skalierbarkeit zu opfern.

Diese Flexibilität ist besonders wichtig, wenn Ihre Nutzerbasis mehrere Länder umfasst, von denen jedes unterschiedliche Datenhandhabungsregeln durchsetzt.

Für kritische Zahlungsauthentifizierungsabläufe sind Ausfallzeiten keine Option. Corbado setzt Multi-AZ-Deployments ein und verteilt Schlüsselkomponenten auf mehrere Verfügbarkeitszonen.

Dieses Setup hilft sicherzustellen, dass, wenn eine AZ einen Ausfall oder ein Konnektivitätsproblem erleidet, Ihre Passkey-Infrastruktur in anderen Zonen online bleibt – sodass Nutzer sich weiterhin authentifizieren können.

Das Ergebnis ist ein widerstandsfähigeres System, das strenge SLAs für Finanzdienstleistungen und E-Commerce-Websites erfüllt, bei denen selbst kurze Ausfallzeiten zu erheblichen Umsatzeinbußen führen können.

Einige Zahlungsanbieter bevorzugen einen privaten, dedizierten Cluster – sei es für eine engere Datenisolation, benutzerdefinierte Compliance-Prüfungen oder eine 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.

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

Passkeys müssen mit schwankenden Arbeitslasten umgehen können: Enorme Verkehrsspitzen (z. B. während des Weihnachtsgeschäfts oder bei Ticketverkäufen für Veranstaltungen) können Systeme mit fester Kapazität überfordern.

Ein modernes Passkey-Backend skaliert horizontal in Echtzeit und fügt je nach Nutzungsmuster Recheninstanzen hinzu oder entfernt sie. Dieses Auto-Scaling gewährleistet eine konsistente Leistung ohne manuelle Eingriffe.

Branchenstandards wie PCI-DSS, PSD2 SCA oder ISO 27001 gelten oft für Zahlungsanbieter. Ein robuster Passkey-Anbieter integriert sich typischerweise standardmäßig in bekannte Compliance-Frameworks:

• Verschlüsselung im Ruhezustand und während der Übertragung: Sichern Sie Daten mit starkem TLS und serverseitiger oder clientseitiger Verschlüsselung für gespeicherte Anmeldedaten.

• Protokollierung und Audit-Trails: Detaillierte Protokolle für jede Passkey-Operation, geeignet für Regulierungsbehörden oder bei der Untersuchung von Vorfällen.

• Regelmäßiges Sicherheitspatching: Automatisches Patchen von Betriebssystemen und Containern, um Schwachstellen in Schach zu halten, was in einer fließenden Multi-AZ-Umgebung besonders relevant ist.

Wahre Ausfallsicherheit geht über eine einzelne Region hinaus. Einige Anbieter schreiben eine regionenübergreifende 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 und sicherstellen, dass der Ausfall einer ganzen Region die Authentifizierungsabläufe nicht zum Erliegen bringt.

Zusammenfassung: Multi-AZ und regionsunabhängig

Die Wahl einer Passkey-Lösung, die leicht skaliert, sich geografisch anpasst und sowohl lokalen Ausfällen als auch großflächigen Katastrophen widersteht, ist für moderne Zahlungsanbieter unerlässlich – insbesondere für solche, die in mehreren Ländern oder unter strenger Compliance agieren. Durch die Unterstützung von Multi-AZ-Deployments und regionsunabhängigen Konfigurationen stellt Corbado (oder vergleichbare Lösungen) sicher, dass Zahlungs-Passkey-Dienste sowohl verfügbar als auch konform bleiben, egal wo sich Ihre Nutzer oder Daten befinden.

Passkeys stellen in der Tat die nächste Generation der sicheren, benutzerfreundlichen Authentifizierung dar. Dennoch stehen Zahlungsanbieter vor einzigartigen Herausforderungen, die das traditionelle WebAuthn-Design nicht direkt adressiert. Diese Einschränkungen sind am deutlichsten bei:

1. Safaris Weigerung, die Cross-Origin-Passkey-Erstellung (insbesondere in iFrames) zu erlauben, was entweder einen Redirect-basierten Ansatz oder die Abhängigkeit von zuvor erstellten Passkeys erzwingt.

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

Dennoch bleiben Passkeys für Zahlungsanbieter unerlässlich, die ein Apple Pay-ähnliches Checkout-Erlebnis anbieten möchten: optimiert, sicher und herrlich einfach für Endnutzer. Im Folgenden wird beschrieben, wie diese Herausforderungen angegangen werden können und wie Corbado dabei hilft.

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

• Cross-Origin-Beschränkungen: Safari (und einige ältere Browser) blockieren navigator.credentials.create(), wenn es über einen iFrame eingebettet ist. Das bedeutet, dass Sie in einem vom Händler eingebetteten Flow auf diesen Browsern keine neuen Passkeys nahtlos erstellen können.

• Fehlende SPC-Unterstützung: Apples Weigerung, SPC zu übernehmen, schränkt die Möglichkeit ein, Cross-Origin-Zahlungsbestätigungen zu standardisieren, und zwingt Anbieter, separate Ansätze für Safari im Vergleich zu Chrome/Edge beizubehalten.

• WebView- & Native-App-Einschränkungen: Eingebettete WebViews unterbrechen oft Passkey-Flows und erfordern System-Browser-Sitzungen oder andere spezialisierte Ansätze, um die Ausrichtung auf den Domain-Origin zu verwalten.

• Fragmentierte Geräteabdeckung: Selbst wenn der Nutzer einen Passkey auf einem Gerät oder Browser erstellt, fehlt ihm möglicherweise die Abdeckung auf anderen, was zu einer Fallback-Nutzung führt.

2. Wie können Zahlungsanbieter diese Einschränkungen überwinden, um Drittanbieter-Passkey-Integrationen erfolgreich umzusetzen?

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

  • iFrame für Browser, die Cross-Origin-Passkeys vollständig unterstützen und eine nahtlose eingebettete Benutzeroberfläche bieten.

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

• System-WebView oder Browser-Redirect in nativen Apps:

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

  • Akzeptanzorientiertes Toolkit: Bieten Sie überzeugende Passkey-Erstellungsaufforderungen, Abdeckungsabläufe für mehrere Geräte und „Heilungs“-Schritte für Fallbacks, um die Nutzung hoch zu halten.

  • Erweiterte Analysen & A/B-Tests:

    • Messen Sie kontinuierlich die Erfolgs-/Fallback-Raten von Passkeys, die Umgebungsabdeckung und das Nutzerfeedback, um Ihre Abläufe zu verfeinern.

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

In diesem Leitfaden haben wir hervorgehoben, dass die reine Verdrahtung von navigator.credentials.create() nicht ausreicht. Wahrer Erfolg hängt von einer hohen Passkey-Akzeptanz, einem konsistenten Nutzererlebnis und einer widerstandsfähigen Abdeckung über mehrere Geräte hinweg ab. Genau hier zeichnet sich Corbado aus:

• Einheitliche Unterstützung für iFrame & Redirect: Das SDK von Corbado 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 Nutzers wahrscheinlich einen gültigen Passkey hat – und löst einen reibungslosen „Mit Passkey bezahlen“-Flow aus. Dieser Ansatz entspricht dem One-Tap-Checkout von Apple Pay und fördert die alltägliche Passkey-Nutzung, anstatt sie zu einem selten genutzten MFA-Schritt zu degradieren.

  • Robuste Abdeckung über mehrere Geräte: Corbado bietet spezielle Abläufe für die erstmalige Passkey-Erstellung im Vergleich zu sekundären Passkey-Erweiterungen, sodass jeder Nutzer schnell die Abdeckung für neue Geräte hinzufügen kann, nachdem er sich per Fallback oder geräteübergreifendem QR-Code angemeldet hat.

  • Fokus auf Full-Stack-Akzeptanz: Durch integrierte Analysen, 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-Aufforderungen der Banken bis hin zu den Checkout-Erlebnissen der Händler.

  • Flexibles, konformes Hosting: Die Multi-AZ-, regionsunabhängigen Deployments von Corbado entsprechen den strengen Compliance-Anforderungen der Zahlungsbranche (PCI DSS, PSD2 SCA usw.) und gewährleisten so die Betriebszeit und die Einhaltung der Datenresidenzregeln weltweit.

Obwohl die restriktiven Richtlinien von Apple unvermeidliche Reibung erzeugen, können Zahlungsanbieter dennoch erfolgreich Drittanbieter-Passkeys implementieren, indem sie:

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

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

3. Sich auf robuste Akzeptanzstrategien konzentrieren: Abdeckung über mehrere Geräte, „Heilung“ von Fallbacks, erweiterte Analysen und A/B-Tests.

Corbado vereint all diese Elemente und bietet eine Unternehmens-Passkey-Plattform, die die Passkey-Registrierung, die One-Tap-Nutzung, die analysegesteuerte Optimierung und das 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 bietet.