--- url: 'https://www.corbado.com/it/blog/scenario-passkey-pagamenti-panoramica' title: 'Scenario delle Passkey per i Pagamenti: 4 Modelli di Integrazione Principali' description: 'Esplora i 4 modelli principali per le passkey di pagamento. Confronta le architetture incentrate su emittenti, esercenti, circuiti e PSP per trovare la migliore strategia di integrazione.' lang: 'it' author: 'Vincent Delitz' date: '2025-07-15T13:23:55.150Z' lastModified: '2026-03-25T10:05:51.415Z' keywords: 'panoramica passkey di pagamento, scenario passkey di pagamento, modello di integrazione passkey di pagamento, modelli di autenticazione per pagamenti' category: 'Passkeys Strategy' --- # Scenario delle Passkey per i Pagamenti: 4 Modelli di Integrazione Principali ## 1. Introduzione Il panorama globale dei [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) si trova a un punto di svolta cruciale. Per decenni, il settore ha dovuto affrontare la tensione intrinseca tra [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) 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](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) 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](https://www.corbado.com/passkeys-for-payment), le istituzioni finanziarie e gli esercenti che cercano di orientarsi nella transizione verso un futuro senza password. ## 2. Sintesi Il settore dei [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) sta subendo un cambiamento fondamentale, spinto dalla necessità di una maggiore [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) come la [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA) e dalla domanda commerciale di esperienze utente senza attriti. Le passkey resistenti al [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) nei [pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet): 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](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) 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](https://www.corbado.com/blog/visa-passkeys) e [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys) utilizzano le passkey per rendere sicura e snella l'esperienza all'interno dei loro vasti ed consolidati ecosistemi di [wallet](https://www.corbado.com/blog/digital-wallet-assurance). Ogni modello presenta una risposta diversa alla domanda strategica fondamentale: "Chi diventerà il [Relying Party](https://www.corbado.com/glossary/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. ## 3. L'Ecosistema Moderno 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. ### 3.1 I Partecipanti Principali 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](https://www.corbado.com/passkeys-for-critical-infrastructure) necessaria, tipicamente fornita da una banca acquirente o da un [fornitore di servizi di pagamento](https://www.corbado.com/it/blog/passkey-fornitori-pagamento-sdk-terze-parti) (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](https://www.corbado.com/passkeys-for-e-commerce), un negozio di [vendita al dettaglio](https://www.corbado.com/passkeys-for-e-commerce), 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](https://www.corbado.com/glossary/merchant) Services, Worldpay (di FIS). 5. **Circuiti delle Carte (Schemes):** - **Descrizione**: La spina dorsale tecnologica che collega tutti gli altri partecipanti. Aziende come [Visa](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), 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](https://www.corbado.com/blog/visa-passkeys), [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), American Express. ### 3.2 Gli Intermediari: Chiarire il Panorama dei "Provider" 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](https://blog.finexer.com/payment-gateway-vs-psp-vs-payment-processor/) negli ultimi anni, poiché i fornitori moderni cercano di offrire soluzioni più complete e "tutto in uno". 1. **Payment Gateway:** - **Descrizione**: Un [payment](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/it/blog/passkey-visa). - **Esempi**: Authorize[.net](https://www.corbado.com/blog/passkeys-asp-net-core) (una soluzione Visa), Braintree, Stripe [Payment](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) è un'azienda che offre agli esercenti una soluzione completa e aggregata per accettare pagamenti elettronici. Un [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) 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](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) 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](https://www.corbado.com/blog/paypal-passkeys), 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](https://www.corbado.com/passkeys-for-banking)" (come la [PSD2](https://www.corbado.com/blog/psd2-passkeys) 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](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) 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](https://www.corbado.com/passkeys-for-critical-infrastructure) di elaborazione e licenze di acquiring. Questa distinzione è importante quando si valutano le opportunità di integrazione per metodi di autenticazione avanzati. ### 3.3 Ruolo del Relying Party (RP) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC), l'emittente rimane l'RP ma consente all'esercente di _invocare_ la cerimonia di autenticazione. Nell'[Autenticazione Delegata](https://www.corbado.com/it/blog/autenticazione-delegata-sca-psd3-passkey) (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: > "Chi è, o vuole essere, il Relying Party in questo flusso?" La risposta indica direttamente l'opportunità di integrazione, il decisore chiave e l'obiettivo strategico sottostante. > **Approfondimento:** Per un'introduzione dettagliata ai Relying Party nel contesto di > WebAuthn e passkey, leggi la nostra guida completa: WebAuthn Relying Party ID (rpID) & > Passkeys: Domini e App Native. ### 3.4 Visualizzare l'Ecosistema: Flusso di Dati e Valore 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](https://www.corbado.com/passkeys-for-travel) 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](https://stripe.com/resources/more/payment-processing-explained)) 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. ```mermaid 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) ``` | Attore | Funzione Principale | Responsabilità Chiave | Esempi Tipici | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | **Cliente / Titolare della Carta** | Avvia il pagamento per beni o servizi. | Fornisce le credenziali di pagamento; rimborsa gli addebiti all'emittente. | Un individuo che fa acquisti online. | | **Esercente** | Vende beni o servizi e accetta pagamenti elettronici. | Integra la tecnologia di accettazione dei pagamenti; gestisce l'esperienza di checkout. | Un sito di e-commerce o un negozio al dettaglio. | | **Banca Emittente (Issuer)** | Emette carte di pagamento ai clienti e si assume il rischio. | Autorizza o rifiuta le transazioni; gestisce i conti dei titolari di carta; addebita il titolare della carta. | Bank of America, Chase, Barclays. | | **Banca Acquirente (Acquirer)** | Fornisce agli esercenti la capacità di accettare pagamenti con carta. | Stabilisce e mantiene i conti degli esercenti; regola i fondi per l'esercente. | Wells Fargo Merchant Services, Worldpay (di FIS). | | **Circuiti delle Carte (Schemes):** | Gestisce le reti che collegano tutte le parti. | Stabilisce le tariffe e le regole di interscambio; instrada i messaggi di autorizzazione e regolamento. | Visa, Mastercard, American Express. | | **Payment Gateway** | Trasmette in modo sicuro i dati di pagamento dall'esercente al processore. | Crittografa i dati sensibili della carta; agisce come "porta d'ingresso" sicura per la transazione. | Authorize.net (una soluzione Visa), Stripe Payment Gateway. | | **Payment Processor** | Gestisce la comunicazione tecnica per la transazione. | Facilita lo scambio di informazioni tra l'acquirente, l'emittente e il circuito della carta. | First Data (ora Fiserv), TSYS. | | **Payment Service Provider (PSP)** | Offre una soluzione di pagamento completa e tutto in uno agli esercenti. | Raggruppa i servizi di gateway, elaborazione e conto esercente; semplifica l'accettazione dei pagamenti. | Stripe, Adyen, PayPal, Mollie. | | **Provider Account-to-Account (A2A) / Open Banking:** | Bypassa i circuiti di carte tradizionali per spostare i fondi direttamente dal conto bancario di un consumatore a quello di un esercente. | Fornisce un accesso sicuro tramite API ai dati dei conti dei clienti e ai servizi di avvio dei pagamenti per fornitori terzi autorizzati. | Trustly, Plaid, Tink, GoCardless, Fintecture. | ### 3.5 Leader di Mercato Regionali 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. | Regione | Entità | Tipo | | ------------------ | ---------------------------------------------------------------------------------------------------- | ------------------ | | **Nord America** | PayPal, Stripe, Block (Square), Adyen, Bill, Brex, Ria Money Transfer | PSP | | **Nord America** | Fiserv (Clover), Global Payments, JPMorgan Chase Merchant Services | Acquirer/Processor | | **Nord America** | Plaid | A2A/Open Banking | | **Europa** | Adyen, Stripe, PayPal, Checkout.com, Worldline, Nexi, Klarna, Mollie, Wise | PSP | | **Europa** | Worldpay (di FIS), Barclaycard | Acquirer/Processor | | **Europa** | Trustly, Brite Payments, Tink, GoCardless, Fintecture, Ivy | A2A/Open Banking | | **Europa** | iDEAL (Paesi Bassi), Bancontact (Belgio), Swish (Svezia) | Circuito Domestico | | **Asia-Pacifico** | Alipay & WeChat Pay (Cina), PhonePe & Paytm (India), GrabPay & GoTo (SEA), Razorpay, PayU, Airwallex | PSP | | **Asia-Pacifico** | Tyro Payments | Acquirer/Processor | | **Asia-Pacifico** | UPI (India), Australian Payments Plus (AP+) | Circuito Domestico | | **America Latina** | Mercado Pago, PagSeguro, StoneCo, EBANX | PSP | | **America Latina** | Cielo, Rede, Getnet (Brasile), Transbank (Cile), Prisma (Argentina) | Acquirer/Processor | | **America Latina** | Pix (Brasile) | Circuito Domestico | ## 4. Anatomia di una Transazione Card-Not-Present (CNP) e il Livello 3-D Secure 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](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) critico noto come [3-D Secure](https://www.corbado.com/glossary/3d-secure), che è centrale per comprendere le sfide moderne dell'autenticazione dei [pagamenti online](https://www.corbado.com/it/blog/passkey-visa). ### 4.1 Il Ciclo di Vita della Transazione: da "Paga" a "Pagato" Il ciclo di vita di una singola transazione [CNP](https://www.corbado.com/glossary/cnp) comporta uno scambio di dati quasi istantaneo seguito da un trasferimento di fondi più lento. #### 4.1.1 Autorizzazione 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](https://stripe.com/resources/more/payment-processing-explained)): 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. #### 4.1.2 Regolamento 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](https://stripe.com/resources/more/payment-processing-explained)) 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. ### 4.2 Il Livello di Sicurezza: EMV 3-D Secure (3DS) Sovrapposto a ogni transazione [CNP](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/psd2-passkeys), all'utente viene attivamente richiesto di dimostrare la propria identità, tipicamente con un OTP o una notifica dell'app di [banking](https://www.corbado.com/passkeys-for-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. > **Approfondimento:** Per un'analisi dettagliata del protocollo 3DS, del ruolo > dell'[ACS](https://www.corbado.com/glossary/acs) e di come i fornitori stanno integrando i dati FIDO, leggi la > nostra guida completa: > [EMV 3DS Access Control Server](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc): Passkey, FIDO > e [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc). ```mermaid 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]; ``` ## 5. La Rivoluzione delle Passkey nei Pagamenti: Architetture di Integrazione Principali L'avvento delle passkey, basate sullo standard WebAuthn resistente al [phishing](https://www.corbado.com/glossary/phishing) della [FIDO Alliance](https://www.corbado.com/glossary/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. ### 5.1 Il Modello Issuer-Centric 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. #### 5.1.1 L'Approccio Basato su Carta: Secure Payment Confirmation (SPC) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/it/blog/psd2-passkey). **Il Difetto Strategico:** Nonostante la sua eleganza tecnica, l'[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) non è una strategia praticabile oggi. Richiede un supporto del browser che non esiste in Safari di Apple. Senza Safari, l'[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) non può essere una soluzione universale, rendendola impraticabile per qualsiasi implementazione su larga scala. > **Approfondimento:** Per un'analisi tecnica completa dell'SPC, di come abilita il > [dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) e del perché il supporto del > browser sia un difetto critico, leggi la nostra analisi approfondita: > [Dynamic Linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) con le Passkey: > [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC). ```mermaid 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 ``` #### 5.1.2 L'Approccio A2A / Open Banking 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](https://www.corbado.com/faq/is-face-id-passkey), 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](https://www.corbado.com/it/blog/autenticazione-delegata-sca-psd3-passkey). È 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. ```mermaid 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 ``` ### 5.2 Il Modello Merchant-Centric: Autenticazione Delegata (DA) L'[Autenticazione Delegata](https://www.corbado.com/it/blog/autenticazione-delegata-sca-psd3-passkey) 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](https://www.corbado.com/it/blog/psd2-passkey) a una terza parte fidata, più comunemente un grande esercente, un PSP o un fornitore di [wallet](https://www.corbado.com/blog/digital-wallet-assurance) digitali. > Per maggiori approfondimenti sull'Autenticazione Delegata e le passkey, leggi il nostro > post sul blog: Autenticazione Delegata e Passkey sotto [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) / > [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) - Corbado **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](https://www.corbado.com/it/blog/psd2-passkey). Secondo le linee guida dell'Autorità [Bancaria](https://www.corbado.com/passkeys-for-banking) Europea sulla [Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance), 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. 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](https://usa.visa.com/products/guide-authentication.html), 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](https://developer.mastercard.com/product/delegated-authentication-for-merchants/). Questo modello riflette la visione strategica dei grandi esercenti e PSP: > "Noi possediamo la relazione primaria con il cliente e abbiamo già investito in > un'esperienza di login sicura e a basso attrito. Lasciate che ci occupiamo noi > dell'autenticazione per creare il miglior percorso utente possibile." 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. ```mermaid 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) ``` ### 5.3 Il Modello Network-Centric: Click to Pay e Servizi di Passkey Federati 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. > **Approfondimento:** Sia Visa che Mastercard stanno perseguendo questa strategia in modo > aggressivo. Esplora le specifiche delle loro implementazioni nei nostri articoli > dedicati su [Passkey Visa](https://www.corbado.com/it/blog/passkey-visa) e > [Passkey Mastercard](https://www.corbado.com/it/blog/mastercard-passkeys). ```mermaid 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 ``` ### 5.4 Il Modello PSP-Centric: Autenticazione Basata su Wallet Questo modello è incentrato sui grandi [Payment Service Provider](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) (PSP) che gestiscono i propri [wallet](https://www.corbado.com/blog/digital-wallet-assurance) 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. > **Approfondimento:** [PayPal](https://www.corbado.com/blog/paypal-passkeys) è un pioniere in questo campo. Per > un caso di studio dettagliato su come utilizzano le passkey per proteggere il loro > ecosistema, leggi la nostra analisi: [Passkey PayPal](https://www.corbado.com/it/blog/passkey-paypal): > Implementare le Passkey come PayPal. ```mermaid 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 ``` ## 6. Sfide Generali con le Passkey nei Pagamenti ### 6.1 Comprendere la Portabilità delle Passkey: Il Ruolo del Relying Party 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](https://www.corbado.com/it/blog/migliori-pratiche-creazione-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](https://www.corbado.com/glossary/icloud-keychain) e [Google Password Manager](https://www.corbado.com/blog/how-to-use-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. ### 6.2 Sfide Operative: Il Problema del Recupero 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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) ad [Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.mastercard.com/content/dam/public/mastercardcom/na/global-site/documents/mastercard-payment-passkeys-faqs.pdf)) 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. ## 7. Punti di Integrazione Strategici e Analisi Comparativa I quattro modelli architetturali - [Issuer](https://www.corbado.com/glossary/issuer)-Centric (SPC), [Merchant](https://www.corbado.com/glossary/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. ### 7.1 Integrazione a livello di Emittente / Provider ACS - **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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC). - **Target Prospect:** Questa integrazione è rivolta ai provider di [ACS](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) 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](https://www.corbado.com/blog/psd2-passkeys). - **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](https://www.corbado.com/blog/how-to-enable-passkeys-ios), è un inibitore significativo. ### 7.2 Integrazione a livello di Esercente / Payment Service Provider (PSP) - **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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/it/blog/provider-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. ### 7.3 Integrazione a livello di Circuito di Carte (tramite Click to Pay) - **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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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](https://www.corbado.com/passkeys-for-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. | Categoria | Emittente / ACS | Esercente / PSP (DA) | Circuito / Click to Pay | PSP / Wallet | | -------------------------------- | -------------------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------ | --------------------------------------------------- | | **Tecnologia Chiave** | Secure Payment Confirmation (SPC) | Autenticazione Delegata (DA) | Servizi di Passkey Federati | Autenticazione basata su Wallet | | **Attore Target** | Provider ACS, Banche Emittenti | Grandi Esercenti, PSP, Wallet | PSP, Payment Gateway | PayPal, Stripe Link, ecc. | | **Esperienza Utente (Attrito)** | Basso (Migliora la challenge, ma è ancora una challenge) | Molto Basso (Elimina la challenge per utenti loggati) | Basso (Checkout per ospiti standardizzato e a basso attrito) | Molto Basso (Flusso fluido nell'ecosistema del PSP) | | **Complessità Implementazione** | Media (Richiede integrazione ACS, 3DS 2.3+) | Alta (Richiede accordi bilaterali, si assume la responsabilità) | Media (Richiede integrazione con API del circuito) | Media (Richiede infrastruttura wallet e passkey) | | **Trasferimento Responsabilità** | Sì (Trasferimento di responsabilità standard 3DS) | Sì (La responsabilità si sposta alla parte delegante) | Sì (Il circuito/emittente si assume la responsabilità) | Sì (Il PSP si assume la responsabilità) | | **Prontezza Ecosistema** | Molto Bassa (Bloccata dalla mancanza di supporto Apple) | Limitata (Richiede fiducia specifica emittente-esercente) | Alta (Forte spinta del circuito per l'adozione) | Alta (Matura per i fornitori di wallet consolidati) | ## 8. Il Panorama Competitivo e le Prospettive Future 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. ### 8.1 Casi di Studio: I Pionieri delle Passkey per i Pagamenti - **PayPal:** In qualità di membro fondatore della [FIDO Alliance](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/conditional-ui) per creare un'esperienza di [login con un tocco](https://docs.corbado.com/corbado-connect/features/one-tap-login) 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](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/), 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](https://www.biometricupdate.com/202412/mastercard-brings-payment-passkey-service-to-latin-america) e gli [Emirati Arabi Uniti con Tap Payments](https://www.entrepreneur.com/en-ae/technology/mastercard-and-tap-payments-launch-click-to-pay-with/482810). 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. ### 8.2 Traiettoria Futura e Implicazioni più Ampie 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](https://www.corbado.com/faq/sim-swapping-sms-authentication-risk) e sofisticate campagne di [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/psd3-psr-passkeys) 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](https://www.corbado.com/blog/big-tech-vs-passkey-aggregators) (ad es. Apple ID, Google Account). Il futuro dei [pagamenti online](https://www.corbado.com/it/blog/passkey-visa) è inestricabilmente legato a questa battaglia più ampia su chi possiederà e gestirà l'identità del consumatore sul web. ### 8.3 Applicazioni Emergenti per le Passkey 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](https://www.corbado.com/passkeys-for-banking) adiacenti. Molti processi che si basano ancora su password o goffi OTP sono candidati ideali per un aggiornamento a passkey. #### 8.3.1 Oltre il Checkout: Nuove Frontiere per le Passkey - **Provisioning di Wallet Digitali:** Il processo di aggiunta di una carta di credito o di debito a un wallet digitale come [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) o [Google Pay](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/passkeys-for-banking) è consentire ad applicazioni di terze parti (come app di budgeting o altri servizi [fintech](https://www.corbado.com/it/blog/passkey-finom-sicurezza-bancaria)) 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. #### 8.3.2 Rivoluzionare le Criptovalute: Passkey per i Wallet di Stablecoin 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](https://www.corbado.com/faq/is-face-id-passkey) o una scansione dell'impronta digitale. Ciò rende un pagamento in criptovaluta fluido e sicuro come l'uso di [Apple Pay](https://www.corbado.com/blog/how-to-use-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. ## 9. Come Corbado può aiutare 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. ### 9.1 Potenziare l'Ecosistema degli Emittenti (Provider ACS e Banche) - **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](https://www.corbado.com/it/blog/psd2-passkey)/[PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) in modo diretto. - **Come Aiuta Corbado:** Forniamo un modulo di [autenticazione passkey](https://www.corbado.com/it/blog/provider-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. ### 9.2 Potenziare Esercenti e PSP per il Checkout Definitivo - **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](https://www.corbado.com/it/blog/migliori-pratiche-adozione-passkey-login) 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. ### 9.3 Potenziare l'Ecosistema di Integrazione dei Circuiti - **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. ### 9.4 Potenziare il Modello di Wallet PSP-Centric - **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. ## 10. Candidati Ideali per una Soluzione di Adozione delle Passkey 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. ### 10.1 Banche Emittenti e Provider ACS (per il potenziamento della SPC) - **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**). ### 10.2 Grandi Esercenti e PSP (per l'Autenticazione Delegata) - **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**). ### 10.3 Circuiti di Carte (Visa, Mastercard, American Express) - **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). ### 10.4 PSP con Wallet per Consumatori (PayPal, Stripe Link, Klarna) - **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**). ### 10.5 Circuiti di Pagamento e Identità Nazionali - **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. ## 11. Il Ruolo dei Wallet delle Big Tech (Apple, Google, Amazon, Meta) 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. ### 11.1 Apple Pay e Google Pay: Il Livello di Autenticazione della Piattaforma [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) e [Google Pay](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/how-to-use-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. ### 11.2 Amazon Pay e Meta Pay: Il Modello di Wallet Card-on-File 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. ## 12. Conclusione 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.