---
url: 'https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk'
title: 'Passkeys für Zahlungsanbieter: So entwickelt man ein Drittanbieter-SDK'
description: 'Erfahren Sie, wie Sie als Zahlungsanbieter Cross-Origin-Passkeys erstellen. Vergleichen Sie iFrame vs. Redirect, bieten Sie eine User Experience auf Apple Pay-Niveau und nutzen Sie Analysen für eine höhere Akzeptanz.'
lang: 'de'
author: 'Vincent Delitz'
date: '2025-07-15T13:41:26.309Z'
lastModified: '2026-03-27T07:03:06.365Z'
keywords: 'PSP, Zahlungsdienstleister, Passkeys für Zahlungsanbieter, Payment Provider SDK, Passkey Integration, WebAuthn, PSD2, SCA, Cross-Origin Passkeys, Secure Payment Confirmation'
category: 'Passkeys Strategy'
---

# 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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) und Komfort im Vergleich zur
traditionellen Multi-Faktor-Authentifizierung (MFA) erheblich. Kürzlich hat
[PayPal Passkeys als primäre MFA-Lösung eingeführt](https://www.forbes.com/sites/daveywinder/2025/03/01/paypal-security-2fa-codes-to-be-replaced-by-single-step-login/)
und damit einen klaren Trend für [Payment](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/passkeys-for-payment)
agieren hingegen meist in Third-Party-Kontexten, wo ihre Dienste (wie
[Zahlungsformulare](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) – durch
strategische Barrieren blockiert werden, die implizit von Apple ausgehen. Insbesondere
Apples eingeschränkte Unterstützung für [Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn)
Passkey-Erstellung in [Safari](https://www.corbado.com/de/blog/digital-credentials-api) und die fehlende
Unterstützung des [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
Standards stellen ein erhebliches Hindernis dar. Dies erschwert die nahtlose Einführung
der [Passkey-Authentifizierung](https://www.corbado.com/de/blog/passkey-anbieter) 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](https://www.corbado.com/glossary/phishing)-resistente, biometrische Logins in jede
Ebene des [Payment](https://www.corbado.com/passkeys-for-payment)-Stacks. Die folgende Grafik veranschaulicht,
wie jeder Akteur in der Wertschöpfungskette von der
[Passkey-Authentifizierung](https://www.corbado.com/de/blog/passkey-anbieter) 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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/de/glossary/ctap) über Geräte
hinweg. **Chance:** Passkeys bieten eine bessere UX als OTPs oder SMS-Codes und
eliminieren das [Phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/de/blog/digitale-nachweise-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](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen). **Chance:**
[Unternehmen für Zahlungsabwicklung](https://dashdevs.com/blog/best-payment-processing-companies/)
können die Passkey-Verifizierung in ihre APIs integrieren, um Risiken zu minimieren und
biometrische [SCA](https://www.corbado.com/de/blog/psd2-passkeys)-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](https://www.corbado.com/blog/digital-wallet-assurance)-Anbieter wie
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) und [Google Pay](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/de/blog/digital-credentials-api) getrieben werden. Zwei wichtige
Standardisierungsversuche wurden konsequent behindert:

- [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (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](https://www.corbado.com/blog/iframe-passkeys-webauthn)-Nutzung von Passkeys speziell für sichere
Zahlungsautorisierungen zu ermöglichen. [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
standardisiert, wie Zahlungsanbieter User über verschiedene Händler-Websites hinweg
authentifizieren, ohne [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) oder
Benutzererfahrung zu beeinträchtigen. Apple hat jedoch die Unterstützung für
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) in [Safari](https://www.corbado.com/de/blog/digital-credentials-api)
konsequent verweigert. Dies ist wahrscheinlich ein strategischer Schachzug, um
sicherzustellen, dass [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) die bevorzugte und
reibungsloseste Zahlungslösung im eigenen Ökosystem bleibt. Apples Weigerung,
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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](https://www.corbado.com/blog/iframe-passkeys-webauthn) iFrames. Während Safari die
Nutzung bestehender Passkeys zur Authentifizierung (`navigator.credentials.get()`) in
einem Third-Party-[iFrame](https://www.corbado.com/blog/iframe-passkeys-webauthn) 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](https://www.corbado.com/blog/iframe-passkeys-webauthn) und authentifiziert sich mit einem Passkey, der
an die [Relying Party](https://www.corbado.com/glossary/relying-party) ID `pay.provider.com` gebunden ist.

Wichtige Punkte:

- **Cross-Origin**: Da der [iFrame](https://www.corbado.com/blog/iframe-passkeys-webauthn) auf einer anderen
  Domain liegt, müssen Sie Berechtigungsrichtlinien (Permission Policies) für
  [publickey-credentials-get](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get)
  und
  [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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“](https://developer.mozilla.org/en-US/docs/Glossary/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.

![Cross origin iframe](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/embedding_cross_origin_iframe_8b52f6996e.png)

### 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](https://passkeys.eu/device-support)
  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.

![Redirect approach for broader compatibility](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_approach_for_broader_compatibility_701166520a.png)

## 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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) als auch auf
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) betten Zahlungsabläufe oft mittels
WebViews ein, um eine nahtlose User Experience zu gewährleisten. Die Implementierung von
Third-Party-[Passkey-Authentifizierung](https://www.corbado.com/de/blog/passkey-anbieter) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) als auch unter
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Folglich kann die
[native App](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/glossary/phishing) und Diebstahl von Zugangsdaten zu verhindern.

Aus Sicht des Geräts ist die [native App](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys) ab (wie
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) auf
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) oder [Chrome](https://www.corbado.com/de/blog/digital-credentials-api)
Custom Tabs auf [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/native-app-passkeys) auf iOS oder Androids
[WebView](https://www.corbado.com/blog/native-app-passkeys)) 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](https://www.corbado.com/blog/native-app-passkeys)
  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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden), 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](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys)
bezahlen“ innerhalb der BOSS [Native App](https://www.corbado.com/blog/native-app-passkeys). Es zeigt, wie eine
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) System-WebView geöffnet wird, die
ihren Status mit Safari-Cookies teilt, sodass der Passkey-Dialog sofort starten kann.

![ios asweb passkeys e-commerce](https://www.corbado.com/website-assets/ios_asweb_passkeys_e_commerce_34ecd03796.jpeg)

**Android (Chrome Custom Tabs):**

Ähnlich bieten [Chrome](https://www.corbado.com/de/blog/digital-credentials-api) 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:

![android asweb passkeys paypal](https://www.corbado.com/website-assets/android_asweb_passkeys_paypal_5eb366dce2.jpeg)

#### 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](https://www.corbado.com/de/blog/digital-credentials-api) 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.

![Redirect to default browser](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_to_default_browser_48b9e771a3.png)

## 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.

| **Aspekt**                    | **Embedded (iFrame) Ansatz**                                                                                                                                                                                                                                                                                   | **Redirect Ansatz**                                                                                                                                                                                                                                                                                                         |
| :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **User Experience**           | ✅ Sehr nahtlos; User bleiben während des gesamten Checkout-Prozesses auf der Seite des Händlers, was die Markenkonsistenz stärkt.                                                                                                                                                                             | ⚠️ Potenziell störend; User verlassen die Händlerseite oder sehen Pop-ups/neue Tabs, was Reibung erzeugt.                                                                                                                                                                                                                   |
| **Browser Kompatibilität**    | ⚠️ Eingeschränkt, da Apples Safari Cross-Origin Passkey-Erstellung blockiert und ältere Browser Restriktionen haben; teilweise Unterstützung, primär für Authentifizierungs-Flows.                                                                                                                             | ✅ Robust; breite Kompatibilität über alle gängigen Browser hinweg, da es in einem First-Party-Domain-Kontext operiert.                                                                                                                                                                                                     |
| **Native App Support**        | ⚠️ Schlechter Support; bricht in eingebetteten Webviews aufgrund strenger Origin-Richtlinien und Sicherheitsbeschränkungen oft ab.                                                                                                                                                                             | ✅ Starker Support; einfach über System Webviews oder externe Browser zu handhaben, im Einklang mit Plattform-Richtlinien (iOS und Android).                                                                                                                                                                                |
| **Attraktivität für Händler** | ✅ Höher; Händler bevorzugen vollständig eingebettete Erlebnisse, da sie die Kontrolle über UX und Branding behalten.                                                                                                                                                                                          | ⚠️ Mittel; Weiterleitungen können Reibung verursachen und potenziell die Conversion-Raten und Kundenzufriedenheit beeinträchtigen, wenn sie nicht elegant gelöst sind.                                                                                                                                                      |
| **Technische Komplexität**    | ⚠️ Höhere Komplexität; erfordert präzise Konfiguration von Permission Policies und Handling diverser Browser-Eigenheiten, mit Limits in nativen Apps.                                                                                                                                                          | ✅ Geringere Komplexität; einfach zu implementieren dank First-Party-Simplicity, was Integrationsfallen reduziert.                                                                                                                                                                                                          |
| **Passkey Kompatibilität**    | ⚠️ Teilweise; Authentifizierung wird breit unterstützt, aber die Passkey-Registrierung ist aufgrund von Cross-Origin-Limits problematisch.                                                                                                                                                                     | ✅ Vollständig; kompletter Support für Passkey-Registrierung und -Authentifizierung ohne Cross-Origin-Einschränkungen.                                                                                                                                                                                                      |
| **Wartung und Support**       | ⚠️ Höherer Aufwand aufgrund häufiger Browser-Updates und Kompatibilitätsprobleme.                                                                                                                                                                                                                              | ✅ Geringerer Aufwand; einfachere Wartung, weniger Cross-Origin-Kompatibilitätsupdates nötig.                                                                                                                                                                                                                               |
| **Best Practice Beispiel**    | Klarna: Klarna unterstützt Passkeys für den First-Party App-Login, hat sich aber immer extrem auf eingebettete Nutzererlebnisse fokussiert und von System WebViews abgeraten. Aus diesem Grund steht Klarna vor Herausforderungen, ein komplettes Third-Party-Passkey-Erlebnis im Händler-Checkout zu liefern. | PayPal: PayPal hat User schon immer auf die eigene Website geleitet und aufgrund seiner Marktmacht und Historie einen Redirect-Ansatz durchgesetzt. Daher war die Integration von Passkeys in Zahlungsflüsse unkompliziert und schnell machbar, selbst in Third-Party-Kontexten, da System WebViews bereits genutzt wurden. |

### 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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/faq/enable-passkeys-iframe) 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)-Strings reduzieren, um
die Privatsphäre der Nutzer zu schützen. Die Unterscheidung wesentlicher Details – wie
Windows 10 vs. [Windows 11](https://www.corbado.com/blog/passkeys-windows-11), genaue macOS-Versionen oder
CPU-Architekturen – ist allein über den
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) oft schwierig oder
unmöglich.

#### 8.2.2 Inkonsistenter Support für Client Hints

Während [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) Daten mit
hoher Entropie auf eine datenschutzkonforme Weise bereitstellen, werden sie nur von
Chromium-basierten Browsern vollständig unterstützt. Safari und
[Firefox](https://www.corbado.com/de/blog/digital-credentials-api) 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](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox). 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](https://www.corbado.com/de/blog/digital-credentials-api).

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

Native Händler-Apps betten Webinhalte oft in [WKWebView](https://www.corbado.com/blog/native-app-passkeys) (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](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/de/blog/psd2-passkeys), etc.) entscheidend:

- **Header & Content Security**: Implementieren Sie strikte
  [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) 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](https://www.corbado.com/de/blog/digital-credentials-api) und wichtigen mobilen OS-Versionen.

- **Häufige Updates**: Verfolgen Sie Änderungen in W3C WebAuthn-Spezifikationen,
  Richtlinien der [FIDO Alliance](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-adoption-business-case) 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](https://www.corbado.com/de/blog/passkey-erstellung-optimieren), 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](https://www.corbado.com/blog/passkey-adoption-business-case).

#### 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](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/blog/best-passkey-sdks-libraries) 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](https://www.corbado.com/de/blog/revolut-passkeys-analyse)-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](https://www.corbado.com/blog/vicroads-passkeys)-Design:

![Corbado optimized ux passkeys](https://www.corbado.com/website-assets/Corbado_optimized_ux_passkeys_e5deec9ed9.png)

#### 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](https://www.corbado.com/de/blog/revolut-passkeys-analyse)-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](https://www.corbado.com/de/blog/biometrie-payer-awareness)/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](https://www.corbado.com/blog/passkey-login-best-practices) 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](https://www.corbado.com/blog/passkey-adoption-business-case) 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](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen) nutzt – ähnlich wie Apple Pay einen
Zahlungsfluss präsentiert.

![apple pay passkeys checkout](https://www.corbado.com/website-assets/apple_pay_passkeys_checkout_f63fb27017.jpeg)

Bei Corbado haben wir einen
„[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)“-Mechanismus
entwickelt, der automatisch erkennt, wenn die Umgebung eines Users wahrscheinlich einen
gültigen Passkey enthält, was ein echtes
[One-Tap](https://docs.corbado.com/corbado-connect/features/one-tap-login)
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.

![A screenshot of a login page AI-generated content may be incorrect.](bc386dced8be285ec3788060ed5cdb7b.png)

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](https://www.corbado.com/de/blog/biometrie-payer-awareness)/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](https://www.corbado.com/blog/webauthn-user-id-userhandle)). 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](https://www.corbado.com/blog/webauthn-user-id-userhandle) 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](https://docs.corbado.com/corbado-connect/features/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

![process events trigger overview](https://www.corbado.com/website-assets/process_events_trigger_overview_e101d943f1.png)

Jedes Mal, wenn Corbado entscheidet, einen
[One-Tap](https://docs.corbado.com/corbado-connect/features/one-tap-login) 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](https://docs.corbado.com/corbado-connect/features/one-tap-login)-Logik
konsistent.

Corbado stellt sicher, dass, wenn ein Passkey gefunden wird (basierend auf Domain-Cookies,
Local Storage Tokens oder
[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/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

![passkeys funnel analysis](https://www.corbado.com/website-assets/passkeys_funnel_analysis_436af30b87.png)

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).

[Watch on YouTube](https://www.youtube.com/watch?v=wnrXJzvBjsU)

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:

![core kpis passkey guide](https://www.corbado.com/website-assets/core_kpis_passkey_guide_e37543f9f2.png)

- **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?“

![ux strategy passkeys corbado](https://www.corbado.com/website-assets/ux_strategy_passkeys_corbado_9884e5167c.png)

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](https://www.corbado.com/de/blog/sms-kosten), 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](https://www.corbado.com/blog/best-passkey-sdks-libraries) 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. &lt;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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/pipeda) in Kanada oder [NIST](https://www.corbado.com/blog/nist-passkeys)/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](https://www.corbado.com/blog/passkeys-amazon-cognito)-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](https://www.corbado.com/passkeys-for-banking) und
[E-Commerce](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)-DSS,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/de/blog/psd2-passkeys) oder
[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks) 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](https://www.corbado.com/de/blog/passkey-erstellung-optimieren).

- **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](https://www.corbado.com/blog/psd2-passkeys) 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](https://www.corbado.com/de/blog/passkey-tutorial-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.