Scenario delle Passkey per i Pagamenti: 4 Modelli di Integrazione Principali

60-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

Il panorama globale dei pagamenti si trova a un punto di svolta cruciale. Per decenni, il settore ha dovuto affrontare la tensione intrinseca tra sicurezza e comodità per l'utente, una sfida sentita in modo particolarmente acuto nell'ambiente digitale, definito Card-Not-Present (CNP). L'aumento di frodi sofisticate ha reso necessarie misure di autenticazione più robuste, mentre le aspettative dei consumatori richiedono esperienze di checkout sempre più fluide. Questo report fornisce un'analisi completa di questo ecosistema in evoluzione, con un focus specifico sull'identificazione dei punti strategici di integrazione per la tecnologia passkey. È stato concepito per servire come guida definitiva per i fornitori di tecnologia, i fornitori di servizi di pagamento, le istituzioni finanziarie e gli esercenti che cercano di orientarsi nella transizione verso un futuro senza password.

Il settore dei pagamenti sta subendo un cambiamento fondamentale, spinto dalla necessità di una maggiore sicurezza come la Strong Customer Authentication (SCA) e dalla domanda commerciale di esperienze utente senza attriti. Le passkey resistenti al phishing sono emerse come la tecnologia chiave per risolvere questa tensione. La nostra analisi mostra che il settore sta convergendo verso quattro modelli architetturali distinti per l'integrazione delle passkey, ognuno dei quali rappresenta una visione competitiva per il futuro dell'autenticazione nei pagamenti:

1. Il Modello Issuer-Centric (ad es. tramite SPC): Sebbene tecnicamente elegante, questo modello è ostacolato da una critica mancanza di supporto da parte dei browser, in particolare da Apple, rendendolo una soluzione impraticabile nel prossimo futuro.
2. Il Modello Merchant-Centric (Autenticazione Delegata): Questo potente modello consente ai grandi esercenti di sfruttare le loro relazioni dirette con i clienti, spostando l'autenticazione a monte per creare un checkout fluido, ma comporta una responsabilità significativa e richiede una fiducia diretta da parte dell'emittente.
3. Il Modello Network-Centric (Click to Pay): Un'importante mossa strategica da parte dei circuiti di carte come Visa e Mastercard per dominare l'esperienza di checkout degli ospiti, offrendo ai consumatori una passkey portatile a livello di circuito.
4. Il Modello PSP-Centric (Wallet): Un modello dominante in cui i grandi Payment Service Provider come PayPal utilizzano le passkey per rendere sicura e snella l'esperienza all'interno dei loro vasti ed consolidati ecosistemi di wallet.

Ogni modello presenta una risposta diversa alla domanda strategica fondamentale: "Chi diventerà il Relying Party primario per i pagamenti?". Questo report analizza queste architetture concorrenti, mappandole rispetto agli attori dell'ecosistema per fornire una chiara roadmap per navigare nel futuro dell'autenticazione dei pagamenti.

Per capire dove e come le passkey possono essere integrate, è prima essenziale stabilire una mappa chiara e dettagliata degli attori dell'ecosistema dei pagamenti e dei loro ruoli distinti. Il flusso di una singola transazione online comporta una complessa interazione tra più entità, ognuna delle quali svolge una funzione specifica nel movimento di dati e fondi.

Al centro di ogni transazione ci sono cinque partecipanti fondamentali che costituiscono la base della catena del valore dei pagamenti.

1. Cliente / Titolare della Carta:

   • Descrizione: L'individuo o l'organizzazione che avvia un acquisto. Il titolare della carta ottiene una carta di pagamento (di credito o di debito) da una banca emittente ed è responsabile del rimborso di eventuali addebiti.
   • Obiettivo: Un'esperienza di checkout veloce, semplice e sicura.
   • Esempi: Qualsiasi individuo con un conto bancario e/o una carta di pagamento.

2. Esercente (Merchant):

   • Descrizione: L'azienda che vende beni o servizi e accetta pagamenti elettronici. Per farlo, l'esercente deve disporre dell'infrastruttura necessaria, tipicamente fornita da una banca acquirente o da un fornitore di servizi di pagamento (PSP), per accettare ed elaborare i pagamenti con carta.
   • Obiettivo: Massimizzare la conversione delle vendite riducendo al minimo l'attrito del checkout e mitigando le frodi.
   • Esempi: Un sito di e-commerce, un negozio di vendita al dettaglio, un servizio in abbonamento.

3. Banca Emittente (Issuer):

   • Descrizione: La banca o l'istituto finanziario del titolare della carta. L'emittente fornisce la carta di pagamento al cliente, si assume il rischio di credito associato ed è in ultima analisi responsabile dell'approvazione o del rifiuto di una transazione in base allo stato del conto del titolare e a una valutazione del rischio.
   • Obiettivo: Ricevere la richiesta di autorizzazione e inviare un codice di risposta attraverso i circuiti delle carte.
   • Esempi: Bank of America, Chase, Barclays.

4. Banca Acquirente (Acquirer):

   • Descrizione: La banca dell'esercente, nota anche come banca dell'esercente. L'acquirente gestisce il conto dell'esercente e facilita l'elaborazione delle transazioni con carta per conto dell'esercente.
   • Obiettivo: Ricevere i dettagli di pagamento dall'esercente, instradarli attraverso il circuito della carta fino all'emittente e, previa approvazione, versare i fondi sul conto dell'esercente.
   • Esempi: Wells Fargo Merchant Services, Worldpay (di FIS).

5. Circuiti delle Carte (Schemes):

   • Descrizione: La spina dorsale tecnologica che collega tutti gli altri partecipanti. Aziende come Visa, Mastercard, American Express e Discover gestiscono queste vaste reti. Non emettono carte né aprono conti per esercenti, ma forniscono l'infrastruttura critica, le regole e gli standard che governano le transazioni.
   • Obiettivo: Facilitare l'instradamento delle richieste di autorizzazione e la compensazione e il regolamento dei fondi tra emittenti e acquirenti.
   • Esempi: Visa, Mastercard, American Express.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Tra i partecipanti principali si trova un ecosistema complesso e spesso sovrapposto di fornitori di tecnologia e servizi. Comprendere le distinzioni tra questi intermediari è cruciale, poiché sono spesso i principali punti di integrazione per nuove tecnologie come le passkey. I confini tra questi ruoli si sono notevolmente assottigliati negli ultimi anni, poiché i fornitori moderni cercano di offrire soluzioni più complete e "tutto in uno".

1. Payment Gateway:

   • Descrizione: Un payment gateway è la tecnologia che funge da portale digitale sicuro per una transazione. Il suo ruolo primario è catturare i dati di pagamento sensibili del cliente dal sito web dell'esercente o dal sistema di punto vendita (POS), crittografarli e trasmetterli in modo sicuro al processore di pagamento o alla banca acquirente. È la "porta d'ingresso" della transazione, responsabile della trasmissione sicura dei dati ma non del movimento dei fondi stessi.
   • Obiettivo: Fornire agli esercenti un modo sicuro e affidabile per accettare pagamenti online.
   • Esempi: Authorize.net (una soluzione Visa), Braintree, Stripe Payment Gateway.

2. Payment Processor:

   • Descrizione: Un processore di pagamento è l'entità che esegue i messaggi di transazione tra le varie parti. Dopo aver ricevuto i dati sicuri dal payment gateway, il processore comunica con il circuito della carta e, di conseguenza, con le banche emittenti e acquirenti per facilitare l'autorizzazione e il regolamento della transazione. Si può pensare al processore come al motore operativo che gestisce la comunicazione tecnica necessaria per il pagamento, mentre il gateway è il canale sicuro per tale comunicazione.
   • Obiettivo: Eseguire in modo affidabile ed efficiente i messaggi di pagamento, gestire il regolamento delle transazioni e la risoluzione delle controversie tra le banche emittenti e acquirenti.
   • Esempi: First Data (ora Fiserv), TSYS, Worldpay.

3. Payment Service Provider (PSP):

   • Descrizione: Un Payment Service Provider è un'azienda che offre agli esercenti una soluzione completa e aggregata per accettare pagamenti elettronici. Un PSP moderno combina tipicamente le funzioni di un payment gateway e di un processore di pagamento, e spesso fornisce anche il conto esercente, tutto sotto un unico contratto. Questo modello "tutto in uno" semplifica notevolmente il processo per gli esercenti, che non devono più stabilire relazioni separate con un fornitore di gateway e una banca acquirente. In alcuni contesti, i PSP che aggregano vari metodi di pagamento per gli esercenti sono anche chiamati Payment Aggregator.
   • Obiettivo: Offrire agli esercenti una soluzione unica per tutte le loro esigenze di pagamento, astraendo la complessità e semplificando l'accettazione dei pagamenti.
   • Esempi: Stripe, Adyen, PayPal, Mollie.

4. Provider Account-to-Account (A2A) / Open Banking:

   • Descrizione: Questa è una categoria di fornitori di pagamento in rapida crescita che bypassa completamente i circuiti di carte tradizionali. I pagamenti A2A spostano i fondi direttamente dal conto bancario di un consumatore al conto bancario di un esercente. Ciò è spesso reso possibile dalle normative di "Open Banking" (come la PSD2 in Europa) che impongono alle banche di fornire un accesso sicuro tramite API ai dati dei conti dei clienti e ai servizi di avvio dei pagamenti per fornitori terzi autorizzati. Questi fornitori costruiscono interfacce user-friendly sopra queste API, consentendo ai consumatori di autenticarsi con la propria banca e approvare un pagamento in un flusso continuo.
   • Obiettivo: Offrire un'alternativa ai pagamenti con carta a basso costo e altamente sicura, eliminando le commissioni di interscambio e riducendo le frodi attraverso l'autenticazione a livello bancario.
   • Esempi: Trustly, Plaid, Tink, GoCardless, Fintecture.

Questo consolidamento di ruoli ha implicazioni profonde. Sebbene accademicamente distinti, in pratica, il singolo punto di contatto di un esercente è spesso un PSP che astrae la complessità delle relazioni sottostanti con gateway, processore e acquirente. Tuttavia, le capacità di questi PSP possono variare drasticamente. Un PSP che è semplicemente un rivenditore dei servizi di gateway di un'altra azienda ha capacità tecniche e interessi strategici molto diversi da un PSP full-stack con la propria infrastruttura di elaborazione e licenze di acquiring. Questa distinzione è importante quando si valutano le opportunità di integrazione per metodi di autenticazione avanzati.

Inoltre, un'analisi più approfondita del flusso di pagamento rivela un concetto fondamentale che chiarisce le motivazioni strategiche dietro le nuove tecnologie di autenticazione: il ruolo del Relying Party (RP). Nel contesto dell'autenticazione FIDO e delle passkey, il Relying Party è l'entità che è in ultima analisi responsabile della verifica dell'identità di un utente. In una transazione di pagamento standard, l'emittente si assume il rischio finanziario della frode ed è quindi il Relying Party predefinito; è sua la decisione di approvare o rifiutare il pagamento.

I modelli architetturali emergenti per l'integrazione delle passkey possono essere meglio compresi come una negoziazione strategica su chi agisce come Relying Party. Nel modello Secure Payment Confirmation (SPC), l'emittente rimane l'RP ma consente all'esercente di invocare la cerimonia di autenticazione. Nell'Autenticazione Delegata (DA), l'emittente delega esplicitamente la funzione di RP all'esercente o al suo PSP. E nel modello network-centric, Visa e Mastercard si posizionano essi stessi come un Relying Party federato per le transazioni di checkout degli ospiti. Pertanto, la domanda centrale per qualsiasi fornitore di pagamenti che considera l'integrazione delle passkey diventa:

La risposta indica direttamente l'opportunità di integrazione, il decisore chiave e l'obiettivo strategico sottostante.

Per fornire una chiara rappresentazione visiva di queste relazioni, è essenziale un diagramma di flusso che illustri il ciclo di vita del pagamento. Tale diagramma rappresenterebbe due percorsi distinti ma interconnessi:

1. Il Flusso di Dati (Autorizzazione): Questo percorso traccia il viaggio della richiesta di autorizzazione. Inizia con il cliente che invia i dettagli di pagamento sul sito dell'esercente, scorre attraverso il payment gateway fino al processore/acquirente, quindi attraverso il circuito della carta fino all'emittente per una decisione sul rischio, e infine, la risposta di approvazione o rifiuto viaggia fino all'esercente e al cliente. L'intero processo avviene in pochi secondi.

2. Il Flusso di Valore (Regolamento): Questo percorso illustra il movimento del denaro, che avviene dopo l'autorizzazione. Mostra le transazioni raggruppate che vengono compensate, con i fondi che fluiscono dall'emittente, attraverso il circuito, all'acquirente (meno le commissioni di interscambio), e infine vengono depositati sul conto dell'esercente, un processo che richiede tipicamente alcuni giorni lavorativi. (Elaborazione dei pagamenti: come funziona l'elaborazione dei pagamenti | Stripe)

Questa visualizzazione consente a qualsiasi partecipante dell'ecosistema di localizzare immediatamente la propria posizione e comprendere le proprie relazioni dirette e indirette con tutte le altre parti, preparando il terreno per un'analisi dettagliata di dove possono avvenire gli interventi di autenticazione.

sequenceDiagram
    participant C as Cliente
    participant M as Esercente
    participant P as Gateway/Acquirer
    participant N as Circuito Carta
    participant I as Emittente

    C->>M: 1. Invia Dettagli Pagamento
    M->>P: 2. Trasmette Dettagli in Sicurezza
    P->>N: 3. Richiesta di Autorizzazione
    N->>I: 4. Inoltra all'Emittente per Verifica
    I-->>N: 5. Risposta di Approvazione/Rifiuto
    N-->>P: 6. Inoltra Risposta
    P-->>M: 7. Inoltra Risposta
    M-->>C: 8. Conferma Ordine o Richiede Nuovo Pagamento

    M->>P: 9. Invia Lotto di Transazioni Approvate
    P->>N: 10. Richiesta di Compensazione
    N->>I: 11. Richiede Fondi all'Emittente
    I-->>N: 12. Trasferisce Fondi (meno commissioni interbancarie)
    N-->>P: 13. Accredita Fondi all'Acquirer
    P-->>M: 14. Deposita Fondi all'Esercente (meno commissioni di elaborazione)

Sebbene l'ecosistema dei pagamenti contenga attori di tutte le dimensioni, il mercato dell'elaborazione e dell'acquisizione è concentrato attorno a diversi grandi attori che variano per regione. I giganti globali spesso competono con forti campioni nazionali e regionali. La seguente tabella fornisce un'istantanea degli attori chiave in diverse aree geografiche.

Ogni acquisto online innesca una sequenza di eventi complessa e ad alta velocità che può essere suddivisa in due fasi principali: autorizzazione e regolamento. Sovrapposto a questo processo c'è un protocollo di sicurezza critico noto come 3-D Secure, che è centrale per comprendere le sfide moderne dell'autenticazione dei pagamenti online.

Integrate passkeys as Payment Provider via 3rd party SDK.

Read article

Il ciclo di vita di una singola transazione CNP comporta uno scambio di dati quasi istantaneo seguito da un trasferimento di fondi più lento.

L'autorizzazione è il processo di verifica che il titolare della carta abbia fondi o credito sufficienti per completare l'acquisto e che la transazione sia legittima. Questa fase si svolge in pochi secondi e segue un percorso preciso in più passaggi (Elaborazione dei pagamenti: come funziona l'elaborazione dei pagamenti | Stripe):

1. Avvio della Transazione: Il cliente seleziona i suoi articoli, procede al checkout e inserisce i dettagli della sua carta di pagamento (numero di carta, data di scadenza, CVV) nel modulo di pagamento online dell'esercente.

2. Trasmissione Sicura: Il sito web dell'esercente passa in modo sicuro queste informazioni al suo payment gateway. Il gateway crittografa i dati per proteggerli durante il transito.

3. Instradamento al Processore/Acquirente: Il gateway inoltra i dettagli della transazione crittografati al processore di pagamento e/o alla banca acquirente dell'esercente.

4. Comunicazione con il Circuito: L'acquirente invia la richiesta di autorizzazione al circuito di carte appropriato (ad es. Visa, Mastercard).

5. Verifica dell'Emittente: Il circuito della carta instrada la richiesta alla banca emittente del titolare della carta. I sistemi dell'emittente eseguono una serie di controlli: verificano la validità della carta, controllano il saldo disponibile o il limite di credito ed eseguono la transazione attraverso i loro motori di rilevamento delle frodi.

6. Risposta di Autorizzazione: Sulla base di questi controlli, l'emittente approva o rifiuta la transazione. Questa decisione, sotto forma di un codice di risposta, viene inviata indietro lungo lo stesso percorso: dall'emittente al circuito della carta, all'acquirente, al processore/gateway e infine al sito web dell'esercente.

7. Completamento: Se approvata, l'esercente completa la vendita e informa il cliente. Se rifiutata, l'esercente chiede al cliente un metodo di pagamento alternativo.

Il regolamento è il processo di spostamento effettivo del denaro dall'emittente all'esercente. A differenza dell'autorizzazione, questo non è istantaneo e di solito avviene in lotti. (Elaborazione dei pagamenti: come funziona l'elaborazione dei pagamenti | Stripe)

1. Raggruppamento: Alla fine della giornata lavorativa, l'esercente invia un file batch di tutte le sue autorizzazioni approvate al suo acquirente.
2. Compensazione: L'acquirente invia il batch al circuito della carta per la compensazione. Il circuito smista le transazioni e le inoltra alle rispettive banche emittenti.
3. Trasferimento di Fondi: Le banche emittenti trasferiscono i fondi per le transazioni approvate alla banca acquirente, meno le commissioni di interscambio, che sono commissioni che l'acquirente paga all'emittente per ogni transazione.
4. Deposito all'Esercente: L'acquirente deposita quindi i fondi sul conto dell'esercente, meno le proprie commissioni di elaborazione. L'intero processo di regolamento richiede solitamente 1-3 giorni lavorativi.

Sovrapposto a ogni transazione CNP c'è un protocollo di sicurezza critico noto come 3-D Secure (3DS). Gestito da EMVCo, il suo scopo è consentire all'emittente di autenticare il titolare della carta, ridurre le frodi e trasferire la responsabilità per i chargeback dall'esercente all'emittente.

Il 3DS moderno (chiamato anche 3DS2) funziona scambiando un ricco set di dati tra l'esercente e l'Access Control Server (ACS) dell'emittente. Questi dati consentono all'ACS di eseguire una valutazione del rischio, portando a due risultati:

• Flusso senza attrito: Se la transazione è considerata a basso rischio, viene approvata silenziosamente in background senza interazione da parte dell'utente. Questo è l'obiettivo per la maggior parte delle transazioni.
• Flusso con challenge: Se la transazione è ad alto rischio o richiesta da normative come la PSD2, all'utente viene attivamente richiesto di dimostrare la propria identità, tipicamente con un OTP o una notifica dell'app di banking.

Questa "challenge" è un importante punto di attrito e un campo di battaglia chiave per i tassi di conversione. L'obiettivo del settore è massimizzare i flussi senza attrito rendendo le challenge il più fluide possibile. È proprio questa challenge ad alto attrito che le passkey sono perfettamente posizionate per risolvere, trasformando un potenziale punto di fallimento in un passaggio sicuro e senza interruzioni.

graph TD
    A[Inizio: Cliente procede al pagamento] --> B{L'esercente avvia il controllo 3DS};
    B --> C[L'SDK dell'esercente invia dati dettagliati sulla transazione e sul dispositivo all'ACS dell'emittente];
    C --> D{Il motore di rischio dell'ACS analizza i dati};
    D --> E{La transazione è ad alto rischio o è richiesta la SCA?};
    subgraph Flusso senza Attrito
    E -- No --> F[Autenticazione approvata passivamente - Nessuna interazione dell'utente];
    end
    subgraph Flusso con Challenge
    E -- Sì --> G[All'utente viene richiesta una challenge di autenticazione];
    G --> H{L'utente completa la challenge? - es. OTP, Push su App, SPC/Passkey};
    H -- Sì --> I[Autenticazione Approvata];
    H -- No --> J[Autenticazione Fallita];
    end
    F --> K[La transazione procede con trasferimento di responsabilità all'emittente];
    I --> K;
    J --> L[La transazione viene bloccata];

L'avvento delle passkey, basate sullo standard WebAuthn resistente al phishing della FIDO Alliance, sta catalizzando una riprogettazione fondamentale dell'autenticazione dei pagamenti. Ciò avviene parallelamente a una potente tendenza del settore: gli esercenti stanno già adottando le passkey per l'autenticazione standard degli utenti (registrazione e login) per combattere le frodi di account takeover e migliorare l'esperienza utente. Questo investimento esistente crea una base naturale su cui costruire modelli di passkey specifici per i pagamenti.

In questo modello, la banca dell'utente (l'emittente) è il Relying Party (RP) finale per l'autenticazione. La passkey è legata al dominio della banca (ad es. banca.com) e l'utente si autentica direttamente con la propria banca per approvare una transazione. Questo modello ha due varianti principali, a seconda che il pagamento avvenga su circuiti di carte o tramite trasferimenti diretti da conto a conto.

In questo modello, la banca emittente mantiene il controllo dell'autenticazione e la passkey è crittograficamente legata al dominio dell'emittente (ad es. banca.com). Sebbene un semplice reindirizzamento al sito web della banca sia possibile, crea un'esperienza utente scadente.

Chi possiede la passkey? Nel modello Issuer-Centric, l'Emittente è il Relying Party (RP).

Volano di Adozione ed Effetti di Rete: La riutilizzabilità della passkey di un emittente crea un potente volano. Una volta che un utente crea una passkey per la propria banca, quella singola passkey può essere utilizzata per approvare senza problemi le transazioni con challenge presso qualsiasi esercente che utilizza il protocollo 3DS. Ciò aumenta il valore della carta dell'emittente sia per i consumatori (migliore UX) che per gli esercenti (maggiore conversione).

La soluzione progettata dal settore per questo è la Secure Payment Confirmation (SPC), uno standard web che consente a un esercente di chiamare la passkey della banca direttamente sulla pagina di checkout, evitando un reindirizzamento. Questo processo utilizza anche il dynamic linking per legare l'autenticazione ai dettagli della transazione, il che è cruciale per la SCA.

Il Difetto Strategico: Nonostante la sua eleganza tecnica, l'SPC non è una strategia praticabile oggi. Richiede un supporto del browser che non esiste in Safari di Apple. Senza Safari, l'SPC non può essere una soluzione universale, rendendola impraticabile per qualsiasi implementazione su larga scala.

sequenceDiagram
    participant U as Utente
    participant M as Sito Esercente
    participant I as ACS Emittente

    Note over M,I: Un controllo 3DS determina la necessità di una challenge.
    M->>I: Richiesta di Autorizzazione (Alto Rischio)
    I-->>M: Avvia Challenge SPC
    Note over U,M: Il browser mostra un prompt nativo all'utente.
    M->>U: Attiva API SPC per il dominio dell'emittente (es. banca.com)
    U->>U: L'utente si autentica con la biometria del dispositivo (Face ID, ecc.)
    U-->>M: Il browser riceve l'asserzione firmata per banca.com
    M->>I: Inoltra l'asserzione firmata per la convalida
    I-->>M: Autenticazione Riuscita

Mentre i modelli precedenti sono incentrati sull'ecosistema delle carte, i pagamenti Account-to-Account (A2A), potenziati dall'Open Banking, presentano un paradigma potente e distinto. Questo modello bypassa completamente i circuiti delle carte e la sua integrazione con le passkey è singolarmente semplice ed efficace.

In questo modello, l'utente si autentica direttamente con la propria banca per approvare un pagamento. L'attrito di questo processo — che spesso comporta un goffo reindirizzamento e un login con password — è stato una barriera importante all'adozione dell'A2A. Le passkey risolvono direttamente questo problema fondamentale.

Chi possiede la passkey? La Banca è il Relying Party (RP). La passkey è quella che l'utente ha già creato per il suo online banking quotidiano con lamiabanca.com.

Volano di Adozione ed Effetti di Rete: Il volano è immenso e guidato dalle banche stesse. Man mano che le banche incoraggiano i loro utenti a passare dalle password alle passkey per accedere alla loro app o sito web bancario principale, quelle passkey sono automaticamente pronte per essere utilizzate per qualsiasi pagamento Open Banking. L'utente non deve fare nulla di più. Ciò rende il flusso di pagamento A2A semplice come una scansione biometrica, aumentandone drasticamente l'attrattiva e la competitività rispetto alle carte.

Come funziona:

1. Al checkout, l'utente seleziona un provider A2A (ad es. Trustly, Plaid) o la propria banca.
2. All'utente viene richiesto di autorizzare il pagamento con la propria banca.
3. La banca, in qualità di RP, avvia una challenge di autenticazione con passkey.
4. L'utente si autentica con Face ID, impronta digitale o PIN.
5. La banca conferma in modo sicuro il pagamento e i fondi vengono trasferiti direttamente sul conto dell'esercente.

Questo modello non rientra negli altri quattro perché non coinvolge un circuito di carte, 3DS, SPC o Autenticazione Delegata. È un flusso incentrato sulla banca in cui il provider A2A agisce come livello di orchestrazione tra l'esercente e il sistema di autenticazione della banca stessa, ora abilitato alle passkey.

sequenceDiagram
    participant U as Utente
    participant M as Sito Esercente
    participant A2A as Provider A2A (es. Trustly)
    participant B as Banca dell'Utente

    U->>M: Seleziona "Paga dalla Banca"
    M->>A2A: Avvia Pagamento A2A
    A2A->>U: Chiede all'utente di selezionare la propria banca
    U->>A2A: Seleziona la Banca
    A2A->>B: Richiede Autorizzazione al Pagamento
    Note over B,U: La banca richiede all'utente l'autenticazione con passkey
    U->>B: Si autentica con Passkey per lamiabanca.com
    B-->>A2A: Autenticazione Riuscita, Pagamento Autorizzato
    A2A-->>M: Conferma Pagamento
    M-->>U: Conferma Ordine

L'Autenticazione Delegata rappresenta un allontanamento più radicale dal modello tradizionale. Abilitata dalla versione 2.2 di 3DS e supportata da specifici programmi dei circuiti di carte, la DA è un framework in cui un emittente può delegare formalmente la responsabilità di eseguire la SCA a una terza parte fidata, più comunemente un grande esercente, un PSP o un fornitore di wallet digitali.

Chi possiede la passkey? In questo modello, l'Esercente o il suo PSP è il Relying Party (RP). La passkey viene creata per il dominio dell'esercente (ad es. amazon.com) e viene utilizzata per il login all'account.

Per qualificarsi per la DA, l'autenticazione iniziale eseguita dall'esercente deve essere pienamente conforme ai requisiti SCA. Secondo le linee guida dell'Autorità Bancaria Europea sulla Strong Customer Authentication, non si tratta di un semplice login; deve avere la stessa forza di un'autenticazione che l'emittente stesso eseguirebbe. Le passkey, con le loro forti proprietà crittografiche, sono una tecnologia ideale per soddisfare questo elevato standard. Tuttavia, un punto cruciale di incertezza normativa rimane riguardo alle passkey sincronizzate. Mentre le passkey legate al dispositivo soddisfano chiaramente l'elemento di "possesso" della SCA, le autorità di regolamentazione come l'EBA non hanno ancora emesso un parere definitivo sul fatto che le passkey sincronizzate, che sono portatili attraverso l'account cloud di un utente, soddisfino il requisito stringente di essere univocamente legate a un singolo dispositivo. Questa è una considerazione chiave per qualsiasi strategia di DA in Europa.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

In questo modello, l'evento di autenticazione si sposta a monte nel percorso del cliente. Invece di verificarsi alla fine del processo di checkout come una challenge 3DS, avviene all'inizio, quando il cliente accede al proprio account sul sito web o sull'app dell'esercente. Se l'esercente utilizza una passkey per il login, può passare la prova di questa autenticazione riuscita e conforme alla SCA all'emittente all'interno dello scambio di dati 3DS. L'emittente, avendo pre-stabilito una relazione di fiducia con quell'esercente, può quindi utilizzare queste informazioni per concedere un'esenzione e bypassare completamente il proprio flusso di challenge. Ciò può portare a un checkout biometrico veramente fluido e con un solo clic per gli utenti che hanno effettuato l'accesso.

Volano di Adozione ed Effetti di Rete: Il volano qui è guidato dalla relazione diretta dell'esercente con il cliente. Man mano che gli esercenti adottano le passkey per il login per ridurre le frodi di account takeover e migliorare l'UX, costruiscono una base di utenti abilitati alle passkey. Ciò crea un percorso naturale per sfruttare queste passkey per la DA nei pagamenti, sbloccando un'esperienza di checkout superiore. L'effetto di rete è più forte per i PSP che possono agire come RP per più esercenti, consentendo potenzialmente a una singola passkey di essere utilizzata in una rete di negozi, creando un potente incentivo per altri esercenti ad aderire all'ecosistema di quel PSP.

I circuiti di carte stanno attivamente promuovendo questo modello attraverso programmi dedicati. Il framework Guide Authentication di Visa, ad esempio, è progettato per essere utilizzato con la DA per consentire agli esercenti di eseguire la SCA per conto dell'emittente. Allo stesso modo, il programma Identity Check Express di Mastercard consente agli esercenti di autenticare il consumatore all'interno del flusso dell'esercente stesso. Questo modello riflette la visione strategica dei grandi esercenti e PSP:

Tuttavia, questo potere comporta responsabilità. Secondo le normative europee, la DA è trattata come "outsourcing", il che significa che l'esercente o il PSP si assume la responsabilità per le transazioni fraudolente e deve aderire a rigorosi requisiti di conformità e gestione del rischio.

sequenceDiagram
    participant U as Utente
    participant M as Sito Esercente
    participant I as ACS Emittente

    Note over U,M: Passaggio 1: L'utente accede al sito dell'esercente.
    U->>M: Si autentica con passkey per esercente.com
    M-->>U: Login Riuscito (la SCA è stata eseguita)

    Note over U,I: Passaggio 2: Successivamente, al checkout...
    U->>M: Clicca su "Paga"
    M->>I: Richiesta di Autorizzazione (inclusa prova di SCA precedente)
    I->>I: Verifica la prova di autenticazione delegata
    I-->>M: Approva Transazione (Nessuna challenge 3DS necessaria)

Questo modello è una grande iniziativa strategica guidata dai circuiti di carte (Visa, Mastercard) per possedere e standardizzare l'esperienza di checkout degli ospiti. Hanno costruito i propri servizi di passkey basati su FIDO, come il Visa Payment Passkey Service, sopra il framework Click to Pay.

Chi possiede la passkey? Nel modello Network-Centric, il Circuito della Carta è il Relying Party. La passkey viene creata per il dominio del circuito (ad es. visa.com).

Volano di Adozione ed Effetti di Rete: Questo modello possiede l'effetto di rete più potente. Una singola passkey creata per un circuito di carte è istantaneamente riutilizzabile presso ogni esercente che supporta Click to Pay, creando un immenso valore per il consumatore e guidando un classico volano di mercato a due facce.

sequenceDiagram
    participant U as Utente
    participant M as Sito Esercente
    participant N as Circuito Carta (Click to Pay)
    participant I as Emittente

    Note over M,U: Flusso di Checkout Ospite
    U->>M: Clicca il pulsante "Click to Pay"
    M->>N: Avvia il flusso Click to Pay
    Note over N,U: All'utente viene richiesto di autenticarsi al Circuito.
    N->>U: Il browser attiva il prompt della passkey per network.com
    U->>U: L'utente si autentica con la biometria del dispositivo
    U-->>N: Asserzione firmata restituita al Circuito
    N->>N: Convalida l'utente, recupera il token della carta memorizzato
    N->>I: Richiesta di Autorizzazione con token del circuito
    I-->>N: Approva/Rifiuta
    N-->>M: Invia la risposta di autorizzazione all'esercente

Questo modello è incentrato sui grandi Payment Service Provider (PSP) che gestiscono i propri wallet rivolti ai consumatori, come PayPal o Stripe (con Link). In questo approccio, il PSP è il Relying Party e possiede l'intero flusso di autenticazione e pagamento.

Chi possiede la passkey? Nel modello PSP-Centric, il PSP è il Relying Party (RP). La passkey viene creata per il dominio del PSP (ad es. paypal.com) e protegge l'account dell'utente all'interno dell'ecosistema di quel PSP.

Volano di Adozione ed Effetti di Rete: Anche questo modello ha un effetto di rete estremamente forte. Una passkey creata per il wallet di un importante PSP è riutilizzabile presso ogni esercente che accetta quel PSP, creando un potente incentivo per utenti ed esercenti ad aderire all'ecosistema del PSP.

sequenceDiagram
    participant U as Utente
    participant M as Sito Esercente
    participant P as PSP / Wallet (es. PayPal)

    U->>M: Seleziona "Paga con PSP" al Checkout
    M->>U: Reindirizza o mostra un popup per il login al PSP
    Note over P,U: L'utente si autentica direttamente al PSP
    U->>P: Si autentica con Passkey per psp.com
    P-->>U: Autenticazione Riuscita
    P-->>M: Invia Garanzia di Pagamento / OK all'Esercente
    M-->>U: Conferma Ordine

Una domanda comune e critica è se una passkey creata per un modello possa essere riutilizzata in un altro. Ad esempio, una passkey che un utente crea per la propria banca da utilizzare con SPC può essere usata per accedere al sito web di un esercente in un flusso DA? La risposta è no, e ciò evidenzia il ruolo centrale del Relying Party (RP).

Una passkey è fondamentalmente una credenziale crittografica che lega un utente a un RP specifico. La chiave pubblica è registrata sui server dell'RP e la chiave privata rimane sul dispositivo dell'utente. L'autenticazione è l'atto di dimostrare il possesso di quella chiave privata a quello specifico RP.

• Nel modello Issuer-Centric (SPC), l'RP è l'Emittente (ad es. chase.com). La passkey è registrata presso la banca.
• Nel modello Merchant-Centric (DA), l'RP è l'Esercente o il suo PSP (ad es. amazon.com o stripe.com). La passkey è registrata presso l'esercente per il login.
• Nel modello Network-Centric, l'RP è il Circuito della Carta (ad es. visa.com). La passkey è registrata presso il circuito per Click to Pay.
• Nel modello PSP-Centric, l'RP è il Payment Service Provider (ad es. paypal.com). La passkey è registrata presso il wallet o il servizio del PSP.

Poiché la passkey è crittograficamente legata al dominio dell'RP, una passkey registrata con chase.com non può essere convalidata da amazon.com. Sono identità digitali distinte da un punto di vista tecnico. Un utente dovrà creare una passkey separata per ogni Relying Party con cui interagisce.

La "riutilizzabilità" e la "portabilità" che rendono potenti le passkey derivano da due aree:

1. Sincronizzazione delle Passkey: Servizi come iCloud Keychain e Google Password Manager sincronizzano le passkey tra i dispositivi di un utente. Quindi, una passkey creata per chase.com su un telefono è automaticamente disponibile sul laptop dell'utente, ma è sempre e solo per chase.com.
2. Federazione: Questo è il modello utilizzato da Click to Pay. Un esercente può fidarsi del Circuito (ad es. Visa) per autenticare l'utente. L'utente si autentica a Visa (l'RP) e Visa segnala quindi all'esercente che l'utente è legittimo. Questo è analogo a "Accedi con Google", dove un sito web si fida di Google per gestire il login. La passkey non viene riutilizzata dall'esercente; è l'evento di autenticazione che viene riutilizzato.

Pertanto, i quattro modelli non sono solo percorsi tecnici diversi, ma strategie di identità concorrenti. Ognuno propone un'entità diversa come Relying Party primario per l'autenticazione dei pagamenti, e gli utenti probabilmente finiranno per avere passkey per i loro emittenti, esercenti preferiti, wallet PSP e circuiti di carte.

Mentre questi modelli offrono nuovi e potenti modi per autenticare, introducono anche una sfida operativa critica che viene spesso trascurata: il ripristino delle passkey e il recupero dell'account. Le passkey sincronizzate, gestite da piattaforme come iCloud Keychain e Google Password Manager, mitigano il problema di un singolo dispositivo perso. Tuttavia, non risolvono il problema di un utente che perde tutti i suoi dispositivi o passa da un ecosistema all'altro (ad es. da iOS ad Android). In questi scenari, un processo sicuro e user-friendly per consentire all'utente di dimostrare la propria identità con altri mezzi e registrare una passkey su un nuovo dispositivo è un prerequisito non negoziabile per qualsiasi implementazione su larga scala. Come nota la stessa documentazione di Mastercard, un utente che cambia dispositivo dovrà creare una nuova passkey, un processo che potrebbe richiedere la convalida dell'identità da parte della sua banca. (Mastercard® payment passkeys – Domande frequenti) Ciò evidenzia che una soluzione completa di passkey deve comprendere non solo la cerimonia di autenticazione stessa, ma anche l'intero ciclo di vita della gestione delle passkey, inclusi robusti flussi di recupero.

I quattro modelli architetturali - Issuer-Centric (SPC), Merchant-Centric (DA), Network-Centric (Click to Pay) e PSP-Centric - si traducono in distinte opportunità di integrazione per i diversi attori dell'ecosistema dei pagamenti. Ogni approccio presenta un insieme unico di compromessi tra esperienza utente, complessità di implementazione, responsabilità e controllo. Questa sezione fornisce un'analisi pragmatica di questi punti di integrazione per guidare il processo decisionale strategico.

• Opportunità: L'opportunità principale per gli emittenti e i provider di Access Control Server (ACS) che li servono è migliorare il "flusso di challenge" 3DS sostituendo metodi legacy come OTP e password con la Secure Payment Confirmation (SPC).
• Target Prospect: Questa integrazione è rivolta ai provider di ACS (ad es. Netcetera, CA Technologies/Arcot), ai fornitori di tecnologia che servono il settore degli emittenti e alle grandi banche emittenti che gestiscono le proprie piattaforme ACS interne.
• Ruolo del Provider: Un fornitore di passkey-as-a-service come Corbado offrirebbe un server FIDO o un modulo software integrabile, pienamente conforme alla specifica SPC. Questo modulo verrebbe integrato nella piattaforma ACS principale, consentendo all'ACS di avviare un flusso SPC quando il suo motore di rischio determina che è necessaria una challenge.
• Pro:
  • Alta Sicurezza e Conformità Normativa: L'uso del dynamic linking crittografico da parte dell'SPC fornisce una prova forte e verificabile del consenso dell'utente per dettagli specifici della transazione, affrontando direttamente i requisiti chiave di normative come la SCA della PSD2.
  • Migliore Esperienza Utente rispetto agli OTP: Autenticarsi con una rapida scansione biometrica è significativamente più veloce e meno soggetto a errori rispetto all'inserimento manuale di un codice ricevuto via SMS, il che può portare a un aumento misurabile dei tassi di conversione delle challenge.
  • Modello di Responsabilità Chiaro: Questo modello si inserisce perfettamente nel framework 3DS esistente. Quando una transazione viene autenticata con successo tramite SPC, la responsabilità per i chargeback fraudolenti si sposta dall'esercente all'emittente, proprio come accade con altri metodi di challenge 3DS.
• Contro:
  • Ancora un Flusso di "Challenge": Sebbene l'SPC migliori l'esperienza della challenge, non la elimina. L'utente viene comunque interrotto al checkout con un passaggio di autenticazione. Questa esperienza, sebbene migliore, è intrinsecamente più frizionale di un flusso "frictionless" completamente passivo o di un flusso di Autenticazione Delegata riuscito.
  • Dipendente dalla Logica di Rischio dell'Emittente: L'adozione e la frequenza d'uso dell'SPC dipendono interamente dall'ACS dell'emittente e dal suo motore RBA. L'ACS decide ancora se e quando avviare una challenge.
  • Ritardo nella Prontezza dell'Ecosistema: L'uso diffuso richiede che l'ecosistema adotti EMV 3DS versione 2.3 o superiore e che i browser degli utenti supportino l'API Web SPC. Come discusso, la mancanza di supporto universale, specialmente su piattaforme mobili come iOS, è un inibitore significativo.

• Opportunità: Implementare l'Autenticazione Delegata (DA), consentendo all'esercente o al suo PSP di eseguire la SCA al momento del login del cliente, creando così un'esperienza di checkout completamente fluida per gli utenti di ritorno e autenticati.
• Target Prospect: Questo è più rilevante per i grandi esercenti di e-commerce, i PSP full-stack (come Stripe o Adyen) e i fornitori di wallet digitali che hanno una relazione diretta con il consumatore e hanno già investito in un sistema di account e login sicuro.
• Ruolo del Provider: Un fornitore di passkey fornirebbe la soluzione di autenticazione passkey di base per il flusso di login dell'esercente. Fondamentalmente, la soluzione deve anche fornire gli output di dati e le prove crittografiche necessarie che possono essere impacchettate nella richiesta di autenticazione 3DS per segnalare all'emittente che una SCA conforme è già avvenuta.
• Pro:
  • Esperienza Utente Ottimale: Questo modello offre il flusso di pagamento più fluido possibile per gli utenti autenticati. Sposta il passaggio di autenticazione in una parte naturale e familiare del percorso dell'utente (login all'account) e può eliminare completamente la challenge 3DS, consentendo un vero checkout con un solo clic.
  • Potenziale di Conversione più Elevato: Rimuovendo il punto finale di attrito al checkout, la DA ha il potenziale per fornire l'aumento più significativo dei tassi di conversione dei pagamenti. Un progetto pilota di Stripe con i titolari di carte Wise ha riportato un aumento della conversione del 7% per le transazioni che utilizzano la loro soluzione DA.
  • Rafforza la Relazione Esercente-Cliente: L'intera esperienza di autenticazione e checkout rimane all'interno dell'ambiente brandizzato dell'esercente, rafforzando la loro relazione diretta con il cliente.
• Contro:
  • Complessità Commerciale e di Responsabilità: La DA non è un semplice interruttore tecnico. Richiede accordi espliciti, spesso bilaterali, tra gli emittenti e gli esercenti/PSP che scelgono di fidarsi. Inoltre, la parte che esegue l'autenticazione delegata si assume la responsabilità per le frodi, e l'accordo è soggetto a una rigorosa supervisione normativa come forma di "outsourcing", che comporta un onere di conformità significativo.
  • Dipendente dalla Fiducia dell'Emittente: L'intero modello si basa sulla volontà di un emittente di fidarsi del processo di autenticazione dell'esercente. Questa fiducia sarà probabilmente estesa inizialmente solo ai partner più grandi, sicuri e strategici.
  • Adozione Frammentata: A differenza di uno standard universale, la DA sarà adottata su base per-emittente, per-esercente, portando a un panorama frammentato in cui l'esperienza non è coerente per tutti i titolari di carta presso tutti gli esercenti.

• Opportunità: Abilitare l'esperienza passkey brandizzata dal circuito per l'enorme volume di transazioni di checkout degli ospiti.
• Target Prospect: Payment Gateway e PSP che desiderano offrire una soluzione di checkout per ospiti moderna e standardizzata alla loro base di clienti esercenti.
• Ruolo del Provider: Il provider può agire come un partner di integrazione cruciale. Dato che Visa e Mastercard hanno sviluppato servizi di passkey separati e proprietari, un fornitore di passkey può offrire un SDK unificato o un "livello di orchestrazione" che astrae le complessità dell'integrazione con le API distinte di ciascun circuito, fornendo un unico punto di integrazione semplificato per il PSP.
• Pro:
  • Soluzione di Checkout per Ospiti Standardizzata: Click to Pay con passkey risolve un importante punto dolente del settore: il checkout degli ospiti ad alto attrito e alto abbandono. Offre un'esperienza coerente, riconoscibile e fidata.
• Adozione Guidata dal Circuito: Visa e Mastercard stanno mettendo tutto il loro peso dietro questa iniziativa, il che guiderà una rapida adozione da parte di emittenti, esercenti e consumatori. I PSP subiranno pressioni competitive per supportarla.
• Onere di Responsabilità e Sicurezza Semplificato: Il circuito di carte, agendo come Relying Party federato, si assume l'onere primario di costruire e proteggere l'infrastruttura di autenticazione FIDO, semplificando la postura di sicurezza e responsabilità per l'esercente.
• Contro:
  • Perdita di Controllo e Branding: Lo svantaggio principale è che l'esercente e il suo PSP cedono il controllo sull'esperienza utente del checkout al circuito di carte. Il checkout diventa un "checkout Visa" o un "checkout Mastercard", con il loro branding e la loro interfaccia utente.
  • Potenziale di Disintermediazione: Diventando il fornitore di identità centrale per l'e-commerce, i circuiti potrebbero indebolire nel tempo la relazione diretta di dati e branding tra l'esercente e il cliente.
  • Implementazione "Black Box": Il funzionamento interno del server FIDO del circuito, dei motori di rischio e della logica di autenticazione è opaco per l'esercente e il PSP. Si stanno integrando con un servizio le cui regole e la cui esperienza utente non controllano.

La transizione all'autenticazione dei pagamenti basata su passkey non è un esercizio teorico; è attivamente guidata dai più grandi attori del settore. Le loro strategie, i programmi pilota e le dichiarazioni pubbliche forniscono una visione chiara delle dinamiche competitive e della probabile traiettoria di adozione.

Become part of our Passkeys Community for updates & support.

Join

• PayPal: In qualità di membro fondatore della FIDO Alliance e fornitore di pagamenti nativo digitale, PayPal è stato uno dei primi e più aggressivi ad adottare le passkey. Hanno iniziato un lancio globale graduale alla fine del 2022, partendo dagli Stati Uniti e espandendosi in Europa e altre regioni. La loro implementazione è un caso di studio di best practice, sfruttando funzionalità come la Conditional UI per creare un'esperienza di login con un tocco che richiede automaticamente una passkey quando l'utente interagisce con il campo di login. PayPal ha riportato un significativo successo iniziale, inclusi tassi di successo di login aumentati e una sostanziale riduzione delle frodi di account takeover (ATO). La loro strategia include anche la promozione attiva dell'evoluzione normativa in Europa, spingendo per un approccio alla SCA basato sui risultati che riconosca la sicurezza intrinseca delle passkey sincronizzate.

• Visa: La strategia di Visa è incentrata sul suo Visa Payment Passkey Service, una piattaforma completa costruita sulla propria infrastruttura di server FIDO. Questo servizio è progettato come un modello federato, in cui Visa gestisce la complessità dell'autenticazione per conto dei suoi partner emittenti. Il veicolo principale per questo servizio è Click to Pay, posizionando Visa per dominare l'esperienza di checkout degli ospiti. La comunicazione di Visa si estende oltre i semplici pagamenti, inquadrando il loro servizio di passkey come un elemento fondamentale di una soluzione di identità digitale più ampia che può essere utilizzata in tutto l'ecosistema del commercio. Stanno attivamente testando la tecnologia, inclusa la SPC, e riferiscono che l'autenticazione biometrica può ridurre i tassi di frode del 50% rispetto agli OTP via SMS.

• Mastercard: Mastercard ha rispecchiato il focus strategico di Visa su un servizio a livello di circuito, lanciando il proprio Payment Passkey Service basato sul suo esistente Token Authentication Service (TAS). La loro strategia go-to-market è stata caratterizzata da una serie di progetti pilota globali di alto profilo. Nell'agosto 2024, hanno annunciato un importante progetto pilota in India, collaborando con i più grandi aggregatori di pagamento del paese (Juspay, Razorpay, PayU), un importante esercente online (bigbasket) e una banca leader (Axis Bank). A questo sono seguiti lanci in altri mercati chiave, tra cui l'America Latina con i partner Sympla e Yuno e gli Emirati Arabi Uniti con Tap Payments. Questo approccio rivela una strategia chiara: collaborare con gli aggregatori dell'ecosistema (PSP, gateway) per raggiungere rapidamente la scala. Mastercard ha assunto un audace impegno pubblico per eliminare gradualmente l'inserimento manuale della carta in Europa entro il 2030, passando interamente a transazioni tokenizzate e autenticate con passkey.

Le strategie di questi pionieri rivelano una dinamica critica. L'esperienza di checkout degli ospiti, storicamente un'area frammentata e ad alto attrito, è diventata la testa di ponte strategica per i circuiti di carte. Creando una soluzione superiore e abilitata alle passkey per gli utenti ospiti tramite Click to Pay, i circuiti possono stabilire una relazione di identità diretta con i consumatori. Una volta che un consumatore crea una passkey a livello di circuito durante un checkout come ospite, quell'identità diventa portatile per ogni altro esercente che supporta Click to Pay. Ciò consente ai circuiti di "acquisire" efficacemente le identità degli utenti e offrire un'esperienza fluida su tutto il web, una mossa potente per catturare il ruolo centrale di fornitore di identità per il commercio digitale.

Gli sforzi concertati di questi grandi attori, combinati con le tendenze tecnologiche e normative più ampie, indicano un cambiamento accelerato e inevitabile nell'autenticazione dei pagamenti.

• La Fine Inevitabile degli OTP: La spinta a livello di settore per le passkey segna l'inizio della fine per i codici monouso basati su SMS come metodo di autenticazione primario. Gli OTP sono sempre più visti come una passività a causa sia della loro esperienza utente ad alto attrito sia della loro crescente vulnerabilità ad attacchi come il SIM swapping e sofisticate campagne di phishing. Man mano che le passkey diventeranno più diffuse, la dipendenza dagli OTP sarà relegata a un meccanismo di fallback o di recupero, piuttosto che a un metodo di challenge primario.

• Venti a Favore Normativi: Sebbene le normative attuali come la PSD2 abbiano creato il mandato iniziale per la SCA, le loro definizioni rigide e basate su categorie hanno creato una certa incertezza riguardo a nuove tecnologie come le passkey sincronizzate. Si prevede che i prossimi aggiornamenti normativi, come la PSD3 in Europa, adotteranno un approccio più neutrale dal punto di vista tecnologico e focalizzato sui risultati. Ciò favorirà probabilmente i metodi di autenticazione che sono dimostrabilmente resistenti al phishing, fornendo un percorso normativo più chiaro per l'ampia adozione delle passkey come metodo SCA conforme.

• L'Ascesa dell'Identità di Pagamento Federata: Le mosse strategiche di Visa e Mastercard non riguardano solo la sicurezza dei pagamenti; riguardano la creazione di un nuovo paradigma per l'identità digitale. Costruendo servizi di passkey federati, si stanno posizionando come i fornitori di identità centrali e fidati per l'intero ecosistema del commercio digitale. Questo può essere visto come una risposta strategica diretta alle potenti piattaforme di identità controllate dalla Big Tech (ad es. Apple ID, Google Account). Il futuro dei pagamenti online è inestricabilmente legato a questa battaglia più ampia su chi possiederà e gestirà l'identità del consumatore sul web.

Mentre la transazione di pagamento principale è il focus primario, la tecnologia passkey è pronta a eliminare l'attrito e migliorare la sicurezza in una vasta gamma di servizi finanziari adiacenti. Molti processi che si basano ancora su password o goffi OTP sono candidati ideali per un aggiornamento a passkey.

• Provisioning di Wallet Digitali: Il processo di aggiunta di una carta di credito o di debito a un wallet digitale come Apple Pay o Google Pay richiede spesso un passaggio di verifica, come un OTP via SMS inviato dall'emittente. Questo è un punto di attrito che può essere sostituito da un flusso passkey.
• Open Banking e Collegamento di Conti: Il fondamento dell'open banking è consentire ad applicazioni di terze parti (come app di budgeting o altri servizi fintech) di accedere ai dati del conto bancario di un utente. Ciò richiede che l'utente si autentichi con la propria banca, un processo che è spesso macchinoso. Le passkey offrono un modo molto più fluido e sicuro per concedere questo consenso, sostituendo goffi reindirizzamenti e l'inserimento manuale della password con una semplice autenticazione biometrica.
• Protezione dei Token Card-on-File (CoF): Oltre a proteggere semplicemente il login per un account con una carta salvata, le passkey possono essere utilizzate per proteggere l'atto iniziale di salvare la carta. Una challenge nel momento in cui un utente aggiunge la propria carta fornisce una forte prova che il legittimo titolare della carta è presente, riducendo le frodi derivanti dall'uso di numeri di carte di credito rubate per creare profili CoF per un uso improprio successivo.
• BNPL e Prestiti Istantanei: I servizi Buy Now, Pay Later e altre forme di credito istantaneo comportano sia un onboarding iniziale sia valutazioni del rischio per transazione. Le passkey sono già utilizzate da pionieri come Klarna per sostituire le password per il login. Possono anche essere utilizzate come metodo di autenticazione step-up per acquisti di alto valore o quando un utente richiede una nuova linea di credito, fornendo un segnale di intenzione dell'utente più forte e a minor attrito rispetto ai metodi tradizionali.

L'ascesa delle stablecoin (come USDC o EURC) presenta un nuovo canale di pagamento basato su blockchain. Tuttavia, una barriera importante all'adozione mainstream è stata la scarsa esperienza utente e la sicurezza dei wallet di criptovalute. Tradizionalmente, questi wallet sono protetti da una "seed phrase" (un elenco di 12-24 parole) che l'utente deve scrivere e proteggere. Questo è incredibilmente poco user-friendly e rende il recupero dell'account un incubo.

Le passkey sono destinate a trasformare completamente questa esperienza. Il settore si sta muovendo verso un modello in cui la chiave privata che controlla gli asset on-chain è protetta dalla passkey del dispositivo.

• Eliminare le Seed Phrase: Invece di scrivere una seed phrase, il wallet di un utente viene creato e protetto dalla sicurezza integrata del suo dispositivo. Per autorizzare una transazione, come l'invio di stablecoin a un esercente, l'utente si autentica semplicemente con Face ID o una scansione dell'impronta digitale. Ciò rende un pagamento in criptovaluta fluido e sicuro come l'uso di Apple Pay.
• Abilitare il Recupero dell'Account: Utilizzando architetture di wallet come gli "smart account" (o "account abstraction"), è possibile integrare meccanismi di recupero. Un utente potrebbe designare amici, familiari o istituzioni fidate come "guardiani" che possono aiutarlo a recuperare il proprio account se perde tutti i suoi dispositivi, un enorme miglioramento rispetto alla natura tutto-o-niente delle seed phrase.

Questa evoluzione potrebbe ridurre significativamente l'attrito e il rischio associati all'uso di stablecoin per i pagamenti, rendendoli potenzialmente un'alternativa più praticabile e mainstream ai canali di pagamento tradizionali.

L'analisi del panorama dei pagamenti e dei modelli emergenti di integrazione delle passkey rivela diverse opportunità distinte e attuabili. Per un'azienda di autenticazione passkey-first come Corbado, l'obiettivo è consentire a ogni attore dell'ecosistema di raggiungere i propri obiettivi strategici fornendo la tecnologia fondamentale necessaria per navigare in questa transizione.

• L'Obiettivo: Modernizzare il flusso di challenge 3DS, sostituendo gli OTP ad alto attrito per aumentare i tassi di conversione, migliorare la sicurezza e soddisfare la conformità PSD2/PSD3 in modo diretto.
• Come Aiuta Corbado: Forniamo un modulo di autenticazione passkey integrabile, progettato per una semplice integrazione nelle piattaforme Access Control Server (ACS) esistenti. Aiutiamo i fornitori di ACS a offrire un'esperienza di challenge di prima classe e a basso attrito che avvantaggia l'intera loro rete di banche ed esercenti.

• L'Obiettivo: Possedere il percorso del cliente end-to-end e offrire l'esperienza di checkout definitiva attraverso l'Autenticazione Delegata (DA), eliminando la challenge 3DS per gli utenti che hanno effettuato l'accesso.
• Come Aiuta Corbado: Corbado offre una soluzione completa per l'abilitazione della DA. Ciò include non solo un sistema di login con passkey di prima classe, ma anche gli strumenti e le API per generare le prove crittografiche richieste dagli emittenti per concedere le esenzioni DA. Agiamo come partner tecnologico, consentendo a esercenti e PSP di massimizzare la conversione e rafforzare il loro marchio.

• L'Obiettivo: Offrire senza sforzo le più recenti funzionalità richieste dai circuiti come Click to Pay e mantenere le piattaforme competitive senza costosi e duplicati sforzi di sviluppo.
• Come Aiuta Corbado: Corbado offre un livello di "Orchestrazione delle Passkey". Aiutiamo con l'integrazione dei servizi sia di Visa che di Mastercard e forniamo anche modi in cui gli esercenti possono offrire contemporaneamente la propria soluzione di passkey per offrire un moderno checkout per ospiti.

• L'Obiettivo: Proteggere l'intero ecosistema del wallet, creando un'esperienza di login e pagamento fluida e sicura che sia portatile attraverso l'intera rete di esercenti del PSP.
• Come Aiuta Corbado: Forniamo l'infrastruttura passkey di base che consente a grandi PSP e fornitori di wallet di diventare il Relying Party centrale per i loro utenti. Integrando la nostra soluzione, possono sostituire le password per i loro login al wallet (ad es. per PayPal, Stripe Link o Klarna). Ciò non solo protegge l'account dal takeover, ma snellisce anche l'autorizzazione del pagamento in un passaggio biometrico con un solo clic, creando un'esperienza di autenticazione potente e brandizzata che fidelizza gli utenti e attira gli esercenti.

Questa analisi evidenzia un fattore di successo critico per qualsiasi strategia basata su passkey: l'adozione da parte degli utenti. Una soluzione che può aumentare in modo dimostrabile la creazione e l'utilizzo delle passkey da una base di circa il 10% a oltre il 50% affronta la sfida principale che si presenta nel lancio di questi nuovi modelli di autenticazione. Sulla base dell'ecosistema e degli obiettivi strategici dei suoi attori, le seguenti organizzazioni e settori sono candidati ideali per una tale soluzione.

• Problema Principale: L'elevato attrito nel flusso di challenge 3DS porta a carrelli abbandonati e perdita di entrate per gli esercenti, rendendo la carta di un emittente meno competitiva.
• Come Aiuta l'Adozione: Una maggiore adozione delle passkey si traduce direttamente in challenge più riuscite e a basso attrito. Ciò migliora i tassi di conversione, aumenta la sicurezza e rende le credenziali di pagamento dell'emittente più preziose sia per gli esercenti che per i consumatori.
• Candidati Ideali: Grandi banche emittenti (Bank of America, Chase, Barclays) e i provider di ACS che forniscono la loro tecnologia 3DS (Netcetera, CA Technologies).

• Problema Principale: Il desiderio di possedere il percorso del cliente ed eliminare l'attrito del checkout è spesso bloccato dalla necessità di una challenge 3DS.
• Come Aiuta l'Adozione: L'intero modello di Autenticazione Delegata (DA) si basa sulla capacità dell'esercente di autenticare fortemente l'utente al momento del login. Un'elevata adozione delle passkey non è solo un miglioramento, ma un prerequisito per una strategia DA di successo. Abilitare la DA per la maggior parte degli utenti è un potente differenziatore competitivo.
• Candidati Ideali: Leader globali dell'e-commerce (Amazon, Walmart), servizi di abbonamento digitale (Netflix, Spotify) e i PSP full-stack che li servono (Stripe, Adyen, Checkout.com).

• Problema Principale: Il successo di servizi di identità strategici a livello di circuito come Click to Pay dipende direttamente da un'ampia adesione dei consumatori.
• Come Aiuta l'Adozione: Un'esperienza di creazione di passkey facile e attraente è essenziale per la crescita di queste reti di identità federate. I circuiti potrebbero integrare una soluzione incentrata sull'adozione negli SDK che forniscono a esercenti e PSP, accelerando il lancio e l'adozione dei loro servizi di passkey proprietari.
• Candidati Ideali: Visa (per il suo Visa Payment Passkey Service) e Mastercard (per il suo Token Authentication Service).

• Problema Principale: Il valore del wallet (ad es. PayPal, Stripe Link, Klarna) è direttamente legato al numero di utenti attivi e coinvolti. L'attrito al login o al checkout indebolisce l'ecosistema.
• Come Aiuta l'Adozione: Guidare l'adozione di massa delle passkey per il dominio proprio del wallet (paypal.com, ecc.) è un obiettivo strategico fondamentale. Riduce le frodi, migliora l'esperienza utente e rafforza l'effetto rete, rendendo il wallet più attraente sia per i consumatori che per gli esercenti.
• Candidati Ideali: PSP globali con offerte di wallet (PayPal, Stripe Link, Klarna) e grandi attori regionali (Mercado Pago, Block).

• Problema Principale: I circuiti di pagamento nazionali subiscono pressioni per modernizzare la loro infrastruttura e fornire soluzioni di identità digitale per rimanere competitivi rispetto alle aziende tecnologiche globali.
• Come Aiuta l'Adozione: Queste reti devono garantire che i loro nuovi servizi di pagamento e identità digitali vedano un uso diffuso. Per un attore come Australian Payments Plus (AP+), guidare l'adozione di servizi come PayTo (per pagamenti in tempo reale) e ConnectID (per l'identità digitale) è un obiettivo strategico fondamentale. Una soluzione che aumenta l'iscrizione alle passkey è un abilitatore diretto di questa strategia.
• Candidati Ideali: Australian Payments Plus (AP+) e altri organismi nazionali di infrastrutture di pagamento.

Le grandi aziende tecnologiche gestiscono sofisticati wallet digitali che svolgono un ruolo unico e potente nell'ecosistema dei pagamenti. Si trovano all'intersezione tra il dispositivo dell'utente, la loro identità di piattaforma e i canali di pagamento tradizionali, il che conferisce loro una posizione e una strategia distinte riguardo all'adozione delle passkey.

Apple Pay e Google Pay sono meglio compresi come un livello tecnologico e di autenticazione che si sovrappone all'infrastruttura esistente delle carte di pagamento. Non emettono carte né elaborano transazioni da soli, ma memorizzano e trasmettono in modo sicuro versioni tokenizzate delle carte di pagamento esistenti di un utente.

• Posizione nell'Ecosistema: Agiscono come un "contenitore" sicuro per le carte di un utente. Quando un utente paga online, invece di inserire i dettagli della propria carta, seleziona Apple Pay o Google Pay. Il wallet passa quindi un token sicuro e monouso al payment gateway dell'esercente. La transazione scorre comunque attraverso l'acquirente, il circuito e l'emittente come di consueto.
• Come Sfruttano le Passkey: Autenticano l'utente con la scansione del volto o dell'impronta digitale al wallet, autorizzandolo a rilasciare il token di pagamento. Questo è un evento di autenticazione potente e a basso attrito, ma è distinto dall'autenticazione 3DS/SCA di cui è responsabile l'emittente della carta. Un emittente può ancora tecnicamente avviare una challenge 3DS su una transazione avviata tramite Apple Pay, sebbene la forte autenticazione a livello di dispositivo renda ciò meno probabile.
• Opportunità e Come Beneficiano dell'Adozione:
  • Semplificare il Provisioning del Wallet: Il processo di aggiunta di una carta a un wallet richiede spesso un OTP dall'emittente. Questo è un punto chiave di attrito. Apple e Google potrebbero collaborare con gli emittenti per sostituirlo con un flusso passkey in-app, utilizzando una passkey per verificare istantaneamente l'utente. Una soluzione di adozione per i loro partner emittenti renderebbe i loro wallet più facili da caricare e utilizzare.
  • Diventare un'Autorità Delegata: Il loro obiettivo strategico finale è sfruttare la loro potente autenticazione di piattaforma per diventare l'autenticatore definitivo e fidato per i pagamenti. Se gli emittenti riconoscessero formalmente l'autenticazione di Apple Pay o Google Pay come conforme ai requisiti SCA, potrebbero diventare Autorità Delegate, eliminando completamente la challenge 3DS. Un'elevata adozione delle proprie passkey di piattaforma è fondamentale per rendere questa una proposta convincente per gli emittenti.

Amazon Pay e Meta Pay funzionano più come un esercente tradizionale con un wallet Card-on-File (CoF) molto grande che può essere utilizzato su siti di terze parti e all'interno dei loro stessi ecosistemi (ad es. per il social commerce su Instagram).

• Posizione nell'Ecosistema: Sono un classico esempio del modello Merchant-Centric. Gli utenti memorizzano le loro carte di pagamento direttamente nel loro account Amazon o Meta. Quando usano Amazon Pay o Meta Pay per il checkout, si stanno autenticando al loro account principale e quella piattaforma elabora il pagamento per loro conto.
• Come Sfruttano le Passkey: Il loro uso primario delle passkey è per proteggere il login all'account principale dell'utente (ad es. la passkey per Amazon.com). Spostando le loro vaste basi di utenti dalle password alle passkey per il login all'account, riducono drasticamente il rischio di frodi di account takeover e proteggono le preziose credenziali di pagamento memorizzate.
• Opportunità e Come Beneficiano dell'Adozione: Il loro beneficio è diretto e immediato. Una soluzione che guida l'adozione delle passkey per i loro account utente principali:
  1. Riduce le Frodi: Diminuisce massicciamente la superficie di attacco per l'account takeover, una delle principali fonti di perdite finanziarie e insoddisfazione dei clienti.
  2. Riduce l'Attrito: Crea un'esperienza di login e checkout fluida e sicura, che è dimostrato aumentare i tassi di conversione. Per questi attori, una soluzione che aumenta l'adozione delle passkey è un investimento diretto nella sicurezza e nelle prestazioni del loro core business commerciale. Sono quindi candidati ideali per una tale soluzione.

L'industria dei pagamenti è all'alba di una nuova era dell'autenticazione. Il compromesso di lunga data tra sicurezza e convenienza viene finalmente risolto dalla maturazione e dall'adozione della tecnologia passkey. L'analisi presentata in questo report dimostra che non si tratta di un cambiamento monolitico, ma di una transizione complessa con molteplici visioni concorrenti per il futuro. Gli emittenti cercano di migliorare il framework 3DS esistente con la SPC; i grandi esercenti e i PSP mirano a prendere il controllo dell'esperienza attraverso l'Autenticazione Delegata o costruendo i propri ecosistemi di wallet; e i circuiti di carte stanno creando un nuovo livello di identità federata con Click to Pay. Ogni modello è in lizza per diventare il nuovo standard di fiducia dell'utente e convenienza.