---
url: 'https://www.corbado.com/de/blog/payment-passkeys-landschaft-ueberblick'
title: 'Die Landschaft der Payment-Passkeys: 4 zentrale Integrationsmodelle'
description: 'Entdecken Sie die 4 zentralen Modelle für Payment-Passkeys. Vergleichen Sie Issuer-, Händler-, Netzwerk- und PSP-zentrierte Architekturen, um die beste Integrationsstrategie zu finden.'
lang: 'de'
author: 'Vincent Delitz'
date: '2025-07-15T13:24:08.460Z'
lastModified: '2026-03-27T07:03:04.104Z'
keywords: 'payment passkey überblick, payment passkey landschaft, payment passkey integrationsmodell, zahlungsauthentifizierungsmodelle'
category: 'Passkeys Strategy'
---

# Die Landschaft der Payment-Passkeys: 4 zentrale Integrationsmodelle

## 1. Einleitung

Die globale [Zahlungslandschaft](https://www.corbado.com/passkeys-for-payment) steht an einem entscheidenden
Wendepunkt. Seit Jahrzehnten kämpft die Branche mit dem inhärenten Spannungsfeld zwischen
[Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) und Nutzerfreundlichkeit – eine
Herausforderung, die im digitalen Card-Not-Present (CNP)-Umfeld besonders spürbar ist. Die
Zunahme von raffiniertem Betrug hat stärkere Authentifizierungsmaßnahmen erforderlich
gemacht, während die Erwartungen der Verbraucher nach immer reibungsloseren
Checkout-Erlebnissen verlangen. Dieser Bericht bietet eine umfassende Analyse dieses sich
entwickelnden Ökosystems, mit einem besonderen Fokus auf die Identifizierung der
strategischen Integrationspunkte für die Passkey-Technologie. Er soll als maßgeblicher
Leitfaden für Technologieanbieter,
[Zahlungsdienstleister](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk),
Finanzinstitute und Händler dienen, die den Übergang in eine passwortlose Zukunft meistern
wollen.

## 2. Zusammenfassung

Die [Zahlungslandschaft](https://www.corbado.com/passkeys-for-payment) befindet sich in einem fundamentalen
Wandel, angetrieben durch die Notwendigkeit stärkerer
[Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) wie der
[Starken Kundenauthentifizierung](https://www.corbado.com/blog/psd2-sca-requirements) (SCA) und der kommerziellen
Nachfrage nach reibungslosen Nutzererlebnissen. [Phishing](https://www.corbado.com/glossary/phishing)-resistente
Passkeys haben sich als Schlüsseltechnologie herauskristallisiert, um dieses Spannungsfeld
aufzulösen. Unsere Analyse zeigt, dass sich die Branche auf vier verschiedene
Architekturmodelle für die Passkey-Integration zubewegt, von denen jedes eine
konkurrierende Vision für die Zukunft der
[Zahlungsauthentifizierung](https://www.corbado.com/passkeys-for-payment) darstellt:

1. **Das Issuer-zentrierte Modell (z. B. über SPC):** Obwohl technisch elegant, wird
   dieses Modell durch einen kritischen Mangel an Browser-Unterstützung, insbesondere von
   Apple, behindert, was es für die nahe Zukunft zu einer unpraktikablen Lösung macht.
2. **Das Händler-zentrierte Modell (Delegated Authentication):** Dieses leistungsstarke
   Modell ermöglicht es großen Händlern, ihre direkten Kundenbeziehungen zu nutzen und die
   Authentifizierung vorzuverlegen, um einen nahtlosen Checkout zu schaffen. Es ist jedoch
   mit erheblicher Haftung verbunden und erfordert direktes Vertrauen des Issuers.
3. **Das Netzwerk-zentrierte Modell (Click to Pay):** Ein wichtiger strategischer
   Schachzug von Kartennetzwerken wie [Visa](https://www.corbado.com/blog/visa-passkeys) und
   [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), um das Gast-Checkout-Erlebnis zu dominieren,
   indem sie einen portablen Passkey auf Netzwerkebene für Verbraucher anbieten.
4. **Das PSP-zentrierte Modell (Wallets):** Ein dominantes Modell, bei dem große Payment
   Service Provider wie [PayPal Passkeys](https://www.corbado.com/blog/paypal-passkeys) verwenden, um das
   Erlebnis innerhalb ihrer riesigen, etablierten
   [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)-Ökosysteme zu sichern und zu optimieren.

Jedes Modell bietet eine andere Antwort auf die zentrale strategische Frage: „Wer wird die
primäre [Relying Party](https://www.corbado.com/glossary/relying-party) für
[Zahlungen](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen)?“ Dieser Bericht analysiert diese
konkurrierenden Architekturen und ordnet sie den Akteuren des Ökosystems zu, um eine klare
Roadmap für die Navigation in der Zukunft der
[Zahlungsauthentifizierung](https://www.corbado.com/passkeys-for-payment) zu bieten.

## 3. Das moderne Zahlungsökosystem

Um zu verstehen, wo und wie Passkeys integriert werden können, ist es zunächst
unerlässlich, eine klare und detaillierte Karte der Akteure des Zahlungsökosystems und
ihrer unterschiedlichen Rollen zu erstellen. Der Ablauf einer einzigen Online-Transaktion
beinhaltet ein komplexes Zusammenspiel mehrerer Entitäten, von denen jede eine spezifische
Funktion bei der Übertragung von Daten und Geldern erfüllt.

### 3.1 Die Kernbeteiligten

Im Zentrum jeder Transaktion stehen fünf grundlegende Teilnehmer, die das Fundament der
Zahlungswertschöpfungskette bilden.

1. **Kunde / Karteninhaber:**
    - **Beschreibung**: Die Person oder Organisation, die einen Kauf initiiert. Der
      Karteninhaber erhält eine Zahlungskarte (Kredit- oder Debitkarte) von einer
      ausstellenden Bank und ist für die Rückzahlung aller anfallenden Gebühren
      verantwortlich.
    - **Ziel**: Schnelles, einfaches und sicheres Checkout-Erlebnis.
    - **Beispiele**: Jede Person mit einem Bankkonto und/oder einer Zahlungskarte.

2. **Händler:**
    - **Beschreibung**: Das Unternehmen, das Waren oder Dienstleistungen verkauft und
      elektronische [Zahlungen](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen) akzeptiert. Dazu
      muss der Händler über die notwendige
      [Infrastruktur](https://www.corbado.com/passkeys-for-critical-infrastructure) verfügen, die typischerweise
      von einer Acquiring-Bank oder einem
      [Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (PSP)
      bereitgestellt wird, um Kartenzahlungen zu akzeptieren und zu verarbeiten.
    - **Ziel**: Maximierung der Verkaufskonversion durch Minimierung der Reibung beim
      Checkout bei gleichzeitiger Betrugsbekämpfung.
    - **Beispiele**: Eine [E-Commerce](https://www.corbado.com/passkeys-for-e-commerce)-Website, ein
      [Einzelhandelsgeschäft](https://www.corbado.com/passkeys-for-e-commerce), ein Abonnementdienst.

3. **Ausstellende Bank (Issuer):**
    - **Beschreibung**: Die Bank oder das Finanzinstitut des Karteninhabers. Der
      [Issuer](https://www.corbado.com/glossary/issuer) stellt dem Kunden die Zahlungskarte zur Verfügung,
      übernimmt das damit verbundene Kreditrisiko und ist letztendlich dafür
      verantwortlich, eine Transaktion auf der Grundlage des Kontostatus des
      Karteninhabers und einer Risikobewertung zu genehmigen oder abzulehnen.
    - **Ziel**: Empfang der Autorisierungsanfrage und Rücksendung eines Antwortcodes über
      die Kartennetzwerke.
    - **Beispiele**: Bank of America, Chase, Barclays.

4. **Acquiring-Bank (Acquirer):**
    - **Beschreibung**: Die Bank des Händlers, auch als Händlerbank bekannt. Der
      [Acquirer](https://www.corbado.com/glossary/acquirer) führt das Konto des Händlers und erleichtert die
      Abwicklung von Kartentransaktionen im Namen des Händlers.
    - **Ziel**: Empfang der Zahlungsdetails vom Händler, Weiterleitung über das
      Kartennetzwerk an den [Issuer](https://www.corbado.com/glossary/issuer) und, nach Genehmigung, Verrechnung
      der Gelder auf dem Händlerkonto.
    - **Beispiele**: Wells Fargo [Merchant](https://www.corbado.com/glossary/merchant) Services, Worldpay (von
      FIS).

5. **Kartennetzwerke (Schemes):**
    - **Beschreibung**: Das technologische Rückgrat, das alle anderen Teilnehmer
      verbindet. Unternehmen wie [Visa](https://www.corbado.com/blog/visa-passkeys),
      [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), American Express und Discover betreiben
      diese riesigen Netzwerke. Sie geben keine Karten aus oder eröffnen Händlerkonten,
      sondern stellen die kritische Infrastruktur, Regeln und Standards bereit, die
      Transaktionen regeln.
    - **Ziel**: Erleichterung der Weiterleitung von Autorisierungsanfragen sowie der
      Verrechnung und Abwicklung von Geldern zwischen Issuern und Acquirern.
    - **Beispiele**: [Visa](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys),
      American Express.

### 3.2 Die Vermittler: Eine Klärung der „Provider“-Landschaft

Zwischen den Kernbeteiligten liegt ein komplexes und oft überlappendes Ökosystem von
Technologie- und Dienstleistern. Das Verständnis der Unterschiede zwischen diesen
Vermittlern ist entscheidend, da sie oft die primären Integrationspunkte für neue
Technologien wie Passkeys sind. Die
[Grenzen zwischen diesen Rollen sind in den letzten Jahren erheblich verschwommen](https://blog.finexer.com/payment-gateway-vs-psp-vs-payment-processor/),
da moderne Anbieter versuchen, umfassendere „All-in-One“-Lösungen anzubieten.

1. **Payment Gateway:**
    - **Beschreibung**: Ein [Payment](https://www.corbado.com/passkeys-for-payment) Gateway ist die Technologie,
      die als sicheres digitales Portal für eine Transaktion fungiert. Seine Hauptaufgabe
      besteht darin, die sensiblen Zahlungsdaten des Kunden von der Website oder dem
      Point-of-Sale (POS)-System des Händlers zu erfassen, sie zu verschlüsseln und sicher
      an den Zahlungsabwickler oder die Acquiring-Bank zu übermitteln. Es ist die
      „Eingangstür“ der Transaktion, verantwortlich für die sichere Übertragung von Daten,
      aber nicht für die Bewegung der Gelder selbst.
    - **Ziel**: Händlern eine sichere und zuverlässige Möglichkeit zu bieten,
      Online-[Zahlungen](https://www.corbado.com/de/blog/digitale-nachweise-zahlungen) zu akzeptieren.
    - **Beispiele**: Authorize[.net](https://www.corbado.com/blog/passkeys-asp-net-core) (eine Visa-Lösung),
      Braintree, Stripe [Payment](https://www.corbado.com/passkeys-for-payment) Gateway.

2. **Payment Processor:**
    - **Beschreibung**: Ein [Payment](https://www.corbado.com/passkeys-for-payment) Processor ist die Entität,
      die die Transaktionsnachrichten zwischen den verschiedenen Parteien ausführt. Nach
      Erhalt der sicheren Daten vom Payment Gateway kommuniziert der Processor mit dem
      Kartennetzwerk und damit mit den ausstellenden und akquirierenden Banken, um die
      Autorisierung und Abwicklung der Transaktion zu erleichtern. Man kann sich den
      Processor als den operativen Motor vorstellen, der die für die Zahlung erforderliche
      technische Kommunikation abwickelt, während das Gateway der sichere Kanal für diese
      Kommunikation ist.
    - **Ziel**: Zuverlässige und effiziente Ausführung von Zahlungsnachrichten, Verwaltung
      der Transaktionsabwicklung und Bearbeitung von Streitfällen zwischen ausstellenden
      und akquirierenden Banken.
    - **Beispiele**: First Data (jetzt Fiserv), TSYS, Worldpay.

3. **Payment Service Provider (PSP):**
    - **Beschreibung**: Ein
      [Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) ist ein
      Unternehmen, das Händlern eine umfassende, gebündelte Lösung zur Annahme
      elektronischer Zahlungen anbietet. Ein moderner
      [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) kombiniert typischerweise die
      Funktionen eines Payment Gateways und eines Payment Processors und stellt oft auch
      das Händlerkonto zur Verfügung, alles unter einem einzigen Vertrag. Dieses
      „All-in-One“-Modell vereinfacht den Prozess für Händler erheblich, die keine
      separaten Beziehungen mehr zu einem Gateway-Anbieter und einer Acquiring-Bank
      aufbauen müssen. In einigen Kontexten werden PSPs, die verschiedene Zahlungsmethoden
      für Händler aggregieren, auch als **Payment Aggregators** bezeichnet.
    - **Ziel**: Händlern eine Komplettlösung für all ihre Zahlungsbedürfnisse zu bieten,
      die Komplexität abstrahiert und die Zahlungsakzeptanz vereinfacht.
    - **Beispiele**: Stripe, Adyen, [PayPal](https://www.corbado.com/blog/paypal-passkeys), Mollie.

4. **Account-to-Account (A2A) / Open Banking Provider:**
    - **Beschreibung**: Dies ist eine schnell wachsende Kategorie von Zahlungsanbietern,
      die traditionelle Kartennetzwerke vollständig umgeht. A2A-Zahlungen bewegen Gelder
      direkt vom Bankkonto eines Verbrauchers auf das Bankkonto eines Händlers. Dies wird
      oft durch „Open [Banking](https://www.corbado.com/de/blog/revolut-passkeys-analyse)“-Vorschriften (wie
      [PSD2](https://www.corbado.com/blog/psd2-passkeys) in Europa) ermöglicht, die vorschreiben, dass Banken
      lizenzierten Drittanbietern sicheren API-Zugang zu Kundendaten und
      Zahlungsinitiierungsdiensten gewähren müssen. Diese Anbieter bauen
      benutzerfreundliche Schnittstellen auf diesen APIs auf, die es den Verbrauchern
      ermöglichen, sich bei ihrer Bank zu authentifizieren und eine Zahlung in einem
      nahtlosen Ablauf zu genehmigen.
    - **Ziel**: Eine kostengünstigere, hochsichere Alternative zu Kartenzahlungen
      anzubieten, indem Interbankenentgelte eliminiert und Betrug durch Authentifizierung
      auf Bankebene reduziert werden.
    - **Beispiele**: Trustly, Plaid, Tink, GoCardless, Fintecture.

Diese Konsolidierung der Rollen hat tiefgreifende Auswirkungen. Obwohl akademisch
getrennt, ist in der Praxis der einzige Ansprechpartner eines Händlers oft ein
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk), der die Komplexität der zugrunde
liegenden Gateway-, Processor- und [Acquirer](https://www.corbado.com/glossary/acquirer)-Beziehungen abstrahiert.
Die Fähigkeiten dieser PSPs können jedoch dramatisch variieren. Ein
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk), der lediglich ein Wiederverkäufer
der Gateway-Dienste eines anderen Unternehmens ist, hat völlig andere technische
Fähigkeiten und strategische Interessen als ein Full-Stack-PSP mit eigener
Verarbeitungs-[Infrastruktur](https://www.corbado.com/passkeys-for-critical-infrastructure) und
Acquiring-Lizenzen. Diese Unterscheidung ist wichtig bei der Bewertung von
Integrationsmöglichkeiten für fortgeschrittene Authentifizierungsmethoden.

### 3.3 Rolle der Relying Party (RP)

Darüber hinaus offenbart eine tiefere Analyse des Zahlungsflusses ein grundlegendes
Konzept, das die strategischen Motivationen hinter neuen Authentifizierungstechnologien
verdeutlicht: die Rolle der **Relying Party (RP)**. Im Kontext der
[FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc)-Authentifizierung und Passkeys ist die
[Relying Party](https://www.corbado.com/glossary/relying-party) die Entität, die letztendlich für die Überprüfung
der [Identität](https://www.corbado.com/de/blog/digital-credentials-api) eines Benutzers verantwortlich ist. Bei
einer Standard-Zahlungstransaktion trägt der [Issuer](https://www.corbado.com/glossary/issuer) das finanzielle
Betrugsrisiko und ist daher die standardmäßige [Relying Party](https://www.corbado.com/glossary/relying-party);
es ist seine Entscheidung, die Zahlung zu genehmigen oder abzulehnen.

Die aufkommenden Architekturmodelle für die Passkey-Integration lassen sich am besten als
strategische Verhandlung darüber verstehen, wer als Relying Party agiert. Im
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC)-Modell bleibt der
Issuer die RP, erlaubt dem Händler aber, die Authentifizierungszeremonie _aufzurufen_. Bei
der [Delegated Authentication](https://www.corbado.com/blog/delegated-sca-psd3-passkeys) (DA) _delegiert_ der
Issuer die RP-Funktion explizit an den Händler oder dessen PSP. Und im netzwerkzentrierten
Modell positionieren sich Visa und Mastercard _selbst_ als föderierte Relying Party für
Gast-Checkout-Transaktionen. Daher lautet die zentrale Frage für jeden Zahlungsanbieter,
der eine Passkey-Integration in Betracht zieht:

> „Wer ist oder will die Relying Party in diesem Ablauf sein?“

Die Antwort verweist direkt auf die Integrationsmöglichkeit, den wichtigsten
Entscheidungsträger und das zugrunde liegende strategische Ziel.

> **Deep Dive:** Für eine detaillierte Einführung in Relying Parties im Kontext von
> WebAuthn & Passkeys lesen Sie unseren vollständigen Leitfaden: WebAuthn Relying Party ID
> (rpID) & Passkeys: Domains & Native Apps.

### 3.4 Visualisierung des Ökosystems: Daten- und Wertefluss

Um eine klare visuelle Darstellung dieser Beziehungen zu bieten, ist ein Flussdiagramm,
das den Lebenszyklus einer Zahlung illustriert, unerlässlich. Ein solches Diagramm würde
zwei getrennte, aber miteinander verbundene Pfade darstellen:

1. **Der Datenfluss (Autorisierung):** Dieser Pfad verfolgt den Weg der
   Autorisierungsanfrage. Er beginnt damit, dass der Kunde Zahlungsdetails auf der Website
   des Händlers eingibt, fließt durch das Payment Gateway zum
   Processor/[Acquirer](https://www.corbado.com/glossary/acquirer), dann über das Kartennetzwerk zum Issuer für
   eine Risikoentscheidung, und schließlich gelangt die Genehmigungs- oder
   Ablehnungsantwort den ganzen Weg zurück zum Händler und Kunden. Dieser gesamte Prozess
   findet in Sekundenschnelle statt.

2. **Der Wertefluss (Settlement):** Dieser Pfad illustriert die Bewegung des Geldes, die
   nach der Autorisierung stattfindet. Er zeigt, wie die gebündelten Transaktionen
   verrechnet werden, wobei die Gelder vom Issuer über das Netzwerk zum Acquirer fließen
   (abzüglich der Interbankenentgelte) und schließlich auf das Konto des Händlers
   eingezahlt werden, ein Prozess, der typischerweise einige Werktage dauert.
   ([Payment processing: How payment processing works | Stripe](https://stripe.com/resources/more/payment-processing-explained))

Diese Visualisierung ermöglicht es jedem Teilnehmer im Ökosystem, seine Position sofort zu
lokalisieren und seine direkten und indirekten Beziehungen zu allen anderen Parteien zu
verstehen, was die Grundlage für eine detaillierte Analyse schafft, wo
Authentifizierungsinterventionen stattfinden können.

```mermaid
sequenceDiagram
    participant C as Kunde
    participant M as Händler
    participant P as Gateway/Acquirer
    participant N as Kartennetzwerk
    participant I as Issuer

    C->>M: 1. Zahlungsdetails übermitteln
    M->>P: 2. Details sicher übertragen
    P->>N: 3. Autorisierungsanfrage
    N->>I: 4. Weiterleitung an Issuer zur Überprüfung
    I-->>N: 5. Genehmigungs-/Ablehnungsantwort
    N-->>P: 6. Antwort weiterleiten
    P-->>M: 7. Antwort weiterleiten
    M-->>C: 8. Bestellung bestätigen oder neue Zahlung anfordern

    M->>P: 9. Stapel genehmigter Transaktionen übermitteln
    P->>N: 10. Clearing-Anfrage
    N->>I: 11. Gelder vom Issuer anfordern
    I-->>N: 12. Gelder überweisen (abzgl. Interbankenentgelte)
    N-->>P: 13. Gutschrift der Gelder an Acquirer
    P-->>M: 14. Einzahlung der Gelder auf Händlerkonto (abzgl. Bearbeitungsgebühren)
```

| Akteur                                                | Kernfunktion                                                                                                                            | Hauptverantwortlichkeiten                                                                                      | Typische Beispiele                                        |
| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| **Kunde / Karteninhaber**                             | Initiiert die Zahlung für Waren oder Dienstleistungen.                                                                                  | Stellt Zahlungsdaten bereit; zahlt Gebühren an den Issuer zurück.                                              | Eine Person, die online einkauft.                         |
| **Händler**                                           | Verkauft Waren oder Dienstleistungen und akzeptiert elektronische Zahlungen.                                                            | Integriert Technologie zur Zahlungsakzeptanz; verwaltet das Checkout-Erlebnis.                                 | Eine E-Commerce-Website oder ein Einzelhandelsgeschäft.   |
| **Ausstellende Bank (Issuer)**                        | Gibt Zahlungskarten an Kunden aus und übernimmt das Risiko.                                                                             | Genehmigt oder lehnt Transaktionen ab; verwaltet Karteninhaberkonten; stellt dem Karteninhaber Rechnungen aus. | Bank of America, Chase, Barclays.                         |
| **Acquiring-Bank (Acquirer)**                         | Ermöglicht Händlern die Annahme von Kartenzahlungen.                                                                                    | Eröffnet und pflegt Händlerkonten; rechnet Gelder mit dem Händler ab.                                          | Wells Fargo Merchant Services, Worldpay (von FIS).        |
| **Kartennetzwerke (Schemes):**                        | Betreibt die Netzwerke, die alle Parteien verbinden.                                                                                    | Legt Interbankenentgelte und Regeln fest; leitet Autorisierungs- und Abwicklungsnachrichten weiter.            | Visa, Mastercard, American Express.                       |
| **Payment Gateway**                                   | Überträgt Zahlungsdaten sicher vom Händler zum Processor.                                                                               | Verschlüsselt sensible Kartendaten; fungiert als sichere „Eingangstür“ für die Transaktion.                    | Authorize.net (eine Visa-Lösung), Stripe Payment Gateway. |
| **Payment Processor**                                 | Verwaltet die technische Kommunikation für die Transaktion.                                                                             | Erleichtert den Informationsaustausch zwischen Acquirer, Issuer und Kartennetzwerk.                            | First Data (jetzt Fiserv), TSYS.                          |
| **Payment Service Provider (PSP)**                    | Bietet Händlern eine umfassende All-in-One-Zahlungslösung.                                                                              | Bündelt Gateway-, Verarbeitungs- und Händlerkontodienste; vereinfacht die Zahlungsakzeptanz.                   | Stripe, Adyen, PayPal, Mollie.                            |
| **Account-to-Account (A2A) / Open Banking Provider:** | Umgeht traditionelle Kartennetzwerke, um Gelder direkt vom Bankkonto eines Verbrauchers auf das Bankkonto eines Händlers zu überweisen. | Bietet sicheren API-Zugang zu Kundendaten und Zahlungsinitiierungsdiensten für lizenzierte Drittanbieter.      | Trustly, Plaid, Tink, GoCardless, Fintecture.             |

### 3.5 Regionale Marktführer

Obwohl das Zahlungsökosystem Akteure aller Größen umfasst, konzentriert sich der Markt für
Processing und Acquiring auf mehrere große Player, die je nach Region variieren. Globale
Giganten konkurrieren oft mit starken nationalen und regionalen Champions. Die folgende
Tabelle gibt einen Überblick über wichtige Akteure in verschiedenen geografischen
Regionen.

| Region            | Entität                                                                                                | Typ                |
| ----------------- | ------------------------------------------------------------------------------------------------------ | ------------------ |
| **Nordamerika**   | PayPal, Stripe, Block (Square), Adyen, Bill, Brex, Ria Money Transfer                                  | PSP                |
| **Nordamerika**   | Fiserv (Clover), Global Payments, JPMorgan Chase Merchant Services                                     | Acquirer/Processor |
| **Nordamerika**   | Plaid                                                                                                  | A2A/Open Banking   |
| **Europa**        | Adyen, Stripe, PayPal, Checkout.com, Worldline, Nexi, Klarna, Mollie, Wise                             | PSP                |
| **Europa**        | Worldpay (von FIS), Barclaycard                                                                        | Acquirer/Processor |
| **Europa**        | Trustly, Brite Payments, Tink, GoCardless, Fintecture, Ivy                                             | A2A/Open Banking   |
| **Europa**        | iDEAL (Niederlande), Bancontact (Belgien), Swish (Schweden)                                            | Nationales Scheme  |
| **Asien-Pazifik** | Alipay & WeChat Pay (China), PhonePe & Paytm (Indien), GrabPay & GoTo (SEA), Razorpay, PayU, Airwallex | PSP                |
| **Asien-Pazifik** | Tyro Payments                                                                                          | Acquirer/Processor |
| **Asien-Pazifik** | UPI (Indien), Australian Payments Plus (AP+)                                                           | Nationales Scheme  |
| **Lateinamerika** | Mercado Pago, PagSeguro, StoneCo, EBANX                                                                | PSP                |
| **Lateinamerika** | Cielo, Rede, Getnet (Brasilien), Transbank (Chile), Prisma (Argentinien)                               | Acquirer/Processor |
| **Lateinamerika** | Pix (Brasilien)                                                                                        | Nationales Scheme  |

## 4. Anatomie einer Card-Not-Present (CNP)-Transaktion und der 3-D Secure-Überbau

Jeder Online-Kauf löst eine komplexe, blitzschnelle Abfolge von Ereignissen aus, die in
zwei Hauptphasen unterteilt werden kann: Autorisierung und Settlement. Über diesen Prozess
legt sich ein kritisches Sicherheitsprotokoll namens [3-D Secure](https://www.corbado.com/glossary/3d-secure),
das für das Verständnis der modernen Herausforderungen bei der
Online-Zahlungsauthentifizierung von zentraler Bedeutung ist.

### 4.1 Der Transaktionslebenszyklus: Von „Bezahlen“ zu „Bezahlt“

Der Lebenszyklus einer einzelnen [CNP](https://www.corbado.com/glossary/cnp)-Transaktion umfasst einen nahezu
sofortigen Datenaustausch, gefolgt von einer langsameren Übertragung von Geldern.

#### 4.1.1 Autorisierung

Die Autorisierung ist der Prozess der Überprüfung, ob der Karteninhaber über ausreichende
Mittel oder Kredit verfügt, um den Kauf abzuschließen, und ob die Transaktion legitim ist.
Diese Phase findet in Sekunden statt und folgt einem präzisen, mehrstufigen Pfad
([Payment processing: How payment processing works | Stripe](https://stripe.com/resources/more/payment-processing-explained)):

1. **Transaktionsinitiierung:** Der Kunde wählt seine Artikel aus, geht zur Kasse und gibt
   seine Zahlungskartendaten (Kartennummer, Ablaufdatum, CVV) in das
   Online-Zahlungsformular des Händlers ein.

2. **Sichere Übertragung:** Die Website des Händlers leitet diese Informationen sicher an
   sein Payment Gateway weiter. Das Gateway verschlüsselt die Daten, um sie während der
   Übertragung zu schützen.

3. **Weiterleitung an Processor/Acquirer:** Das Gateway leitet die verschlüsselten
   Transaktionsdetails an den Payment Processor und/oder die Acquiring-Bank des Händlers
   weiter.

4. **Netzwerkkommunikation:** Der Acquirer sendet die Autorisierungsanfrage an das
   entsprechende Kartennetzwerk (z. B. Visa, Mastercard).

5. **Issuer-Überprüfung:** Das Kartennetzwerk leitet die Anfrage an die ausstellende Bank
   des Karteninhabers weiter. Die Systeme des Issuers führen eine Reihe von Prüfungen
   durch: Überprüfung der Gültigkeit der Karte, Prüfung des verfügbaren Guthabens oder
   Kreditlimits und Durchführung der Transaktion durch seine Betrugserkennungs-Engines.

6. **Autorisierungsantwort:** Basierend auf diesen Prüfungen genehmigt oder lehnt der
   Issuer die Transaktion ab. Diese Entscheidung in Form eines Antwortcodes wird auf
   demselben Weg zurückgesendet: vom Issuer zum Kartennetzwerk, zum Acquirer, zum
   Processor/Gateway und schließlich zur Website des Händlers.

7. **Abschluss:** Bei Genehmigung schließt der Händler den Verkauf ab und informiert den
   Kunden. Bei Ablehnung bittet der Händler den Kunden um eine alternative
   Zahlungsmethode.

#### 4.1.2 Settlement

Settlement ist der Prozess der tatsächlichen Geldbewegung vom Issuer zum Händler. Im
Gegensatz zur Autorisierung ist dies nicht sofort und erfolgt typischerweise in Stapeln.
([Payment processing: How payment processing works | Stripe](https://stripe.com/resources/more/payment-processing-explained))

1. **Stapelverarbeitung:** Am Ende des Geschäftstages sendet der Händler eine Stapeldatei
   all seiner genehmigten Autorisierungen an seinen Acquirer.
2. **Clearing:** Der Acquirer reicht den Stapel zur Verrechnung beim Kartennetzwerk ein.
   Das Netzwerk sortiert die Transaktionen und leitet sie an die jeweiligen ausstellenden
   Banken weiter.
3. **Geldtransfer:** Die ausstellenden Banken überweisen die Gelder für die genehmigten
   Transaktionen an die Acquiring-Bank, abzüglich der Interbankenentgelte, die der
   Acquirer für jede Transaktion an den Issuer zahlt.
4. **Händlereinzahlung:** Der Acquirer zahlt dann die Gelder auf das Konto des Händlers
   ein, abzüglich seiner eigenen Bearbeitungsgebühren. Dieser gesamte Abwicklungsprozess
   dauert in der Regel 1-3 Werktage.

### 4.2 Die Sicherheitsebene: EMV 3-D Secure (3DS)

Über jeder [CNP](https://www.corbado.com/glossary/cnp)-Transaktion liegt ein kritisches Sicherheitsprotokoll
namens **3-D Secure (3DS)**. Verwaltet von EMVCo, besteht sein Zweck darin, dem Issuer die
Authentifizierung des Karteninhabers zu ermöglichen, Betrug zu reduzieren und die Haftung
für Rückbuchungen vom Händler auf den Issuer zu verlagern.

Modernes 3DS (auch 3DS2 genannt) funktioniert durch den Austausch eines reichhaltigen
Datensatzes zwischen dem Händler und dem **Access Control Server (ACS)** des Issuers.
Diese Daten ermöglichen es dem [ACS](https://www.corbado.com/glossary/acs), eine Risikobewertung durchzuführen,
die zu zwei Ergebnissen führt:

- **Frictionless Flow:** Wenn die Transaktion als risikoarm eingestuft wird, wird sie im
  Hintergrund ohne Benutzerinteraktion stillschweigend genehmigt. Dies ist das Ziel für
  die meisten Transaktionen.
- **Challenge Flow:** Wenn die Transaktion risikoreich ist oder durch Vorschriften wie
  [PSD2](https://www.corbado.com/blog/psd2-passkeys) vorgeschrieben ist, wird der Benutzer aktiv aufgefordert,
  seine [Identität](https://www.corbado.com/de/blog/digital-credentials-api) nachzuweisen, typischerweise mit
  einem OTP oder einer Benachrichtigung in der
  [Banking](https://www.corbado.com/de/blog/revolut-passkeys-analyse)-App.

Diese „Challenge“ ist ein großer Reibungspunkt und ein entscheidendes Schlachtfeld für
[Conversion Rates](https://www.corbado.com/blog/logins-impact-checkout-conversion). Das Ziel der Branche ist es,
reibungslose Abläufe zu maximieren und Challenges so nahtlos wie möglich zu gestalten.
Genau diese reibungsintensive Challenge können Passkeys perfekt lösen und einen
potenziellen Fehlerpunkt in einen sicheren und nahtlosen Schritt verwandeln.

> **Deep Dive:** Für eine detaillierte Analyse des 3DS-Protokolls, der Rolle des
> [ACS](https://www.corbado.com/glossary/acs) und wie Anbieter
> [FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc)-Daten integrieren, lesen Sie unseren
> vollständigen Leitfaden:
> [EMV 3DS Access Control Server](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc): Passkeys,
> [FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc) und
> [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc).

```mermaid
graph TD
    A[Start: Kunde geht zur Kasse] --> B{Händler initiiert 3DS-Prüfung};
    B --> C[SDK des Händlers sendet umfangreiche Transaktions- und Gerätedaten an den ACS des Issuers];
    C --> D{ACS Risk Engine analysiert Daten};
    D --> E{Ist die Transaktion risikoreich oder ist SCA vorgeschrieben?};
    subgraph Frictionless Flow
    E -- Nein --> F[Authentifizierung passiv genehmigt - Keine Benutzerinteraktion];
    end
    subgraph Challenge Flow
    E -- Ja --> G[Benutzer wird zur Authentifizierungs-Challenge aufgefordert];
    G --> H{Benutzer schließt Challenge ab? - z.B. OTP, App-Push, SPC/Passkey};
    H -- Ja --> I[Authentifizierung genehmigt];
    H -- Nein --> J[Authentifizierung fehlgeschlagen];
    end
    F --> K[Transaktion wird mit Haftungsübertragung auf den Issuer fortgesetzt];
    I --> K;
    J --> L[Transaktion wird blockiert];
```

## 5. Die Passkey-Revolution im Zahlungsverkehr: Zentrale Integrationsarchitekturen

Das Aufkommen von Passkeys, basierend auf dem [Phishing](https://www.corbado.com/glossary/phishing)-resistenten
WebAuthn-Standard der [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance), katalysiert eine
grundlegende Neugestaltung der Zahlungsauthentifizierung. Dies geschieht parallel zu einem
starken Branchentrend: Händler setzen bereits Passkeys für die
Standard-Benutzerauthentifizierung (Anmeldung und Login) ein, um Account Takeover Fraud zu
bekämpfen und das Benutzererlebnis zu verbessern. Diese bestehende Investition schafft
eine natürliche Grundlage, auf der zahlungsspezifische Passkey-Modelle aufgebaut werden
können.

### 5.1 Das Issuer-zentrierte Modell

In diesem Modell ist die Bank des Benutzers (der Issuer) die ultimative Relying Party (RP)
für die Authentifizierung. Der Passkey ist an die Domain der Bank gebunden (z. B.
`bank.com`), und der Benutzer authentifiziert sich direkt bei seiner Bank, um eine
Transaktion zu genehmigen. Dieses Modell hat zwei Hauptvarianten, je nachdem, ob die
Zahlung über Kartenschienen oder durch direkte Konto-zu-Konto-Überweisungen erfolgt.

#### 5.1.1 Der kartenbasierte Ansatz: Secure Payment Confirmation (SPC)

In diesem Modell behält die ausstellende Bank die Kontrolle über die Authentifizierung,
und der Passkey ist kryptografisch an die Domain des Issuers gebunden (z. B. `bank.com`).
Eine einfache Weiterleitung zur Website der Bank ist zwar möglich, schafft aber ein
schlechtes Benutzererlebnis.

**Wem gehört der Passkey?** Im Issuer-zentrierten Modell ist der **Issuer die Relying
Party (RP)**.

**Adoption-Flywheel & Netzwerkeffekte:** Die Wiederverwendbarkeit des Passkeys eines
Issuers erzeugt einen starken Flywheel-Effekt. Sobald ein Benutzer einen Passkey für seine
Bank erstellt, kann dieser eine Passkey nahtlos zur Genehmigung von angefochtenen
Transaktionen bei _jedem_ Händler verwendet werden, der das 3DS-Protokoll nutzt. Dies
erhöht den Wert der Karte des Issuers sowohl für Verbraucher (bessere UX) als auch für
Händler (höhere Konversion).

Die von der Industrie entwickelte Lösung hierfür ist **Secure Payment Confirmation
(SPC)**, ein Webstandard, der es einem Händler ermöglicht, den Passkey der Bank direkt auf
der Checkout-Seite aufzurufen und so eine Weiterleitung zu vermeiden. Dieser Prozess
verwendet auch **Dynamic Linking**, um die Authentifizierung an die Transaktionsdetails zu
binden, was für [SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk)
entscheidend ist.

**Der strategische Fehler:** Trotz seiner technischen Eleganz ist
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) heute keine tragfähige Strategie. Es erfordert
Browser-Unterstützung, die in Apples [Safari](https://www.corbado.com/de/blog/digital-credentials-api) nicht
vorhanden ist. Ohne [Safari](https://www.corbado.com/de/blog/digital-credentials-api) kann
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) keine universelle Lösung sein, was es für jede
groß angelegte Implementierung unpraktikabel macht.

> **Deep Dive:** Für eine vollständige technische Aufschlüsselung von SPC, wie es
> [Dynamic Linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) ermöglicht und warum die
> Browser-Unterstützung ein kritischer Fehler ist, lesen Sie unsere ausführliche Analyse:
> [Dynamic Linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) mit Passkeys:
> [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC).

```mermaid
sequenceDiagram
    participant U as Benutzer
    participant M as Händler-Website
    participant I as Issuer ACS

    Note over M,I: Eine 3DS-Prüfung ergibt, dass eine Challenge erforderlich ist.
    M->>I: Autorisierungsanfrage (Hohes Risiko)
    I-->>M: SPC-Challenge initiieren
    Note over U,M: Browser zeigt dem Benutzer eine native Aufforderung an.
    M->>U: SPC-API für Issuer-Domain auslösen (z.B. bank.com)
    U->>U: Benutzer authentifiziert sich mit Gerätebiometrie (Face ID, etc.)
    U-->>M: Browser erhält signierte Assertion für bank.com
    M->>I: Signierte Assertion zur Validierung weiterleiten
    I-->>M: Authentifizierung erfolgreich
```

#### 5.1.2 Der A2A / Open Banking-Ansatz

Während die vorherigen Modelle auf dem Karten-Ökosystem basieren, stellen
Account-to-Account (A2A)-Zahlungen, angetrieben durch Open
[Banking](https://www.corbado.com/de/blog/revolut-passkeys-analyse), ein starkes und eigenständiges Paradigma
dar. Dieses Modell umgeht die Kartenschienen vollständig, und seine Integration mit
Passkeys ist einzigartig unkompliziert und effektiv.

In diesem Modell authentifiziert sich der Benutzer direkt bei seiner eigenen Bank, um eine
Zahlung zu genehmigen. Die Reibung dieses Prozesses – oft mit einer umständlichen
Weiterleitung und einem Passwort-Login verbunden – war ein Haupthindernis für die
A2A-Akzeptanz. Passkeys lösen dieses Kernproblem direkt.

**Wem gehört der Passkey?** Die **Bank ist die Relying Party (RP)**. Der Passkey ist
derjenige, den der Benutzer bereits für sein alltägliches Online-Banking mit
`meinebank.de` erstellt hat.

**Adoption-Flywheel & Netzwerkeffekte:** Der Flywheel-Effekt ist immens und wird von den
Banken selbst angetrieben. Wenn Banken ihre Benutzer ermutigen, von Passwörtern auf
Passkeys für den Login in ihre primäre Banking-App oder Website umzusteigen, sind diese
Passkeys automatisch bereit, für jede Open-Banking-Zahlung verwendet zu werden. Der
Benutzer muss nichts extra tun. Dies macht den A2A-Zahlungsfluss so einfach wie einen
biometrischen Scan und erhöht seine Attraktivität und Wettbewerbsfähigkeit gegenüber
Karten dramatisch.

**Wie es funktioniert:**

1. An der Kasse wählt der Benutzer einen A2A-Anbieter (z. B. Trustly, Plaid) oder seine
   eigene Bank.
2. Der Benutzer wird aufgefordert, die Zahlung mit seiner Bank zu autorisieren.
3. Die Bank löst als RP eine Passkey-Authentifizierungs-Challenge aus.
4. Der Benutzer authentifiziert sich mit [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Fingerabdruck
   oder PIN.
5. Die Bank bestätigt die Zahlung sicher, und die Gelder werden direkt auf das Konto des
   Händlers überwiesen.

Dieses Modell passt nicht in die anderen vier, da es kein Kartennetzwerk, 3DS, SPC oder
[Delegated Authentication](https://www.corbado.com/blog/delegated-sca-psd3-passkeys) beinhaltet. Es ist ein
bankenzentrierter Fluss, bei dem der A2A-Anbieter als Orchestrierungsschicht zwischen dem
Händler und dem eigenen, jetzt Passkey-fähigen Authentifizierungssystem der Bank fungiert.

```mermaid
sequenceDiagram
    participant U as Benutzer
    participant M as Händler-Website
    participant A2A as A2A-Anbieter (z.B. Trustly)
    participant B as Bank des Benutzers

    U->>M: Wählt "Mit Bank bezahlen"
    M->>A2A: A2A-Zahlung initiieren
    A2A->>U: Benutzer auffordern, seine Bank auszuwählen
    U->>A2A: Wählt Bank aus
    A2A->>B: Zahlungsautorisierung anfordern
    Note over B,U: Bank fordert Benutzer zur Passkey-Authentifizierung auf
    U->>B: Mit Passkey für meinebank.de authentifizieren
    B-->>A2A: Authentifizierung erfolgreich, Zahlung autorisiert
    A2A-->>M: Zahlung bestätigen
    M-->>U: Bestellung bestätigen
```

### 5.2 Das Händler-zentrierte Modell: Delegated Authentication (DA)

[Delegated Authentication](https://www.corbado.com/blog/delegated-sca-psd3-passkeys) stellt eine radikalere
Abkehr vom traditionellen Modell dar. Ermöglicht durch 3DS Version 2.2 und unterstützt
durch spezifische Programme der Kartennetzwerke, ist DA ein Rahmenwerk, bei dem ein Issuer
die Verantwortung für die Durchführung von
[SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk) formell an einen
vertrauenswürdigen Dritten delegieren kann, am häufigsten einen großen Händler, PSP oder
digitalen [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)-Anbieter.

> Für weitere Einblicke in Delegated Authentication und Passkeys lesen Sie bitte unseren
> Blogbeitrag: Delegated Authentication & Passkeys unter [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) /
> [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) - Corbado

**Wem gehört der Passkey?** In diesem Modell ist der **Händler oder sein PSP die Relying
Party (RP)**. Der Passkey wird für die Domain des Händlers erstellt (z. B. `amazon.com`)
und für den Konto-Login verwendet.

Um sich für DA zu qualifizieren, muss die vom Händler durchgeführte Erstauthentifizierung
vollständig den
[SCA](https://www.corbado.com/de/blog/passkeys-fuer-zahlungsanbieter-drittanbieter-sdk)-Anforderungen
entsprechen. Gemäß den Leitlinien der Europäischen
[Bankenaufsichtsbehörde](https://www.corbado.com/passkeys-for-banking) zur
[Starken Kundenauthentifizierung](https://www.corbado.com/blog/psd2-sca-requirements) ist dies nicht nur ein
einfacher Login; er muss die gleiche Stärke haben wie eine Authentifizierung, die der
Issuer selbst durchführen würde. Passkeys sind mit ihren starken kryptografischen
Eigenschaften eine ideale Technologie, um diese hohe Hürde zu erfüllen. Ein entscheidender
Punkt regulatorischer Unsicherheit bleibt jedoch bezüglich **synchronisierter Passkeys**.
Während gerätegebundene Passkeys eindeutig das „Besitz“-Element von SCA erfüllen, haben
Regulierungsbehörden wie die EBA noch keine endgültige Meinung dazu abgegeben, ob
synchronisierte Passkeys, die über das Cloud-Konto eines Benutzers portabel sind, die
strenge Anforderung erfüllen, eindeutig mit einem einzigen Gerät verknüpft zu sein. Dies
ist eine wichtige Überlegung für jede DA-Strategie in Europa.

In diesem Modell bewegt sich das Authentifizierungsereignis in der Customer Journey nach
vorne. Anstatt am Ende des Checkout-Prozesses als 3DS-Challenge stattzufinden, geschieht
es am Anfang, wenn sich der Kunde in sein Konto auf der Website oder App des Händlers
einloggt. Wenn der Händler einen Passkey für den Login verwendet, kann er den Nachweis
dieser erfolgreichen, SCA-konformen Authentifizierung innerhalb des 3DS-Datenaustauschs an
den Issuer übermitteln. Der Issuer, der eine vorab etablierte Vertrauensbeziehung zu
diesem Händler hat, kann diese Informationen dann nutzen, um eine Ausnahme zu gewähren und
seinen eigenen Challenge-Flow vollständig zu umgehen. Dies kann zu einem wirklich
nahtlosen, biometrischen One-Click-Checkout für eingeloggte Benutzer führen.

**Adoption-Flywheel & Netzwerkeffekte:** Der Flywheel-Effekt wird hier durch die direkte
Kundenbeziehung des Händlers angetrieben. Wenn Händler Passkeys für den Login einführen,
um Account Takeover Fraud zu reduzieren und die UX zu verbessern, bauen sie eine Basis von
Passkey-fähigen Benutzern auf. Dies schafft einen natürlichen Weg, diese Passkeys für DA
bei Zahlungen zu nutzen und ein überlegenes Checkout-Erlebnis freizuschalten. Der
Netzwerkeffekt ist am stärksten für PSPs, die als RP für mehrere Händler fungieren können,
was potenziell ermöglicht, dass ein einziger Passkey in einem Netzwerk von Geschäften
verwendet wird und einen starken Anreiz für andere Händler schafft, dem Ökosystem dieses
PSPs beizutreten.

Kartennetzwerke fördern dieses Modell aktiv durch dedizierte Programme.
[Visas Guide Authentication Framework](https://usa.visa.com/products/guide-authentication.html)
ist beispielsweise so konzipiert, dass es mit DA verwendet wird, um Händler zu befähigen,
SCA im Namen des Issuers durchzuführen. In ähnlicher Weise ermöglicht das Identity Check
Express-Programm von Mastercard Händlern,
[den Verbraucher innerhalb des eigenen Flusses des Händlers zu authentifizieren](https://developer.mastercard.com/product/delegated-authentication-for-merchants/).
Dieses Modell spiegelt die strategische Vision großer Händler und PSPs wider:

> „Wir besitzen die primäre Kundenbeziehung und haben bereits in ein sicheres,
> reibungsarmes Login-Erlebnis investiert. Lassen Sie uns die Authentifizierung
> übernehmen, um die bestmögliche User Journey zu schaffen.“

Diese Macht geht jedoch mit Verantwortung einher. Nach europäischen Vorschriften wird DA
als „Outsourcing“ behandelt, was bedeutet, dass der Händler oder PSP die Haftung für
betrügerische Transaktionen übernimmt und strenge Compliance- und
Risikomanagementanforderungen einhalten muss.

```mermaid
sequenceDiagram
    participant U as Benutzer
    participant M as Händler-Website
    participant I as Issuer ACS

    Note over U,M: Schritt 1: Benutzer loggt sich auf der Händlerseite ein.
    U->>M: Authentifizierung mit Passkey für merchant.com
    M-->>U: Login erfolgreich (SCA wurde durchgeführt)

    Note over U,I: Schritt 2: Später, an der Kasse...
    U->>M: Klickt auf "Bezahlen"
    M->>I: Autorisierungsanfrage (inkl. Nachweis der vorherigen SCA)
    I->>I: Überprüft den Nachweis der delegierten Authentifizierung
    I-->>M: Transaktion genehmigen (Keine 3DS-Challenge erforderlich)
```

### 5.3 Das Netzwerk-zentrierte Modell: Click to Pay & Föderierte Passkey-Dienste

Dieses Modell ist eine wichtige strategische Initiative der Kartennetzwerke (Visa,
Mastercard), um das Gast-Checkout-Erlebnis zu dominieren und zu standardisieren. Sie haben
ihre eigenen FIDO-basierten Passkey-Dienste, wie den **Visa Payment Passkey Service**, auf
dem **Click to Pay**-Framework aufgebaut.

**Wem gehört der Passkey?** Im Netzwerk-zentrierten Modell ist das **Kartennetzwerk die
Relying Party**. Der Passkey wird für die Domain des Netzwerks erstellt (z. B.
`visa.com`).

**Adoption-Flywheel & Netzwerkeffekte:** Dieses Modell besitzt den stärksten
Netzwerkeffekt. Ein einziger für ein Kartennetzwerk erstellter Passkey ist sofort bei
jedem Händler wiederverwendbar, der Click to Pay unterstützt, was einen immensen Wert für
den Verbraucher schafft und einen klassischen zweiseitigen Markt-Flywheel antreibt.

> **Deep Dive:** Sowohl Visa als auch Mastercard verfolgen diese Strategie aggressiv.
> Erfahren Sie mehr über die Besonderheiten ihrer Implementierungen in unseren dedizierten
> Artikeln zu [Visa Passkeys](https://www.corbado.com/blog/visa-passkeys) und
> [Mastercard Passkeys](https://www.corbado.com/blog/mastercard-passkeys).

```mermaid
sequenceDiagram
    participant U as Benutzer
    participant M as Händler-Website
    participant N as Kartennetzwerk (Click to Pay)
    participant I as Issuer

    Note over M,U: Gast-Checkout-Fluss
    U->>M: Klickt auf "Click to Pay"-Button
    M->>N: Click to Pay-Fluss initiieren
    Note over N,U: Benutzer wird aufgefordert, sich beim Netzwerk zu authentifizieren.
    N->>U: Browser löst Passkey-Aufforderung für network.com aus
    U->>U: Benutzer authentifiziert sich mit Gerätebiometrie
    U-->>N: Signierte Assertion an Netzwerk zurückgegeben
    N->>N: Validiert Benutzer, ruft gespeicherten Kartentoken ab
    N->>I: Autorisierungsanfrage mit Netzwerk-Token
    I-->>N: Genehmigen/Ablehnen
    N-->>M: Authentifizierungsantwort an Händler senden
```

### 5.4 Das PSP-zentrierte Modell: Wallet-basierte Authentifizierung

Dieses Modell konzentriert sich auf große
[Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (PSPs), die
ihre eigenen kundenorientierten Wallets betreiben, wie **PayPal** oder **Stripe (mit
Link)**. Bei diesem Ansatz ist der **PSP die Relying Party**, und er besitzt den gesamten
Authentifizierungs- und Zahlungsfluss.

**Wem gehört der Passkey?** Im PSP-zentrierten Modell ist der **PSP die Relying Party
(RP)**. Der Passkey wird für die Domain des PSPs erstellt (z. B. `paypal.com`) und sichert
das Konto des Benutzers innerhalb des Ökosystems dieses PSPs.

**Adoption-Flywheel & Netzwerkeffekte:** Dieses Modell hat ebenfalls einen extrem starken
Netzwerkeffekt. Ein für das [Wallet](https://www.corbado.com/blog/digital-wallet-assurance) eines großen PSPs
erstellter Passkey ist bei jedem Händler wiederverwendbar, der diesen PSP akzeptiert, was
einen starken Anreiz für Benutzer und Händler schafft, dem Ökosystem des PSPs beizutreten.

> **Deep Dive:** [PayPal](https://www.corbado.com/blog/paypal-passkeys) ist ein Pionier in diesem Bereich. Für
> eine detaillierte Fallstudie, wie sie Passkeys zur Sicherung ihres Ökosystems verwenden,
> lesen Sie unsere Analyse: [PayPal Passkeys](https://www.corbado.com/blog/paypal-passkeys): Passkeys wie
> [PayPal](https://www.corbado.com/blog/paypal-passkeys) implementieren.

```mermaid
sequenceDiagram
    participant U as Benutzer
    participant M as Händler-Website
    participant P as PSP / Wallet (z.B. PayPal)

    U->>M: Wählt "Mit PSP bezahlen" an der Kasse
    M->>U: Leitet weiter oder zeigt Popup für PSP-Login
    Note over P,U: Benutzer authentifiziert sich direkt beim PSP
    U->>P: Authentifizierung mit Passkey für psp.com
    P-->>U: Authentifizierung erfolgreich
    P-->>M: Zahlungsgarantie / OK an Händler senden
    M-->>U: Bestellung bestätigen
```

## 6. Allgemeine Herausforderungen mit Passkeys im Zahlungsverkehr

### 6.1 Verständnis der Passkey-Portabilität: Die Rolle der Relying Party

Eine häufige und entscheidende Frage ist, ob ein für ein Modell erstellter Passkey in
einem anderen wiederverwendet werden kann. Kann beispielsweise ein Passkey, den ein
Benutzer für seine Bank zur Verwendung mit SPC erstellt, zum Einloggen auf der Website
eines Händlers in einem DA-Fluss verwendet werden? Die Antwort ist nein, und sie
unterstreicht die zentrale Rolle der **Relying Party (RP)**.

Ein Passkey ist im Grunde ein kryptografisches Anmeldeinformation, das einen Benutzer mit
einer bestimmten RP verknüpft. Der öffentliche Schlüssel wird auf den Servern der RP
registriert, und der private Schlüssel verbleibt auf dem Gerät des Benutzers. Die
Authentifizierung ist der Akt des Nachweises des Besitzes dieses privaten Schlüssels
_gegenüber dieser spezifischen RP_.

- Im **Issuer-zentrierten (SPC)**-Modell ist die RP der **Issuer** (z. B. `chase.com`).
  Der Passkey ist bei der Bank registriert.
- Im **Händler-zentrierten (DA)**-Modell ist die RP der **Händler** oder sein PSP (z. B.
  `amazon.com` oder `stripe.com`). Der Passkey ist beim Händler für den Login registriert.
- Im **Netzwerk-zentrierten** Modell ist die RP das **Kartennetzwerk** (z. B. `visa.com`).
  Der Passkey ist beim Netzwerk für Click to Pay registriert.
- Im **PSP-zentrierten** Modell ist die RP der **Payment Service Provider** (z. B.
  `paypal.com`). Der Passkey ist beim Wallet oder Dienst des PSP registriert.

Da der Passkey kryptografisch an die Domain der RP gebunden ist, kann ein bei `chase.com`
registrierter Passkey nicht von `amazon.com` validiert werden. Sie sind aus technischer
Sicht unterschiedliche digitale Identitäten. Ein Benutzer muss für jede Relying Party, mit
der er interagiert, einen separaten Passkey erstellen.

Die „Wiederverwendbarkeit“ und „Portabilität“, die Passkeys so leistungsstark machen,
kommen aus zwei Bereichen:

1. **Passkey-Synchronisierung:** Dienste wie [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain)
   und [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) synchronisieren
   Passkeys über die Geräte eines Benutzers. Ein für `chase.com` auf einem Telefon
   erstellter Passkey ist also automatisch auf dem Laptop des Benutzers verfügbar, aber er
   ist immer noch nur für `chase.com`.
2. **Föderation:** Dies ist das von Click to Pay verwendete Modell. Ein Händler kann dem
   Netzwerk (z. B. Visa) vertrauen, den Benutzer zu authentifizieren. Der Benutzer
   authentifiziert sich bei Visa (der RP), und Visa signalisiert dann dem Händler, dass
   der Benutzer legitim ist. Dies ist analog zu „Mit Google anmelden“, wo eine Website
   Google vertraut, den Login zu handhaben. Der Passkey wird nicht vom Händler
   wiederverwendet; das _Authentifizierungsereignis_ wird es.

Daher sind die vier Modelle nicht nur unterschiedliche technische Wege, sondern
konkurrierende Identitätsstrategien. Jedes schlägt eine andere Entität vor, die primäre
Relying Party für die Zahlungsauthentifizierung zu sein, und Benutzer werden
wahrscheinlich Passkeys für ihre Issuer, Lieblingshändler, PSP-Wallets _und_
Kartennetzwerke haben.

### 6.2 Operative Herausforderungen: Das Wiederherstellungsproblem

Obwohl diese Modelle leistungsstarke neue Authentifizierungsmethoden bieten, führen sie
auch eine kritische operative Herausforderung ein, die oft übersehen wird:
**Passkey-Wiederherstellung und Kontowiederherstellung**. Synchronisierte Passkeys, die
von Plattformen wie [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) und
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) verwaltet werden,
mildern das Problem eines einzelnen verlorenen Geräts. Sie lösen jedoch nicht das Problem,
dass ein Benutzer _alle_ seine Geräte verliert oder zwischen Ökosystemen wechselt (z. B.
von [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) zu
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)). In diesen Szenarien ist ein sicherer und
benutzerfreundlicher Prozess, mit dem der Benutzer seine
[Identität](https://www.corbado.com/de/blog/digital-credentials-api) auf andere Weise nachweisen und einen
Passkey auf einem neuen Gerät registrieren kann, eine unabdingbare Voraussetzung für jede
groß angelegte Bereitstellung. Wie die eigene Dokumentation von Mastercard feststellt,
muss ein Benutzer, der das Gerät wechselt, einen neuen Passkey erstellen, ein Prozess, der
möglicherweise eine Identitätsprüfung durch seine Bank erfordert.
([Mastercard® payment passkeys – Frequently asked questions](https://www.mastercard.com/content/dam/public/mastercardcom/na/global-site/documents/mastercard-payment-passkeys-faqs.pdf))
Dies unterstreicht, dass eine vollständige Passkey-Lösung nicht nur die
Authentifizierungszeremonie selbst, sondern auch den gesamten Lebenszyklus des
Passkey-Managements, einschließlich robuster Wiederherstellungsabläufe, umfassen muss.

## 7. Strategische Integrationspunkte und vergleichende Analyse

Die vier Architekturmodelle – Issuer-zentriert (SPC), Händler-zentriert (DA),
Netzwerk-zentriert (Click to Pay) und PSP-zentriert – führen zu unterschiedlichen
Integrationsmöglichkeiten für verschiedene Akteure im Zahlungsökosystem. Jeder Ansatz
bietet ein einzigartiges Bündel von Kompromissen zwischen Benutzererlebnis,
Implementierungskomplexität, Haftung und Kontrolle. Dieser Abschnitt bietet eine
pragmatische Analyse dieser Integrationspunkte, um strategische Entscheidungen zu leiten.

### 7.1 Integration beim Issuer / ACS-Anbieter

- **Chance:** Die primäre Chance für Issuer und die Access Control Server (ACS)-Anbieter,
  die sie bedienen, besteht darin, den 3DS-„Challenge-Flow“ zu verbessern, indem veraltete
  Methoden wie OTPs und Passwörter durch
  [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) ersetzt werden.
- **Zielgruppe:** Diese Integration richtet sich an [ACS](https://www.corbado.com/glossary/acs)-Anbieter (z. B.
  Netcetera, CA Technologies/Arcot), Technologieanbieter im Issuer-Bereich und große
  ausstellende Banken, die ihre eigenen internen ACS-Plattformen betreiben.
- **Rolle des Anbieters:** Ein Passkey-as-a-Service-Anbieter wie Corbado würde ein
  einbettbares FIDO-Server- oder Softwaremodul anbieten, das vollständig mit der
  SPC-Spezifikation konform ist. Dieses Modul würde in die Kern-ACS-Plattform integriert,
  sodass der ACS einen SPC-Flow auslösen kann, wenn seine Risiko-Engine eine Challenge für
  notwendig hält.
- **Vorteile:**
    - **Hohe Sicherheit & regulatorische Konformität:** Die Verwendung von
      kryptografischem [Dynamic Linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) durch SPC
      bietet einen starken, prüfbaren Nachweis der Benutzereinwilligung für spezifische
      Transaktionsdetails und adressiert direkt die Kernanforderungen von Vorschriften wie
      [PSD2 SCA](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden).
    - **Verbessertes Benutzererlebnis gegenüber OTPs:** Die Authentifizierung mit einem
      schnellen biometrischen Scan ist deutlich schneller und weniger fehleranfällig als
      die manuelle Eingabe eines per SMS erhaltenen Codes, was zu einer messbaren
      Steigerung der [Conversion Rates](https://www.corbado.com/blog/logins-impact-checkout-conversion) bei
      Challenges führen kann.
    - **Klares Haftungsmodell:** Dieses Modell fügt sich nahtlos in das bestehende
      3DS-Framework ein. Wenn eine Transaktion erfolgreich über SPC authentifiziert wird,
      verlagert sich die Haftung für betrügerische Rückbuchungen vom Händler auf den
      Issuer, genau wie bei anderen 3DS-Challenge-Methoden.
- **Nachteile:**
    - **Immer noch ein „Challenge“-Flow:** Obwohl SPC das Challenge-Erlebnis verbessert,
      eliminiert es dieses nicht. Der Benutzer wird immer noch an der Kasse mit einem
      Authentifizierungsschritt unterbrochen. Dieses Erlebnis ist zwar besser, aber von
      Natur aus reibungsintensiver als ein vollständig passiver „Frictionless“-Flow oder
      ein erfolgreicher Delegated Authentication-Flow.
    - **Abhängig von der Issuer-Risikologik:** Die Akzeptanz und Häufigkeit der
      SPC-Nutzung hängen vollständig vom ACS des Issuers und seiner RBA-Engine ab. Der ACS
      entscheidet immer noch, _ob_ und _wann_ eine Challenge ausgelöst wird.
    - **Verzögerte Ökosystem-Bereitschaft:** Eine weit verbreitete Nutzung erfordert, dass
      das Ökosystem EMV 3DS Version 2.3 oder höher annimmt und dass die Browser der
      Benutzer die SPC Web API unterstützen. Wie bereits erwähnt, ist der Mangel an
      universeller Unterstützung, insbesondere auf mobilen Plattformen wie
      [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios), ein erhebliches Hindernis.

### 7.2 Integration beim Händler / Payment Service Provider (PSP)

- **Chance:** Implementierung von Delegated Authentication (DA), die es dem Händler oder
  seinem PSP ermöglicht, SCA zum Zeitpunkt des Kunden-Logins durchzuführen und so ein
  vollständig nahtloses Checkout-Erlebnis für wiederkehrende, authentifizierte Benutzer zu
  schaffen.
- **Zielgruppe:** Dies ist am relevantesten für große
  [E-Commerce](https://www.corbado.com/passkeys-for-e-commerce)-Händler, Full-Stack-PSPs (wie Stripe oder Adyen)
  und digitale Wallet-Anbieter, die eine direkte Beziehung zum Verbraucher haben und
  bereits in ein sicheres Konto- und Login-System investiert haben.
- **Rolle des Anbieters:** Ein [Passkey-Anbieter](https://www.corbado.com/de/blog/passkey-anbieter) würde die
  Kernlösung für die [Passkey-Authentifizierung](https://www.corbado.com/de/blog/passkey-anbieter) für den
  Login-Flow des Händlers liefern. Entscheidend ist, dass die Lösung auch die notwendigen
  Datenausgaben und kryptografischen Nachweise liefern muss, die in die
  3DS-Authentifizierungsanfrage verpackt werden können, um dem Issuer zu signalisieren,
  dass eine konforme SCA bereits stattgefunden hat.
- **Vorteile:**
    - **Optimales Benutzererlebnis:** Dieses Modell bietet den reibungslosesten
      Zahlungsfluss für authentifizierte Benutzer. Es verlagert den
      Authentifizierungsschritt in einen natürlichen und vertrauten Teil der User Journey
      (Konto-Login) und kann die 3DS-Challenge vollständig eliminieren, was einen echten
      One-Click-Checkout ermöglicht.
    - **Höchstes Konversionspotenzial:** Durch die Beseitigung des letzten Reibungspunktes
      an der Kasse hat DA das Potenzial, die signifikanteste Steigerung der Conversion
      Rates bei Zahlungen zu erzielen. Ein Pilotprojekt von Stripe mit Wise-Karteninhabern
      berichtete von einer Konversionssteigerung von 7 % für Transaktionen, die ihre
      DA-Lösung nutzten.
    - **Stärkt die Händler-Kunden-Beziehung:** Das gesamte Authentifizierungs- und
      Checkout-Erlebnis bleibt in der Markenwelt des Händlers, was seine direkte Beziehung
      zum Kunden stärkt.
- **Nachteile:**
    - **Komplexe Geschäftsbedingungen und Haftung:** DA ist kein einfacher technischer
      Schalter. Es erfordert explizite, oft bilaterale Vereinbarungen zwischen Issuern und
      den Händlern/PSPs, denen sie vertrauen. Darüber hinaus übernimmt die Partei, die die
      [delegierte Authentifizierung](https://www.corbado.com/de/blog/delegierte-authentifizierung-psd3-psr-passkeys)
      durchführt, die Haftung für Betrug, und die Vereinbarung unterliegt einer strengen
      regulatorischen Aufsicht als eine Form des „Outsourcings“, was eine erhebliche
      Compliance-Last mit sich bringt.
    - **Abhängig vom Vertrauen des Issuers:** Das gesamte Modell hängt von der
      Bereitschaft eines Issuers ab, dem Authentifizierungsprozess des Händlers zu
      vertrauen. Dieses Vertrauen wird wahrscheinlich anfangs nur den größten, sichersten
      und strategisch wichtigsten Partnern gewährt.
    - **Fragmentierte Akzeptanz:** Im Gegensatz zu einem universellen Standard wird DA auf
      einer Pro-Issuer-, Pro-Händler-Basis eingeführt, was zu einer fragmentierten
      Landschaft führt, in der das Erlebnis nicht für alle Karteninhaber bei allen
      Händlern konsistent ist.

### 7.3 Integration beim Kartennetzwerk (über Click to Pay)

- **Chance:** Das netzwerk-gebrandete Passkey-Erlebnis für das massive Volumen an
  Gast-Checkout-Transaktionen zu ermöglichen.
- **Zielgruppe:** Payment Gateways und PSPs, die ihren Händlerkunden eine moderne,
  standardisierte Gast-Checkout-Lösung anbieten möchten.
- **Rolle des Anbieters:** Der Anbieter kann als entscheidender Integrationspartner
  fungieren. Da Visa und Mastercard separate, proprietäre Passkey-Dienste entwickelt
  haben, kann ein [Passkey-Anbieter](https://www.corbado.com/de/blog/passkey-anbieter) ein einheitliches SDK oder
  eine „Orchestrierungsschicht“ anbieten, die die Komplexität der Integration mit den
  unterschiedlichen APIs jedes Netzwerks abstrahiert und einen einzigen, vereinfachten
  Integrationspunkt für den PSP bietet.
- **Vorteile:**
    - **Standardisierte Gast-Checkout-Lösung:** Click to Pay mit Passkeys löst ein großes
      Problem der Branche: den reibungsintensiven Gast-Checkout mit hoher Abbruchrate. Es
      bietet ein konsistentes, wiedererkennbares und vertrauenswürdiges Erlebnis.
- **Netzwerkgetriebene Akzeptanz:** Visa und Mastercard setzen sich mit vollem Gewicht für
  diese Initiative ein, was eine schnelle Akzeptanz bei Issuern, Händlern und Verbrauchern
  fördern wird. PSPs werden unter Wettbewerbsdruck geraten, dies zu unterstützen.
- **Vereinfachte Haftungs- und Sicherheitslast:** Das Kartennetzwerk, das als föderierte
  Relying Party agiert, trägt die Hauptlast für den Aufbau und die Sicherung der
  FIDO-Authentifizierungs-[Infrastruktur](https://www.corbado.com/passkeys-for-critical-infrastructure), was die
  Sicherheits- und Haftungsposition für den Händler vereinfacht.
- **Nachteile:**
    - **Verlust von Kontrolle und Branding:** Der Hauptnachteil ist, dass der Händler und
      sein PSP die Kontrolle über das Checkout-Benutzererlebnis an das Kartennetzwerk
      abgeben. Der Checkout wird zu einem „Visa-Checkout“ oder einem „Mastercard-Checkout“
      mit deren Branding und Benutzeroberfläche.
    - **Potenzial zur Disintermediation:** Indem sie zum zentralen Identitätsanbieter für
      den [E-Commerce](https://www.corbado.com/passkeys-for-e-commerce) werden, könnten die Netzwerke die direkte
      Daten- und Markenbeziehung zwischen Händler und Kunde im Laufe der Zeit schwächen.
    - **„Black Box“-Implementierung:** Die internen Abläufe des FIDO-Servers, der
      Risiko-Engines und der Authentifizierungslogik des Netzwerks sind für den Händler
      und den PSP undurchsichtig. Sie integrieren sich in einen Dienst, dessen Regeln und
      Benutzererlebnis sie nicht kontrollieren.

| Kategorie                       | Issuer / ACS                                                       | Händler / PSP (DA)                                            | Netzwerk / Click to Pay                                 | PSP / Wallet                                       |
| ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------- |
| **Schlüsseltechnologie**        | Secure Payment Confirmation (SPC)                                  | Delegated Authentication (DA)                                 | Föderierte Passkey-Dienste                              | Wallet-basierte Authentifizierung                  |
| **Zielakteur**                  | ACS-Anbieter, ausstellende Banken                                  | Große Händler, PSPs, Wallets                                  | PSPs, Payment Gateways                                  | PayPal, Stripe Link, etc.                          |
| **Benutzererlebnis (Reibung)**  | Niedrig (Verbessert Challenge, ist aber immer noch eine Challenge) | Sehr niedrig (Eliminiert Challenge für eingeloggte Benutzer)  | Niedrig (Standardisierter, reibungsarmer Gast-Checkout) | Sehr niedrig (Nahtloser Fluss im PSP-Ökosystem)    |
| **Implementierungskomplexität** | Mittel (Erfordert ACS-Integration, 3DS 2.3+)                       | Hoch (Erfordert bilaterale Vereinbarungen, übernimmt Haftung) | Mittel (Erfordert Integration mit Netzwerk-APIs)        | Mittel (Erfordert Wallet- & Passkey-Infrastruktur) |
| **Haftungsübertragung**         | Ja (Standard-3DS-Haftungsübertragung)                              | Ja (Haftung geht auf die delegierende Partei über)            | Ja (Netzwerk/Issuer übernimmt Haftung)                  | Ja (PSP übernimmt Haftung)                         |
| **Ökosystem-Bereitschaft**      | Sehr niedrig (Blockiert durch fehlende Apple-Unterstützung)        | Begrenzt (Erfordert spezifisches Issuer-Händler-Vertrauen)    | Hoch (Starker Vorstoß des Netzwerks zur Akzeptanz)      | Hoch (Ausgereift für etablierte Wallet-Anbieter)   |

## 8. Wettbewerbslandschaft und Zukunftsaussichten

Der Übergang zur Passkey-basierten Zahlungsauthentifizierung ist keine theoretische Übung;
er wird aktiv von den größten Akteuren der Branche vorangetrieben. Ihre Strategien,
Pilotprogramme und öffentlichen Äußerungen geben einen klaren Einblick in die
Wettbewerbsdynamik und die wahrscheinliche Entwicklung der Akzeptanz.

### 8.1 Fallstudien: Die Pioniere der Payment Passkeys

- **PayPal:** Als Gründungsmitglied der [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) und
  digital-nativer Zahlungsanbieter war PayPal einer der aggressivsten frühen Anwender von
  Passkeys. Sie begannen Ende 2022 mit einer schrittweisen globalen Einführung, beginnend
  in den USA und expandierend nach Europa und in andere Regionen. Ihre Implementierung ist
  eine Fallstudie für Best Practices, die Funktionen wie
  [Conditional UI](https://www.corbado.com/glossary/conditional-ui) nutzt, um ein
  [One-Tap-Login](https://docs.corbado.com/corbado-connect/features/one-tap-login)-Erlebnis
  zu schaffen, das automatisch einen Passkey anfordert, wenn der Benutzer mit dem
  Login-Feld interagiert. PayPal hat erhebliche frühe Erfolge gemeldet, darunter erhöhte
  Login-Erfolgsraten und eine erhebliche Reduzierung von Account Takeover (ATO)-Betrug.
  Ihre Strategie umfasst auch die aktive Befürwortung einer regulatorischen
  Weiterentwicklung in Europa, die auf einen ergebnisorientierten Ansatz für SCA drängt,
  der die inhärente [Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) von
  synchronisierten Passkeys anerkennt.

- **Visa:** Die Strategie von Visa konzentriert sich auf den **Visa Payment Passkey
  Service**, eine umfassende Plattform, die auf ihrer eigenen FIDO-Server-Infrastruktur
  aufbaut. Dieser Dienst ist als föderiertes Modell konzipiert, bei dem Visa die
  Komplexität der Authentifizierung im Namen seiner ausstellenden Partner übernimmt. Das
  Hauptvehikel für diesen Dienst ist **Click to Pay**, was Visa in die Lage versetzt, das
  Gast-Checkout-Erlebnis zu dominieren. Die Botschaft von Visa geht über einfache
  Zahlungen hinaus und rahmt ihren Passkey-Dienst als grundlegendes Element einer
  breiteren digitalen Identitätslösung ein, die im gesamten Handelsökosystem verwendet
  werden kann. Sie pilotieren die Technologie aktiv, einschließlich SPC, und berichten,
  dass biometrische Authentifizierung die Betrugsraten im Vergleich zu SMS-OTPs um 50 %
  senken kann.

- **Mastercard:** Mastercard hat den strategischen Fokus von Visa auf einen Service auf
  Netzwerkebene gespiegelt und seinen eigenen **Payment Passkey Service** auf Basis seines
  bestehenden **Token Authentication Service (TAS)** eingeführt. Ihre
  Go-to-Market-Strategie war durch eine Reihe von hochkarätigen globalen Pilotprojekten
  gekennzeichnet. Im August 2024 kündigten sie ein
  [großes Pilotprojekt in Indien](https://www.mastercard.com/news/press/2024/august/mastercard-selects-india-for-the-global-launch-of-its-payment-passkey-service-accelerating-secure-online-checkout-for-millions-of-shoppers/)
  an, in Partnerschaft mit den größten Zahlungsaggregatoren des Landes (Juspay, Razorpay,
  PayU), einem großen Online-Händler (bigbasket) und einer führenden Bank (Axis Bank). Es
  folgten Einführungen in anderen Schlüsselmärkten, darunter
  [Lateinamerika mit den Partnern Sympla und Yuno](https://www.biometricupdate.com/202412/mastercard-brings-payment-passkey-service-to-latin-america)
  und die
  [VAE mit Tap Payments](https://www.entrepreneur.com/en-ae/technology/mastercard-and-tap-payments-launch-click-to-pay-with/482810).
  Dieser Ansatz offenbart eine klare Strategie: Partnerschaften mit Ökosystem-Aggregatoren
  (PSPs, Gateways) eingehen, um schnell Skaleneffekte zu erzielen. Mastercard hat sich
  öffentlich dazu verpflichtet, die manuelle Karteneingabe in Europa bis 2030 auslaufen zu
  lassen und vollständig auf tokenisierte, Passkey-authentifizierte Transaktionen
  umzusteigen.

Die Strategien dieser Pioniere offenbaren eine kritische Dynamik. Das
Gast-Checkout-Erlebnis, historisch ein fragmentierter und reibungsintensiver Bereich, ist
zum strategischen Brückenkopf für die Kartennetzwerke geworden. Indem sie eine überlegene,
Passkey-fähige Lösung für Gastbenutzer über Click to Pay schaffen, können die Netzwerke
eine direkte Identitätsbeziehung zu den Verbrauchern aufbauen. Sobald ein Verbraucher bei
einem Gast-Checkout einen Passkey auf Netzwerkebene erstellt, wird diese Identität auf
jeden anderen Händler übertragbar, der Click to Pay unterstützt. Dies ermöglicht es den
Netzwerken, Benutzeridentitäten effektiv zu „erwerben“ und ein nahtloses Erlebnis im
gesamten Web anzubieten – ein starker Schachzug, um die zentrale Rolle des
Identitätsanbieters für den digitalen Handel zu erobern.

### 8.2 Zukünftige Entwicklung und breitere Auswirkungen

Die konzertierten Bemühungen dieser großen Akteure, kombiniert mit breiteren
technologischen und regulatorischen Trends, deuten auf einen beschleunigten und
unvermeidlichen Wandel in der Zahlungsauthentifizierung hin.

- **Das unvermeidliche Ende von OTPs:** Der branchenweite Vorstoß für Passkeys
  signalisiert den Anfang vom Ende für SMS-basierte Einmalpasswörter als primäre
  Authentifizierungsmethode. OTPs werden zunehmend als Haftungsrisiko angesehen, sowohl
  wegen ihres reibungsintensiven Benutzererlebnisses als auch wegen ihrer wachsenden
  Anfälligkeit für Angriffe wie SIM-Swapping und ausgeklügelte
  [Phishing](https://www.corbado.com/glossary/phishing)-Kampagnen. Mit der zunehmenden Verbreitung von Passkeys
  wird die Abhängigkeit von OTPs auf einen Fallback- oder Wiederherstellungsmechanismus
  reduziert, anstatt eine primäre Challenge-Methode zu sein.

- **Regulatorischer Rückenwind:** Während aktuelle Vorschriften wie
  [PSD2](https://www.corbado.com/blog/psd2-passkeys) den ursprünglichen Auftrag für SCA schufen, haben ihre
  starren, kategoriebasierten Definitionen eine gewisse Unsicherheit bezüglich neuer
  Technologien wie synchronisierter Passkeys geschaffen. Kommende regulatorische
  Aktualisierungen, wie [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) in Europa, werden voraussichtlich
  einen technologieneutraleren, ergebnisorientierten Ansatz verfolgen. Dies wird
  wahrscheinlich Authentifizierungsmethoden begünstigen, die nachweislich
  [Phishing-resistent](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) sind, und einen klareren
  regulatorischen Weg für die breite Einführung von Passkeys als konforme SCA-Methode
  ebnen.

- **Der Aufstieg der föderierten Zahlungsidentität:** Die strategischen Schritte von Visa
  und Mastercard gehen über die reine Sicherung von Zahlungen hinaus; es geht darum, ein
  neues Paradigma für die digitale Identität zu etablieren. Durch den Aufbau föderierter
  Passkey-Dienste positionieren sie sich als die zentralen, vertrauenswürdigen
  Identitätsanbieter für das gesamte digitale Handelsökosystem. Dies kann als direkte
  strategische Antwort auf die mächtigen Identitätsplattformen von
  [Big Tech](https://www.corbado.com/blog/big-tech-vs-passkey-aggregators) (z. B. Apple ID, Google Account)
  gesehen werden. Die Zukunft des Online-Zahlungsverkehrs ist untrennbar mit diesem
  größeren Kampf verbunden, wer die Identität der Verbraucher im Web besitzen und
  verwalten wird.

### 8.3 Aufkommende Anwendungen für Passkeys

Während die Kernzahlungstransaktion im Mittelpunkt steht, ist die Passkey-Technologie
bereit, Reibung zu beseitigen und die Sicherheit in einer Vielzahl von angrenzenden
[Finanzdienstleistungen](https://www.corbado.com/passkeys-for-banking) zu verbessern. Viele Prozesse, die immer
noch auf Passwörtern oder umständlichen OTPs beruhen, sind ideale Kandidaten für ein
Passkey-Upgrade.

#### 8.3.1 Jenseits des Checkouts: Neue Grenzen für Passkeys

- **Digital Wallet Provisioning:** Der Prozess des Hinzufügens einer Kredit- oder
  Debitkarte zu einem digitalen Wallet wie [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) oder
  [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) erfordert oft einen Verifizierungsschritt, wie
  z. B. ein vom Issuer gesendetes SMS-OTP. Dies ist ein Reibungspunkt, der durch einen
  Passkey-Flow ersetzt werden kann.
- **Open Banking & Kontoverknüpfung:** Die Grundlage des Open Banking besteht darin,
  Drittanbieteranwendungen (wie Budgetierungs-Apps oder andere
  [Fintech](https://www.corbado.com/de/blog/finom-passkeys-banking)-Dienste) den Zugriff auf die Bankkontodaten
  eines Benutzers zu ermöglichen. Dies erfordert, dass sich der Benutzer bei seiner Bank
  authentifiziert, ein Prozess, der oft umständlich ist. Passkeys bieten eine viel
  reibungslosere und sicherere Möglichkeit, diese Zustimmung zu erteilen, und ersetzen
  umständliche Weiterleitungen und manuelle Passworteingaben durch eine einfache
  biometrische Authentifizierung.
- **Sicherung von Card-on-File (CoF)-Token:** Über die reine Sicherung des Logins für ein
  Konto mit einer gespeicherten Karte hinaus können Passkeys verwendet werden, um den
  anfänglichen Akt des _Speicherns_ der Karte zu sichern. Eine Challenge in dem Moment, in
  dem ein Benutzer seine Karte hinzufügt, liefert einen starken Beweis dafür, dass der
  legitime Karteninhaber anwesend ist, und reduziert Betrug durch gestohlene
  Kreditkartennummern, die zur Erstellung von CoF-Profilen für späteren Missbrauch
  verwendet werden.
- **BNPL und Sofortkredite:** Buy Now, Pay Later-Dienste und andere Formen von
  Sofortkrediten umfassen sowohl ein anfängliches Onboarding als auch Risikobewertungen
  pro Transaktion. Passkeys werden bereits von Pionieren wie Klarna verwendet, um
  Passwörter für den Login zu ersetzen. Sie können auch als
  Step-up-Authentifizierungsmethode für hochwertige Einkäufe oder wenn ein Benutzer eine
  neue Kreditlinie beantragt, verwendet werden und ein stärkeres, reibungsärmeres Signal
  der Benutzerabsicht als traditionelle Methoden liefern.

#### 8.3.2 Revolutionierung von Krypto: Passkeys für Stablecoin-Wallets

Der Aufstieg von Stablecoins (wie USDC oder EURC) stellt eine neue, Blockchain-basierte
Zahlungsschiene dar. Ein Haupthindernis für die breite Akzeptanz war jedoch die schlechte
Benutzererfahrung und Sicherheit von Krypto-Wallets. Traditionell werden diese Wallets
durch eine „Seed-Phrase“ (eine Liste von 12-24 Wörtern) gesichert, die der Benutzer
aufschreiben und schützen muss. Dies ist unglaublich benutzerunfreundlich und macht die
[Kontowiederherstellung](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) zu einem Albtraum.

Passkeys werden diese Erfahrung komplett verändern. Die Branche bewegt sich auf ein Modell
zu, bei dem der private Schlüssel, der die On-Chain-Vermögenswerte kontrolliert, durch den
Passkey des Geräts gesichert wird.

- **Eliminierung von Seed-Phrases:** Anstatt eine Seed-Phrase aufzuschreiben, wird das
  Wallet eines Benutzers durch die eingebaute Sicherheit seines Geräts erstellt und
  gesichert. Um eine Transaktion zu autorisieren, wie z. B. das Senden von Stablecoins an
  einen Händler, authentifiziert sich der Benutzer einfach mit
  [Face ID](https://www.corbado.com/faq/is-face-id-passkey) oder einem Fingerabdruckscan. Dies macht eine
  Krypto-Zahlung so nahtlos und sicher wie die Verwendung von
  [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay).
- **Ermöglichung der Kontowiederherstellung:** Durch die Verwendung von
  Wallet-Architekturen wie „Smart Accounts“ (oder „Account Abstraction“) können
  Wiederherstellungsmechanismen eingebaut werden. Ein Benutzer könnte vertrauenswürdige
  Freunde, Familie oder Institutionen als „Guardians“ benennen, die ihm helfen können,
  sein Konto wiederherzustellen, wenn er alle seine Geräte verliert – eine enorme
  Verbesserung gegenüber der Alles-oder-Nichts-Natur von Seed-Phrases.

Diese Entwicklung könnte die Reibung und das Risiko bei der Verwendung von Stablecoins für
Zahlungen erheblich reduzieren und sie potenziell zu einer praktikableren und
etablierteren Alternative zu traditionellen Zahlungsschienen machen.

## 9. Wie Corbado helfen kann

Die Analyse der Zahlungslandschaft und der aufkommenden Passkey-Integrationsmodelle zeigt
mehrere klare und umsetzbare Möglichkeiten auf. Für ein auf Passkeys spezialisiertes
Authentifizierungsunternehmen wie Corbado ist das Ziel, jeden Akteur im Ökosystem zu
befähigen, seine strategischen Ziele zu erreichen, indem wir die grundlegende Technologie
bereitstellen, die zur Bewältigung dieses Übergangs erforderlich ist.

### 9.1 Stärkung des Issuer-Ökosystems (ACS-Anbieter & Banken)

- **Das Ziel:** Den 3DS-Challenge-Flow zu modernisieren, reibungsintensive OTPs zu
  ersetzen, um die Konversionsraten zu erhöhen, die Sicherheit zu verbessern und die
  Anforderungen von PSD2/[PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) direkt zu erfüllen.
- **Wie Corbado hilft:** Wir bieten ein einbettbares Passkey-Authentifizierungsmodul, das
  für eine unkomplizierte Integration in bestehende Access Control Server
  (ACS)-Plattformen konzipiert ist. Wir helfen ACS-Anbietern, ein erstklassiges,
  reibungsarmes Challenge-Erlebnis anzubieten, das ihrem gesamten Netzwerk von Banken und
  Händlern zugutekommt.

### 9.2 Stärkung von Händlern & PSPs für den ultimativen Checkout

- **Das Ziel:** Die End-to-End-Customer-Journey zu beherrschen und das ultimative
  Checkout-Erlebnis durch Delegated Authentication (DA) zu liefern, wodurch die
  3DS-Challenge für eingeloggte Benutzer entfällt.
- **Wie Corbado hilft:** Corbado liefert eine umfassende Lösung zur Ermöglichung von DA.
  Dies umfasst nicht nur ein erstklassiges Passkey-Login-System, sondern auch die
  Werkzeuge und APIs zur Erzeugung der kryptografischen Nachweise, die von Issuern zur
  Gewährung von DA-Ausnahmen benötigt werden. Wir agieren als Technologiepartner und
  ermöglichen es Händlern und PSPs, die Konversion zu maximieren und ihre Marke zu
  stärken.

### 9.3 Stärkung des Netzwerk-Integrations-Ökosystems

- **Das Ziel:** Mühelos die neuesten, vom Netzwerk vorgeschriebenen Funktionen wie Click
  to Pay anzubieten und Plattformen wettbewerbsfähig zu halten, ohne kostspielige,
  doppelte Entwicklungsanstrengungen.
- **Wie Corbado hilft:** Corbado bietet eine „Passkey Orchestration“-Schicht. Wir helfen
  bei der Integration der Dienste von Visa und Mastercard und bieten auch Möglichkeiten,
  wie Händler gleichzeitig ihre eigene Passkey-Lösung anbieten können, um einen modernen
  Gast-Checkout zu ermöglichen.

### 9.4 Stärkung des PSP-zentrierten Wallet-Modells

- **Das Ziel:** Das gesamte Wallet-Ökosystem zu sichern und ein nahtloses und sicheres
  Login- und Zahlungserlebnis zu schaffen, das über das gesamte Händlernetzwerk des PSPs
  portabel ist.
- **Wie Corbado hilft:** Wir stellen die Kern-Passkey-Infrastruktur bereit, die es großen
  PSPs und Wallet-Anbietern ermöglicht, zur zentralen Relying Party für ihre Benutzer zu
  werden. Durch die Integration unserer Lösung können sie Passwörter für ihre
  Wallet-Logins (z. B. für PayPal, Stripe Link oder Klarna) ersetzen. Dies sichert nicht
  nur das Konto gegen Übernahme, sondern optimiert auch die Zahlungsautorisierung zu einem
  biometrischen Ein-Klick-Schritt und schafft so ein starkes, markengebundenes
  Authentifizierungserlebnis, das Benutzer bindet und Händler anzieht.

## 10. Hauptkandidaten für eine Passkey-Adoptionslösung

Diese Analyse unterstreicht einen entscheidenden Erfolgsfaktor für jede Passkey-basierte
Strategie: die Benutzerakzeptanz. Eine Lösung, die die Erstellung und Nutzung von Passkeys
nachweislich von einer Basis von \~10 % auf über 50 % steigern kann, adressiert die
primäre Herausforderung bei der Einführung dieser neuen Authentifizierungsmodelle.
Basierend auf dem Ökosystem und den strategischen Zielen seiner Akteure sind die folgenden
Organisationen und Sektoren Hauptkandidaten für eine solche Lösung.

### 10.1 Ausstellende Banken und ACS-Anbieter (zur SPC-Verbesserung)

- **Kernproblem:** Hohe Reibung im 3DS-Challenge-Flow führt zu abgebrochenen Warenkörben
  und Umsatzverlusten für Händler, was die Karte eines Issuers weniger wettbewerbsfähig
  macht.
- **Wie die Akzeptanz hilft:** Eine höhere Akzeptanz von Passkeys führt direkt zu mehr
  erfolgreichen, reibungsarmen Challenges. Dies verbessert die Konversionsraten, erhöht
  die Sicherheit und macht die Zahlungsdaten des Issuers für Händler und Verbraucher
  wertvoller.
- **Hauptkandidaten:** Große ausstellende Banken (**Bank of America, Chase, Barclays**)
  und die ACS-Anbieter, die ihre 3DS-Technologie liefern (**Netcetera, CA Technologies**).

### 10.2 Große Händler und PSPs (für Delegated Authentication)

- **Kernproblem:** Der Wunsch, die Customer Journey zu beherrschen und die Reibung beim
  Checkout zu eliminieren, wird oft durch die Notwendigkeit einer 3DS-Challenge blockiert.
- **Wie die Akzeptanz hilft:** Das gesamte Modell der Delegated Authentication (DA)
  basiert darauf, dass der Händler den Benutzer beim Login stark authentifizieren kann.
  Eine hohe Passkey-Akzeptanz ist nicht nur eine Verbesserung, sondern eine Voraussetzung
  für eine erfolgreiche DA-Strategie. Die Ermöglichung von DA für eine Mehrheit der
  Benutzer ist ein starker Wettbewerbsvorteil.
- **Hauptkandidaten:** Globale E-Commerce-Führer (**Amazon, Walmart**), digitale
  Abonnementdienste (**Netflix, Spotify**) und die Full-Stack-PSPs, die sie bedienen
  (**Stripe, Adyen, Checkout.com**).

### 10.3 Kartennetzwerke (Visa, Mastercard, American Express)

- **Kernproblem:** Der Erfolg strategischer Identitätsdienste auf Netzwerkebene wie Click
  to Pay hängt direkt von einer breiten Verbraucherregistrierung ab.
- **Wie die Akzeptanz hilft:** Ein einfaches und ansprechendes Erstellungserlebnis für
  Passkeys ist für das Wachstum dieser föderierten Identitätsnetzwerke unerlässlich. Die
  Netzwerke könnten eine auf Akzeptanz ausgerichtete Lösung in die SDKs einbetten, die sie
  Händlern und PSPs zur Verfügung stellen, und so die Einführung und Nutzung ihrer
  proprietären Passkey-Dienste beschleunigen.
- **Hauptkandidaten:** **Visa** (für seinen Visa
  [Payment Passkey Service](https://www.corbado.com/de/blog/visa-passkeys)) und **Mastercard** (für seinen Token
  Authentication Service).

### 10.4 PSPs mit Verbraucher-Wallets (PayPal, Stripe Link, Klarna)

- **Kernproblem:** Der Wert des Wallets (z. B. PayPal, Stripe Link, Klarna) ist direkt an
  die Anzahl der aktiven, engagierten Benutzer gebunden. Reibung beim Login oder Checkout
  schwächt das Ökosystem.
- **Wie die Akzeptanz hilft:** Die Förderung der Massenakzeptanz von Passkeys für die
  eigene Domain des Wallets (`paypal.com` usw.) ist ein zentrales strategisches Ziel. Es
  reduziert Betrug, verbessert das Benutzererlebnis und stärkt den Netzwerkeffekt, was das
  Wallet für Verbraucher und Händler attraktiver macht.
- **Hauptkandidaten:** Globale PSPs mit Wallet-Angeboten (**PayPal, Stripe Link, Klarna**)
  und große regionale Akteure (**Mercado Pago, Block**).

### 10.5 Nationale Zahlungs- & Identitätsnetzwerke

- **Kernproblem:** Nationale Zahlungssysteme stehen unter dem Druck, ihre Infrastruktur zu
  modernisieren und digitale Identitätslösungen anzubieten, um gegenüber globalen
  Technologieunternehmen wettbewerbsfähig zu bleiben.
- **Wie die Akzeptanz hilft:** Diese Netzwerke müssen sicherstellen, dass ihre neuen
  digitalen Zahlungs- und Identitätsdienste eine breite Nutzung finden. Für einen Akteur
  wie **Australian Payments Plus (AP+)** ist die Förderung der Akzeptanz für Dienste wie
  **PayTo** (für Echtzeitzahlungen) und **ConnectID** (für digitale Identität) ein
  zentrales strategisches Ziel. Eine Lösung, die die Passkey-Registrierung fördert, ist
  ein direkter Wegbereiter für diese Strategie.
- **Hauptkandidaten:** **Australian Payments Plus (AP+)** und andere nationale
  Zahlungsinfrastrukturgremien.

## 11. Die Rolle der Big-Tech-Wallets (Apple, Google, Amazon, Meta)

Die großen Technologieunternehmen betreiben hochentwickelte digitale Wallets, die eine
einzigartige und mächtige Rolle im Zahlungsökosystem spielen. Sie befinden sich an der
Schnittstelle zwischen dem Gerät des Benutzers, seiner Plattformidentität und den
traditionellen Zahlungsschienen, was ihnen eine besondere Position und Strategie in Bezug
auf die Passkey-Akzeptanz verleiht.

### 11.1 Apple Pay & Google Pay: Die Plattform-Authentifizierungsschicht

[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) sind
am besten als Technologie- und Authentifizierungsschicht zu verstehen, die auf der
bestehenden Zahlungskarteninfrastruktur aufsetzt. Sie geben keine Karten aus oder
verarbeiten Transaktionen selbst, sondern speichern und übertragen stattdessen sicher
tokenisierte Versionen der bestehenden Zahlungskarten eines Benutzers.

- **Position im Ökosystem:** Sie fungieren als sicherer „Container“ für die Karten eines
  Benutzers. Wenn ein Benutzer online bezahlt, wählt er anstelle der Eingabe seiner
  Kartendaten Apple Pay oder [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay). Das Wallet
  übergibt dann einen sicheren, einmalig verwendbaren Token an das Payment Gateway des
  Händlers. Die Transaktion fließt immer noch normal durch den Acquirer, das Netzwerk und
  den Issuer.
- **Wie sie Passkeys nutzen:** Sie authentifizieren den Benutzer mit Gesichts- oder
  Fingerabdruckscan _gegenüber dem Wallet_ und autorisieren es, den Zahlungstoken
  freizugeben. Dies ist ein leistungsstarkes, reibungsarmes Authentifizierungsereignis,
  das sich jedoch von der 3DS/SCA-Authentifizierung unterscheidet, für die der
  Kartenaussteller verantwortlich ist. Ein Issuer kann technisch immer noch eine
  3DS-Challenge für eine über Apple Pay initiierte Transaktion auslösen, obwohl die starke
  gerätebasierte Authentifizierung dies weniger wahrscheinlich macht.
- **Chancen & wie sie von der Akzeptanz profitieren:**
    - **Optimierung des Wallet Provisioning:** Das Hinzufügen einer Karte zu einem Wallet
      erfordert oft ein OTP vom Issuer. Dies ist ein wichtiger Reibungspunkt. Apple und
      Google könnten mit Issuern zusammenarbeiten, um dies durch einen In-App-Passkey-Flow
      zu ersetzen und einen Passkey zur sofortigen Verifizierung des Benutzers zu
      verwenden. Eine Adoptionslösung für ihre Issuer-Partner würde ihre Wallets einfacher
      zu laden und zu verwenden machen.
    - **Zur delegierten Autorität werden:** Ihr ultimatives strategisches Ziel ist es,
      ihre leistungsstarke Plattformauthentifizierung zu nutzen, um zum definitiven,
      vertrauenswürdigen [Authenticator](https://www.corbado.com/glossary/authenticator) für Zahlungen zu werden.
      Wenn Issuer die Authentifizierung von Apple Pay oder Google Pay formell als
      SCA-konform anerkennen, könnten sie zu delegierten Autoritäten werden und die
      3DS-Challenge vollständig eliminieren. Eine hohe Akzeptanz ihrer eigenen
      Plattform-Passkeys ist entscheidend, um dies zu einem überzeugenden Angebot für
      Issuer zu machen.

### 11.2 Amazon Pay & Meta Pay: Das Card-on-File-Wallet-Modell

Amazon Pay und Meta Pay funktionieren eher wie ein traditioneller Händler mit einem sehr
großen Card-on-File (CoF)-Wallet, das auf Websites von Drittanbietern und innerhalb ihrer
eigenen Ökosysteme (z. B. für Social Commerce auf Instagram) verwendet werden kann.

- **Position im Ökosystem:** Sie sind ein klassisches Beispiel für das
  **Händler-zentrierte Modell**. Benutzer speichern ihre Zahlungskarten direkt in ihrem
  Amazon- oder Meta-Konto. Wenn sie Amazon Pay oder Meta Pay zum Bezahlen verwenden,
  authentifizieren sie sich bei ihrem Hauptkonto, und diese Plattform verarbeitet die
  Zahlung in ihrem Namen.
- **Wie sie Passkeys nutzen:** Ihre primäre Verwendung von Passkeys besteht darin, den
  Login zum Hauptkonto des Benutzers zu sichern (z. B. der Passkey für `Amazon.com`).
  Indem sie ihre riesigen Benutzerbasen von Passwörtern auf Passkeys für den Konto-Login
  umstellen, reduzieren sie das Risiko von Account Takeover Fraud drastisch und schützen
  die wertvollen gespeicherten Zahlungsdaten.
- **Chancen & wie sie von der Akzeptanz profitieren:** Ihr Nutzen ist direkt und
  unmittelbar. Eine Lösung, die die Passkey-Akzeptanz für ihre Kernbenutzerkonten fördert:
    1. **Reduziert Betrug:** Verringert massiv die Angriffsfläche für Kontoübernahmen,
       eine Hauptquelle für finanzielle Verluste und Kundenunzufriedenheit.
    2. **Reduziert Reibung:** Schafft ein nahtloses und sicheres Login- und
       Checkout-Erlebnis, das nachweislich die Konversionsraten erhöht. Für diese Akteure
       ist eine Lösung, die die Passkey-Akzeptanz steigert, eine direkte Investition in
       die Sicherheit und Leistung ihres Kerngeschäfts im Handel. Sie sind daher
       Hauptkandidaten für eine solche Lösung.

## 12. Fazit

Die Zahlungsbranche steht am Beginn einer neuen Ära der Authentifizierung. Der langjährige
Kompromiss zwischen Sicherheit und Komfort wird endlich durch die Reifung und Einführung
der Passkey-Technologie aufgelöst. Die in diesem Bericht vorgestellte Analyse zeigt, dass
dies kein monolithischer Wandel ist, sondern ein komplexer Übergang mit mehreren
konkurrierenden Visionen für die Zukunft. Issuer versuchen, das bestehende 3DS-Framework
mit SPC zu verbessern; große Händler und PSPs wollen die Kontrolle über das Erlebnis durch
Delegated Authentication oder durch den Aufbau eigener Wallet-Ökosysteme übernehmen; und
die Kartennetzwerke schaffen mit Click to Pay eine neue, föderierte Identitätsschicht.
Jedes Modell wetteifert darum, der neue Standard für Benutzervertrauen und Komfort zu
werden.
