Scopri come creare passkey cross-origin come fornitore di servizi di pagamento. Confronta iframe e reindirizzamento, offri una UX al livello di Apple Pay e usa gli analytics per una maggiore adozione.
Vincent
Created: July 15, 2025
Updated: July 16, 2025
See the original blog version in English here.
Want to learn how top banks deploy passkeys? Get our 80-page Banking Passkeys Report (incl. ROI insights). Trusted by JPMC, UBS & QNB.
Get ReportLe passkey si stanno affermando come il metodo più efficace per proteggere e autorizzare le transazioni online, migliorando significativamente la sicurezza e la praticità rispetto alla tradizionale autenticazione a più fattori (MFA). Di recente, PayPal ha adottato le passkey come soluzione MFA principale e autonoma, definendo una chiara tendenza per i fornitori di servizi di pagamento in tutto il mondo.
Tuttavia, le passkey sono state originariamente progettate pensando a contesti di prima parte, il che significa che funzionano in modo ottimale quando gli utenti si autenticano direttamente sul sito web o sull'app proprietaria delle credenziali. I fornitori di servizi di pagamento, al contrario, operano tipicamente in contesti di terze parti, dove i loro servizi (come i moduli di pagamento o gli SDK) sono integrati nei siti web e nelle app dei merchant. Questa discrepanza fondamentale tra il design delle passkey e i modelli operativi dei fornitori di servizi di pagamento presenta limitazioni critiche per un'integrazione senza interruzioni. Per affrontare queste sfide, dobbiamo esplorare due domande cruciali:
1. Quali sono i limiti attuali dell'uso delle passkey in contesti di terze parti per i fornitori di servizi di pagamento? 2. Come possono i fornitori di servizi di pagamento superare questi limiti per implementare con successo le integrazioni di passkey di terze parti?
Esaminando queste domande, scopriremo che gli sforzi in corso nel settore per adattare le passkey a contesti di terze parti - in particolare attraverso standard web come Secure Payment Confirmation (SPC) - sono bloccati da barriere strategiche implicitamente imposte da Apple. Nello specifico, il supporto limitato di Apple per la creazione di passkey cross-origin in Safari e il mancato supporto dello standard Secure Payment Confirmation rappresentano un ostacolo significativo, complicando l'adozione fluida dell'autenticazione basata su passkey da parte dei fornitori di servizi di pagamento di terze parti. Comprendere e superare questi ostacoli è essenziale per qualsiasi fornitore che miri a offrire esperienze di pagamento sicure e senza attriti.
Recent Articles
♟️
Passkey per fornitori di servizi di pagamento: come creare un SDK di terze parti
♟️
Autenticazione PCI DSS 4.0: Passkeys
♟️
Mastercard Identity Check: tutto ciò che emittenti e merchant devono sapere
♟️
EMV 3DS Access Control Server: Passkeys, FIDO e SPC
♟️
Scenario delle Passkey per i Pagamenti: 4 Modelli di Integrazione Principali
Le passkey portano un login basato su dati biometrici e resistente al phishing a ogni livello dello stack di pagamento. Di seguito è riportata un'analisi di come ogni attore nella catena del valore dei pagamenti può beneficiare dell'integrazione dell'autenticazione con passkey.
Impatto: Checkout più rapido, conversioni più elevate, meno carrelli abbandonati. Opportunità: I merchant che offrono passkey tramite SDK o flussi di reindirizzamento possono imitare una UX al livello di Apple Pay e ridurre la dipendenza da password o OTP, portando a una maggiore fiducia e a un aumento delle vendite.
Impatto: Autenticazione senza password fluida su tutti i dispositivi. Opportunità: Le passkey offrono una UX migliore rispetto a OTP o codici SMS ed eliminano il rischio di phishing. Un'ampia adozione potrebbe trasformare le passkey nel nuovo standard per la verifica del titolare della carta.
Impatto: Prevenzione delle frodi più forte. Opportunità: Gli emittenti possono offrire un'autenticazione step-up basata su passkey nei flussi 3DS, riducendo i costi degli OTP e migliorando la soddisfazione degli utenti.
Impatto: Maggiore accettazione delle transazioni e meno autenticazioni fallite. Opportunità: Supportare le passkey tramite i PSP può migliorare i risultati dei merchant e ridurre l'attrito durante il checkout o i flussi di fatturazione ricorrente.
Impatto: Riduzione delle frodi, migliore UX per i merchant e maggiore conformità. Opportunità: Integrando o reindirizzando i flussi di passkey, i PSP possono fornire un'autenticazione di nuova generazione mantenendo la compatibilità tra browser e app native.
Impatto: Approvazioni delle transazioni semplificate con meno pagamenti rifiutati. Opportunità: Le aziende di elaborazione dei pagamenti possono integrare la verifica con passkey nelle loro API per ridurre i rischi e supportare alternative biometriche SCA per flussi conformi.
Impatto: Archiviazione sicura delle credenziali e riautenticazione senza attriti. Opportunità: I fornitori di wallet come Apple Pay e Google Pay utilizzano già flussi simili alle passkey.
Di seguito, diamo una breve occhiata ai principali fornitori di servizi di pagamento e carte di credito e analizziamo se e come hanno implementato le passkey:
Mastercard ha lanciato ufficialmente il suo Payment Passkey Service, fornendo un'esperienza di autenticazione senza password integrata nei flussi EMV 3DS. Gli utenti possono creare e utilizzare passkey legate al dominio di autenticazione di Mastercard (ad es. verify.mastercard.com), consentendo un login biometrico sicuro tra i merchant partecipanti. Questo lancio rappresenta un passo importante verso un'autenticazione resistente al phishing e conforme a PSD2 nel settore dei pagamenti. Leggi di più: Passkey di Mastercard
Visa ha introdotto il suo Visa Payment Passkey Service, integrando le passkey nel flusso "Click to Pay". Consentendo agli utenti di autenticarsi senza problemi utilizzando la biometria invece di password o OTP, Visa mira a modernizzare l'esperienza di checkout online con maggiore sicurezza e praticità per l'utente. Leggi di più: Passkey di VISA
American Express non ha ancora lanciato pubblicamente un'offerta di passkey. Tuttavia, in qualità di membro del consiglio di amministrazione della FIDO Alliance, è probabile che American Express implementerà una soluzione di autenticazione basata su passkey nel prossimo futuro, in linea con le più ampie tendenze del settore.
PayPal è stato uno dei primi fornitori di servizi di pagamento ad adottare le passkey. La loro implementazione supporta il login biometrico senza interruzioni per account personali e aziendali su tutti i dispositivi. La passkey è legata al dominio di PayPal ed è già disponibile in molte regioni. Tuttavia, la loro implementazione ha margini di miglioramento, specialmente per quanto riguarda i flussi multi-dispositivo e il rilevamento della piattaforma. Leggi di più: Passkey di PayPal
Klarna non ha ancora introdotto ufficialmente il supporto per le passkey. Dalle nostre osservazioni, Klarna si affida pesantemente a WebView integrate nella sua app e negli SDK di checkout. Poiché Safari e iOS limitano la creazione di passkey in iframe / WebView, questo potrebbe essere uno dei motivi per cui Klarna non ha ancora implementato le passkey.
Square ha introdotto il login con passkey per la sua dashboard per sviluppatori e la console di gestione, consentendo un accesso sicuro e senza password agli strumenti interni. Tuttavia, non è stato fatto alcun annuncio riguardo al supporto delle passkey nei flussi di pagamento o nelle API per utenti finali o merchant.
Stripe ha implementato il login con passkey per la sua dashboard, consentendo agli sviluppatori di autenticarsi tramite biometria. Le passkey per Stripe Checkout o Elements non sono ancora disponibili. Data la forte propensione di Stripe per i flussi basati su reindirizzamento, è probabile che le passkey, se implementate nei pagamenti, seguirebbero la stessa architettura di reindirizzamento.
Ad oggi, BILL non ha fatto annunci pubblici o aggiornamenti di prodotto relativi alle passkey per l'autenticazione.
Remitly non ha rivelato alcun piano o informazione pubblica sull'implementazione dell'autenticazione con passkey nei suoi servizi.
Non ci sono report pubblici o documentazione di prodotto che indichino che Payoneer abbia adottato o stia testando il login o i flussi di transazione basati su passkey.
Adyen non ha ancora introdotto le passkey nei suoi flussi di autenticazione o pagamento. Nessuna dichiarazione pubblica o documentazione per sviluppatori menziona il supporto per le passkey.
Worldpay non ha annunciato alcun supporto per le passkey ad oggi. Il loro stack di autenticazione si basa ancora su metodi tradizionali come password, OTP e flussi basati su 3DS.
Checkout.com non ha ancora implementato pubblicamente il supporto per le passkey. Non ci sono aggiornamenti per sviluppatori, post sul blog o annunci ufficiali riguardanti l'adozione delle passkey.
AliPay non ha lanciato ufficialmente le passkey. Data la crescente tendenza dell'autenticazione biometrica negli ecosistemi di pagamento cinesi, un'implementazione potrebbe avvenire in futuro, ma nessuna documentazione attuale lo conferma.
Mollie non ha rilasciato dichiarazioni pubbliche o aggiornamenti di prodotto riguardanti l'adozione delle passkey nei suoi sistemi di autenticazione o checkout.
Amazon ha implementato il supporto per le passkey per i login degli utenti sulla sua piattaforma principale. Estendere questa tecnologia ad Amazon Pay sarebbe un passo successivo naturale, soprattutto perché molti utenti hanno già una passkey registrata con Amazon, il che semplificherebbe notevolmente l'onboarding degli utenti durante il checkout.
Braintree, una società di PayPal, non ha ancora adottato ufficialmente l'autenticazione con passkey. La loro documentazione attuale non menziona le passkey nel contesto del login utente o delle API per i merchant.
Link, la soluzione di checkout con un clic di Stripe, ha implementato le passkey, che potrebbero servire come base per la strategia di passkey di Stripe nei pagamenti al consumo. Tuttavia, Stripe non ha annunciato ufficialmente il supporto delle passkey per Link o piani specifici per l'implementazione.
Afterpay non ha rilasciato dichiarazioni o funzionalità relative al supporto delle passkey. Come Klarna, la loro integrazione di checkout è fortemente basata su app, il che potrebbe porre ostacoli tecnici all'adozione delle passkey a causa dei vincoli delle WebView integrate.
L'adozione delle passkey da parte dei fornitori di servizi di pagamento di terze parti affronta ostacoli strategici, principalmente guidati dalle politiche restrittive di Apple in Safari. Due tentativi critici di standardizzazione sono stati costantemente ostacolati:
Igor Gjorgjioski
Head of Digital Channels & Platform Enablement, VicRoads
Corbado proved to be a trusted partner. Their hands-on, 24/7 support and on-site assistance enabled a seamless integration into VicRoads' complex systems, offering passkeys to 5 million users.
Le aziende si affidano a Corbado per proteggere i propri utenti e rendere i login più fluidi con le passkey. Richiedi subito la tua consulenza gratuita sulle passkey.
Richiedi una consulenza gratuitaLa Secure Payment Confirmation (SPC) rappresenta lo sforzo più significativo del settore - guidato principalmente da Google - per consentire un uso fluido e cross-origin delle passkey, specificamente progettato per autorizzazioni di pagamento sicure. La SPC standardizza il modo in cui i fornitori di servizi di pagamento autenticano gli utenti su più siti di merchant senza compromettere la sicurezza o l'esperienza utente. Tuttavia, Apple ha costantemente negato il supporto per la SPC all'interno di Safari, probabilmente come mossa strategica per garantire che Apple Pay rimanga la soluzione di pagamento preferita e più fluida all'interno del suo ecosistema. Il rifiuto di Apple di adottare la SPC non solo limita la diffusione su larga scala delle passkey in contesti di terze parti, ma ritarda anche efficacemente una più ampia adozione da parte del settore di un'autenticazione di pagamento standardizzata.
Leggi questo post del blog sulla SPC se vuoi saperne di più sui dettagli.
Un'altra barriera critica riguarda la restrizione deliberata di Apple sulla creazione di
passkey all'interno di iframe
cross-origin. Mentre Safari consente l'uso di passkey
esistenti per l'autenticazione (navigator.credentials.get()
) in un
iframe di terze parti, blocca esplicitamente la
registrazione di passkey (navigator.credentials.create()
) in tali contesti.
Questa limitazione restringe gravemente i fornitori di servizi di pagamento che dipendono dalla creazione di nuove passkey senza interruzioni durante il flusso di checkout del merchant. Di conseguenza, i fornitori sono costretti a utilizzare approcci basati su reindirizzamento o devono fare affidamento su passkey esistenti, precedentemente stabilite direttamente sui propri domini. Questa decisione di Apple influisce direttamente sulla praticità e fluidità delle integrazioni dei merchant, creando un significativo punto di attrito sia per i consumatori che per i fornitori.
Perché le passkey sono importanti per le aziende?
Le aziende di tutto il mondo affrontano gravi rischi a causa di password deboli e phishing. Le passkey sono l'unico metodo MFA che soddisfa le esigenze di sicurezza e UX aziendali. Il nostro whitepaper mostra come implementare le passkey in modo efficiente e qual è l'impatto sul business.
In questo approccio, il merchant include il tuo modulo di pagamento in un <iframe>
servito dal dominio del tuo fornitore di servizi di pagamento, ad esempio
https://pay.provider.com
. L'utente rimane sul dominio del merchant (ad es.
https://www.mystore.com
), vede la tua interfaccia di pagamento
nell'iframe integrato e si autentica con una passkey
legata all'ID della Relying Party pay.provider.com
.
Punti chiave:
Cross-Origin: Poiché l'iframe si trova su un dominio diverso, è necessario configurare le policy di autorizzazione per publickey-credentials-get e publickey-credentials-create per consentire le operazioni con le passkey all'interno dell'iframe.
Limitazione alla creazione: Alcuni browser (in particolare le versioni più vecchie e
Safari) non consentono ancora la creazione di passkey in iframe cross-origin.
L'autenticazione (navigator.credentials.get()
) è più ampiamente supportata, ma la
registrazione (navigator.credentials.create()
) potrebbe fallire in determinati
ambienti, specialmente in Safari.
Attivazione da parte dell'utente: I flussi di passkey richiedono tipicamente un'"attivazione transitoria" (ad es. un clic diretto su un pulsante da parte dell'utente). Assicurati che la tua interfaccia iframe attivi la cerimonia della passkey all'interno di un evento avviato dall'utente.
Sicurezza e UX: L'approccio con iframe offre un'esperienza di checkout fluida e in linea, ma se il browser di un utente blocca o limita i cookie di terze parti o l'archiviazione locale, potrebbe interrompere il flusso della passkey.
Con un flusso basato su reindirizzamento, invii l'utente dal dominio del merchant al tuo
dominio di pagamento, oppure apri una nuova scheda/finestra che punta a qualcosa come
https://pay.provider.com/checkout
. Le passkey vengono quindi create o utilizzate
direttamente sul tuo dominio in un contesto di prima parte.
Punti chiave:
Semplicità di prima parte: L'intero flusso di lavoro della passkey (creazione, autenticazione) avviene sul dominio del fornitore di servizi di pagamento, quindi non ci sono restrizioni cross-origin. Tutti i principali browser supportano la creazione e il login con passkey in contesti di prima parte.
UX del reindirizzamento: L'utente lascia la pagina del merchant (o vede un pop-up) per completare l'autenticazione. Questo può essere meno fluido, ma semplifica l'architettura del flusso di passkey integrato e riduce le complessità cross-origin.
Fallback per browser incompatibili: Puoi degradare gradualmente se le passkey non sono disponibili (ad es. browser più vecchi) fornendo metodi di login alternativi sul tuo dominio di pagamento senza bisogno di gestire autorizzazioni cross-origin aggiuntive.
L'integrazione delle passkey all'interno delle app mobili native presenta sfide uniche rispetto agli scenari basati sul web. Le app native per i merchant (sia su iOS che su Android) spesso integrano i flussi di pagamento all'interno dell'applicazione utilizzando WebView integrate per mantenere un'esperienza utente fluida. Tuttavia, l'implementazione dell'autenticazione con passkey di terze parti in questi contesti integrati può essere problematica a causa delle rigide policy di origine del browser e delle limitazioni specifiche della piattaforma.
Le passkey sono intrinsecamente legate a un dominio specifico (l'ID della "Relying Party"), che è un principio di sicurezza fondamentale per garantire che le credenziali non possano essere utilizzate in modo improprio su siti web o app non correlati. Quando un fornitore di servizi di pagamento crea passkey sotto il proprio dominio - ad esempio, pay.provider.com - tali passkey sono strettamente limitate a quel dominio sia su iOS che su Android. Di conseguenza, un'app nativa di un merchant (che opera naturalmente sotto l'identificatore e il dominio dell'app del merchant) non può invocare direttamente le passkey del fornitore come credenziale di "prima parte". Ciò richiederebbe la condivisione cross-origin di chiavi private, che i sistemi operativi e le specifiche WebAuthn vietano esplicitamente per prevenire il phishing e il furto di credenziali.
Dal punto di vista del dispositivo, l'app nativa del merchant è un'"origine" diversa rispetto al dominio del fornitore di servizi di pagamento. Tentare di autenticarsi nativamente con credenziali registrate su un'origine separata violerebbe il modello di sicurezza fondamentale delle passkey, legato all'origine. Questo è esattamente il motivo per cui l'uso di passkey di terze parti in un contesto di merchant dipende da un browser di sistema o da una WebView basata sul sistema (come ASWebAuthenticationSession su iOS o Chrome Custom Tabs su Android). Questi flussi speciali preservano il contesto del dominio originale del fornitore - garantendo che le passkey rimangano saldamente legate all'origine - pur consentendo agli utenti di autenticarsi con il fornitore di servizi di pagamento all'interno dell'app di un merchant. Nelle sezioni seguenti, esploreremo come funziona.
Le WebView integrate (ad es. WKWebView su iOS o la WebView di Android) sono ampiamente preferite perché consentono alle app di integrare contenuti web direttamente nelle loro interfacce native, offrendo una stretta integrazione e coerenza della UX. Tuttavia, questi ambienti integrati sono significativamente limitati quando si gestiscono passkey di terze parti a causa delle policy di origine e di sicurezza:
Mancata corrispondenza dell'origine: Le passkey si basano rigorosamente sulle origini dei domini per una gestione sicura delle credenziali. Una WebView integrata opera sotto il dominio del contenuto che visualizza (spesso quello del merchant), rendendo difficile o impossibile creare o autenticare passkey legate esplicitamente al dominio di un fornitore di servizi di pagamento di terze parti.
Vincoli di sicurezza della piattaforma: Sia Apple (iOS) che Google (Android) hanno progressivamente limitato le capacità delle WebView integrate per l'autenticazione, in particolare quando si tratta di credenziali sicure. Questi vincoli sono progettati per proteggere la privacy degli utenti e la sicurezza, ma rendono l'implementazione di passkey di terze parti notevolmente più complicata.
Nel complesso, sebbene le WebView integrate siano attraenti per i merchant dal punto di vista della UX, introducono significative limitazioni pratiche per l'implementazione di flussi di autenticazione con passkey di terze parti robusti.
Dati i limiti associati alle WebView integrate, i fornitori di servizi di pagamento adottano tipicamente una delle due strategie alternative per implementare in modo affidabile le passkey di terze parti nelle app mobili native:
iOS (ASWebAuthenticationSession):
Apple fornisce ASWebAuthenticationSession come un ambiente sicuro, simile a un browser, esterno al contesto dell'applicazione host. Condivide l'archiviazione dei cookie con il browser Safari predefinito e supporta in modo affidabile le passkey di terze parti perché le credenziali si allineano con il dominio di origine del fornitore di servizi di pagamento.
L'esempio seguente mostra la funzionalità "Check out with PayPal" all'interno dell'app nativa di BOSS. Mostra come viene aperta una webview di sistema ASWebAuthenticationSession, che condivide il suo stato con i cookie di Safari, consentendo l'avvio immediato del dialogo della passkey.
Android (Chrome Custom Tabs):
Allo stesso modo, le Custom Tabs di Android offrono un ambiente quasi-browser che consente la creazione e l'autenticazione coerente delle passkey. Come ASWebAuthenticationSession, le Custom Tabs vengono eseguite separatamente dal contesto dell'app del merchant, garantendo l'integrità del dominio e delle credenziali.
Guarda lo stesso esempio dall'app nativa di BOSS su Android qui:
Un altro approccio consiste nel reindirizzare gli utenti dall'app nativa al browser web predefinito del dispositivo mobile (Safari su iOS, Chrome su Android). Ciò garantisce che il flusso di pagamento - e quindi la gestione delle passkey - avvenga interamente in un contesto di prima parte affidabile, associato al dominio del fornitore di servizi di pagamento. Gli utenti tornano quindi all'app del merchant dopo il completamento dell'autenticazione o del pagamento. Questa opzione è molto scomoda per i clienti perché devono lasciare l'app.
Entrambe le soluzioni richiedono una transizione temporanea degli utenti fuori dall'ambiente dell'app nativa del merchant. Sebbene leggermente meno fluidi rispetto alle soluzioni integrate, questi approcci migliorano significativamente la compatibilità, la sicurezza e l'affidabilità delle operazioni con passkey di terze parti.
In definitiva, i fornitori di servizi di pagamento che sviluppano SDK nativi devono bilanciare attentamente le considerazioni sull'esperienza utente con i vincoli tecnici pratici. Nonostante le preferenze dei merchant per esperienze completamente integrate, sfruttare le WebView di sistema o il reindirizzamento a browser esterni rimane la best practice per garantire un'autenticazione con passkey di terze parti sicura e affidabile all'interno delle app native.
La scelta tra un approccio integrato (iframe) e uno basato su reindirizzamento per l'integrazione di passkey di terze parti negli SDK di pagamento comporta la valutazione di compromessi tra esperienza utente, compatibilità del browser, complessità tecnica e preferenze dei merchant.
Entrambe le soluzioni presentano vantaggi e svantaggi distinti, che i fornitori di servizi di pagamento dovrebbero considerare attentamente in base al loro mercato di riferimento, alla UX desiderata e all'infrastruttura tecnica.
Aspetto | Approccio integrato (Iframe) | Approccio con reindirizzamento |
---|---|---|
User Experience | ✅ Molto fluida; gli utenti rimangono sul sito del merchant per l'intero processo di checkout, migliorando la coerenza del brand del merchant. | ⚠️ Potenzialmente dirompente; gli utenti lasciano il sito del merchant o incontrano pop-up/nuove schede, introducendo attrito. |
Compatibilità con i browser | ⚠️ Limitata a causa del blocco da parte di Safari di Apple della creazione di passkey cross-origin e delle restrizioni dei browser più vecchi; supporto parziale, principalmente per i flussi di autenticazione. | ✅ Robusta; ampiamente compatibile con tutti i principali browser poiché opera in un contesto di dominio di prima parte. |
Supporto per app native | ⚠️ Scarso supporto; si interrompe nelle webview integrate a causa di rigide policy di origine e vincoli di sicurezza. | ✅ Forte supporto; gestito facilmente tramite webview di sistema o browser esterni, in linea con le linee guida della piattaforma (iOS e Android). |
Attrattiva per i merchant | ✅ Maggiore; i merchant preferiscono esperienze completamente integrate poiché mantengono il controllo sulla UX e sul branding. | ⚠️ Media; il reindirizzamento può causare attrito, con un potenziale impatto sui tassi di conversione e sulla soddisfazione del cliente se non gestito con cura. |
Complessità di implementazione tecnica | ⚠️ Maggiore complessità; richiede una configurazione precisa delle Permission Policy e la gestione di varie stranezze dei browser con limiti sulle app native. | ✅ Minore complessità; semplice da implementare grazie alla semplicità del contesto di prima parte, riducendo le potenziali insidie dell'integrazione. |
Compatibilità con le passkey | ⚠️ Parziale; l'autenticazione è ampiamente supportata, ma la creazione di passkey è particolarmente problematica a causa delle limitazioni cross-origin. | ✅ Completa; supporto totale per la registrazione e l'autenticazione delle passkey senza restrizioni cross-origin. |
Manutenzione e supporto | ⚠️ Maggiori costi generali a causa dei frequenti aggiornamenti dei browser e delle sfide di compatibilità. | ✅ Minori costi generali; manutenzione più semplice, meno aggiornamenti di compatibilità cross-origin richiesti. |
Esempio di best practice | Klarna: Klarna si è sempre concentrata molto sulle esperienze utente integrate e ha sconsigliato l'uso di WebView di sistema. Per questo motivo, al momento della stesura di questo articolo, Klarna sta faticando a offrire ai suoi clienti un'esperienza completa con passkey di terze parti. | PayPal: PayPal ha sempre indirizzato gli utenti al proprio sito web, imponendo un approccio basato sul reindirizzamento grazie alla sua forza di mercato e alla sua lunga storia. Pertanto, l'integrazione delle passkey nei flussi di pagamento è stata semplice e rapida, anche in contesti di terze parti, poiché le WebView di sistema erano già in uso. |
L'approccio integrato (iframe) offre un'esperienza utente fluida e brandizzata dal merchant, molto attraente per questi ultimi, ma è ostacolato da una compatibilità limitata con i browser, in particolare dal rifiuto di Safari di consentire la creazione di passkey cross-origin. Questa limitazione costringe merchant e fornitori a soluzioni complesse e basate su workaround che spesso compromettono la funzionalità o portano a un supporto incompleto per la registrazione delle passkey.
Al contrario, l'approccio con reindirizzamento offre una compatibilità completa tra browser e piattaforme mobili native operando in un contesto di dominio di prima parte. Semplifica notevolmente l'integrazione, migliora l'affidabilità e garantisce il pieno supporto alla creazione e all'autenticazione delle passkey. Lo svantaggio principale è il potenziale attrito creato dal reindirizzamento degli utenti lontano dal sito web o dall'app del merchant, sebbene questo possa essere mitigato con un'attenta progettazione della UX, aspettative comunicate chiaramente o integrazioni con piattaforme affidabili come Corbado.
Dati questi aspetti, un approccio ibrido è spesso ideale, consentendo ai fornitori di servizi di pagamento di sfruttare il modello iframe integrato quando il browser dell'utente lo supporta e di passare elegantemente a un approccio di reindirizzamento in caso contrario. Questa strategia combinata massimizza la compatibilità, l'attrattiva per i merchant e la soddisfazione del cliente in diversi ambienti.
L'implementazione di un SDK di pagamento con passkey di terze parti implica il bilanciamento di esperienza utente, compatibilità del browser, vincoli delle app native, analytics e sicurezza, specialmente dati gli ostacoli specifici di Apple (ad es. blocco della creazione di passkey cross-origin, mancato supporto SPC). Di seguito sono riportate le raccomandazioni chiave per garantire il miglior risultato possibile durante l'integrazione delle passkey nei flussi di pagamento web o nativi.
A causa del supporto variabile dei browser e dei comportamenti incoerenti di Apple, è fondamentale supportare sia un approccio integrato (basato su iframe) sia un approccio di reindirizzamento:
Checkout con Iframe (Integrato)
Fornisce un'esperienza fluida e sulla pagina per i browser moderni che consentono operazioni con passkey cross-origin (principalmente per l'autenticazione).
È necessario impostare la Permissions-Policy corretta per publickey-credentials-get/publickey-credentials-create.
Si noti che Safari e alcuni browser più vecchi bloccano la creazione di passkey cross-origin negli iframe.
Flusso di reindirizzamento
Supporta in modo affidabile sia la registrazione che il login con passkey in un contesto di prima parte.
Leggermente più attrito a causa del reindirizzamento o del pop-up extra, ma universalmente più sicuro per la compatibilità cross-browser.
Fallback ideale per Safari, che attualmente non consente la creazione di passkey di terze parti negli iframe.
Offrendo entrambi gli approcci, è possibile decidere dinamicamente - o lasciare che i merchant decidano - quale utilizzare, massimizzando la compatibilità per tutti gli ambienti utente.
Rilevare accuratamente le capacità del browser rimane una sfida a causa della ridotta granularità dello User-Agent e del supporto incoerente per i Client Hints tra le piattaforme.
Il parsing tradizionale è sempre più inaffidabile poiché i browser riducono i dettagli nelle stringhe dello User-Agent per proteggere la privacy degli utenti. Differenziare dettagli essenziali - come Windows 10 vs. Windows 11, versioni precise di macOS o architetture della CPU - è ora difficile o impossibile usando solo lo User-Agent.
Mentre i Client Hints forniscono dati ad alta entropia in modo rispettoso della privacy, solo i browser basati su Chromium li supportano pienamente. Safari e Firefox non offrono alcun supporto per i Client Hint, limitando gravemente il rilevamento preciso delle funzionalità sui dispositivi Apple.
Le WebView integrate tipicamente limitano l'accesso a informazioni dettagliate sul dispositivo e raramente supportano i Client Hints. Questa limitazione rende il rilevamento della capacità delle passkey particolarmente difficile nei contesti di app native.
Dati questi vincoli, rilevare in modo affidabile il supporto per le passkey cross-origin - in particolare negli SDK di pagamento di terze parti - richiede un'attenta combinazione di query dinamiche di Client Hint (dove disponibili), euristiche di fallback basate sullo User-Agent e comportamenti predefiniti conservativi per browser come Safari e Firefox.
Le app native dei merchant spesso integrano contenuti web in WKWebView (iOS) o Android WebView, che sono molto restrittive per le passkey. Le strategie comuni includono:
Sessioni del browser di sistema: Utilizzare ASWebAuthenticationSession (iOS) o Custom Tabs (Android) per spostare la creazione/login con passkey in un contesto browser sicuro di "prima parte".
Reindirizzamento al browser predefinito: Un approccio meno fluido ma altamente affidabile per garantire l'integrità del dominio per le operazioni con le passkey.
Come fornitore di servizi di pagamento, una forte sicurezza e la conformità normativa (PCI, PSD2 SCA, ecc.) sono fondamentali:
Header e sicurezza dei contenuti: Implementare header Permissions-Policy rigorosi e regole CSP robuste per i flussi cross-origin.
Logging e monitoraggio: Registrare accuratamente gli eventi di creazione e utilizzo delle passkey per la prevenzione delle frodi e gli audit di conformità.
Archiviazione minima di PII: Mappare gli utenti alle passkey utilizzando identificatori hash, riducendo l'esposizione ai sensi del GDPR o di leggi simili sulla protezione dei dati.
Audit Trail: Registrare ogni evento di creazione e autenticazione di passkey per rilevare anomalie e soddisfare gli audit di conformità.
Le passkey sono ancora in evoluzione, quindi saranno necessari controlli continui:
Test cross-browser e cross-OS: Automatizzare i test su Safari, Chrome, Edge, Firefox e le principali versioni dei sistemi operativi mobili.
Aggiornamenti frequenti: Tenere traccia delle modifiche nelle specifiche W3C WebAuthn, nelle linee guida della FIDO Alliance o nelle proposte SPC.
Feedback degli utenti e tassi di errore: Registrare gli errori delle passkey (creazione o login) per risolvere rapidamente i problemi, specialmente per gli utenti basati su Apple.
Un solido framework di KPI aiuta a monitorare se la tua integrazione di passkey di terze parti migliora veramente la sicurezza e l'esperienza utente. Anche se questo articolo riguarda l'implementazione di SDK, è importante tenere presente che l'adozione delle passkey è fondamentale anche in questo caso d'uso. Il tasso di creazione e il tasso di utilizzo delle passkey richiedono un'attenta analisi e ottimizzazione.
Definizione: Percentuale di utenti che creano con successo una passkey quando richiesto (ad es. al checkout o alla configurazione dell'account).
Perché è importante: Un alto tasso di creazione significa che il tuo flusso di onboarding/nudge per le passkey è convincente e senza attriti.
Obiettivo: Dovresti puntare a un tasso del 50-80%
Definizione: Tra gli utenti che iniziano la cerimonia di creazione (cliccano su "Crea Passkey"), quanti la finalizzano senza interrompere o incorrere in errori?
Perché è importante: Indica quanto bene sta funzionando il tuo flusso cross-origin o di reindirizzamento.
Obiettivo: Idealmente, dovresti avere un valore di circa il 95-100% una volta che un utente ha scelto di procedere.
Definizione: La percentuale di autorizzazioni di pagamento totali (o login) effettuate tramite passkey, rispetto ai metodi di fallback.
Perché è importante: La creazione non ha senso se gli utenti tornano ai metodi più vecchi.
Obiettivo: Un tasso del 50-80% segnala una forte adozione delle passkey.
Definizione: Percentuale di tentativi di login con passkey che riescono senza errori o fallback.
Perché è importante: Un riflesso della tua usabilità nel mondo reale.
Obiettivo: Tipicamente dovresti superare il 90-95% per considerare le passkey "senza attriti".
Definizione: Con quale frequenza gli utenti falliscono con le passkey a metà cerimonia e passano a una password o a un OTP?
Perché è importante: Un alto utilizzo del fallback suggerisce che ostacoli tecnici o di UX impediscono alle passkey di sostituire i metodi legacy.
Obiettivo: Idealmente, l'utilizzo del fallback è inferiore all'1-5%
Per i fornitori di servizi di pagamento, misura se le passkey riducono le frodi, accelerano il checkout o diminuiscono l'abbandono del carrello. Combina i dati sull'utilizzo delle passkey con i dati di conversione dei pagamenti o le metriche di successo del 3-D Secure per una visione olistica.
Il monitoraggio di questi KPI aiuta a individuare quali ambienti o percorsi utente necessitano di miglioramenti - ad esempio, se Safari su iOS ha un tasso di abbandono più elevato a causa dei blocchi cross-origin, puoi indirizzare sistematicamente quegli utenti a un flusso di reindirizzamento.
Una delle sfide più critiche nella creazione di un SDK di passkey di terze parti è orchestrare un flusso di creazione fluido e coerente, in cui gli utenti registrano effettivamente le loro passkey. Che ciò avvenga nel portale di una banca, nelle impostazioni dell'account del fornitore di servizi di pagamento o direttamente sulla pagina di checkout di un merchant, i passaggi fondamentali per la registrazione della passkey sono molto simili. Di conseguenza, l'approccio alla creazione di passkey non cambia fondamentalmente a seconda che si integri il flusso in un iframe o si reindirizzi l'utente a una pagina di prima parte; ciò che conta di più è fornire schermate chiare e facili da usare, gestire i vincoli cross-origin e tracciare le metriche essenziali che mostrano con quale efficacia gli utenti adottano le passkey. Di seguito sono riportati gli aspetti chiave di un flusso di creazione di passkey best-practice e come Corbado li supporta:
Indipendentemente da dove a un utente venga richiesto di creare una passkey - che si tratti di un ambiente di online banking di una banca, del sito web/app del fornitore di servizi di pagamento o del checkout di un merchant - Corbado fornisce componenti pre-costruiti e personalizzabili per i prompt utente, le conferme di successo e la gestione degli errori.
Questi componenti garantiscono un aspetto coerente, consentendo al contempo un branding white-label in modo che ogni banca o merchant possa mantenere i propri elementi di design unici, se necessario.
Guarda il seguente componente UI per la schermata di creazione della passkey con il brand di VicRoads:
Corbado raccoglie e unifica i dati da tutti gli endpoint di creazione:
Siti web o app di banche dove le passkey vengono offerte inizialmente.
Le impostazioni dell'account personale del fornitore di servizi di pagamento (dove gli utenti possono gestire le credenziali).
Pagine di checkout dei merchant che consentono opzionalmente la creazione di passkey "al volo".
Questo approccio unificato rende facile misurare il tasso di creazione delle passkey, il tasso di successo della creazione, i punti di abbandono degli utenti e qualsiasi errore tecnico, indipendentemente dal canale che avvia la registrazione della passkey.
Corbado offre funzionalità di test A/B per perfezionare le istruzioni su schermo, il testo dei pulsanti e la tempistica dei prompt. Sottili cambiamenti nel testo (ad es. "Crea una passkey ora - niente più password!" vs. "Proteggi il tuo prossimo pagamento con una passkey!") spesso producono differenze significative nell'accettazione da parte degli utenti.
Sulla base dei risultati del test A/B, è possibile ottimizzare i seguenti KPI:
Tasso di creazione: Percentuale di utenti che, una volta richiesto, impostano con successo una passkey.
Tasso di successo della creazione: La quota di utenti che terminano la cerimonia senza interrompere o incorrere in errori.
Utilizzo del fallback: Il tasso con cui gli utenti saltano la creazione della passkey a favore di metodi di login più vecchi.
Impatto sulla conversione: Per i merchant, misurare se la creazione di passkey al checkout riduce l'abbandono del carrello.
Gli utenti possono creare passkey nei seguenti contesti:
Contesto bancario: Flussi di creazione attivati dopo che un utente accede alla propria banca, sfruttando la fiducia e la familiarità dell'ambiente di banking.
Impostazioni dell'account del fornitore di servizi di pagamento: Gli utenti impostano le passkey direttamente nelle impostazioni "Il mio profilo" o "Sicurezza" del dominio del fornitore di servizi di pagamento.
Checkout del merchant: Prompt nella fase finale del pagamento, specialmente se l'utente non ha creato una passkey in precedenza. Questo può essere integrato (iframe) o tramite reindirizzamento.
In ogni scenario, la cerimonia della passkey sottostante segue gli stessi passaggi: conferma dell'utente, prompt biometrico/PIN e registrazione delle credenziali. L'SDK di Corbado garantisce che i vincoli cross-origin (se integrato) o il contesto di dominio di prima parte (se reindirizzato) siano gestiti senza problemi in background.
Corbado collega ogni nuova passkey all'identificatore utente appropriato - che si tratti di "prefissoBanca_idUtente" o di un riferimento utente interno nel sistema del fornitore di servizi di pagamento - in modo che ogni utilizzo successivo sia tracciabile all'account utente corretto.
Questi metadati sono anche cruciali per analytics avanzati: ad esempio, per vedere come si comportano le campagne di creazione di passkey di RBC rispetto a quelle di TD, o come differiscono i tassi di creazione tra i checkout dei merchant e i flussi diretti dalle "impostazioni dell'account".
La stessa logica dell'SDK di Corbado può adattarsi a seconda che la creazione di passkey cross-origin sia consentita (in Chrome o Edge moderni) o debba passare elegantemente a un reindirizzamento per Safari.
La segnalazione degli errori integrata aiuta a identificare se un sottoinsieme di utenti fallisce costantemente la creazione della passkey (ad es. versioni iOS più vecchie, dispositivi Windows aziendali), in modo che il team di prodotto possa affinare le istruzioni o le strategie di fallback.
Il nostro team ha condotto numerosi esperimenti di creazione di passkey con clienti enterprise, imparando quali frasi, posizionamenti di pulsanti e tempistiche producono i migliori tassi di adozione.
Incorporiamo queste best practice in ogni schermata di creazione, pur consentendo una personalizzazione completa per le esigenze di branding e conformità.
Nel complesso, la creazione di passkey è la fase più importante per garantire un'elevata adozione: anche il flusso di login con passkey più elegante non avrà importanza se gli utenti non registrano mai le credenziali. Offrendo schermate di creazione uniformi e tracciabili su tutti i canali possibili - dominio della banca, del fornitore di servizi di pagamento o checkout del merchant - e dotandole di analytics KPI e test A/B, Corbado aiuta i fornitori di servizi di pagamento a promuovere un'adozione di passkey veramente scalabile, rispecchiando l'esperienza utente di soluzioni native come Apple Pay.
Una volta che un utente ha creato una passkey, il passo successivo è assicurarsi che la usi effettivamente per pagamenti rapidi e senza attriti, come nel flusso di pagamento di Apple Pay.
In Corbado, abbiamo sviluppato un meccanismo di "Passkey Intelligence" che rileva automaticamente quando l'ambiente di un utente contiene probabilmente una passkey valida, consentendo una vera esperienza di pagamento one-tap. Di seguito sono riportati gli elementi fondamentali che lo rendono possibile.
Quando un utente di ritorno viene riconosciuto, il front-end di Corbado mostra un pulsante dedicato (ad es. "Paga con Passkey") invece di forzare l'inserimento di credenziali di fallback.
Un solo tocco su questo pulsante attiva il flusso WebAuthn get()
(o il prompt nativo
della passkey), consentendo all'utente di autenticarsi istantaneamente tramite
biometria/PIN, senza passaggi aggiuntivi o inserimenti di moduli.
L'SDK di Corbado raccoglie segnali (ad es. cookie di archiviazione locale, uso precedente di passkey con successo, rilevamenti dell'ambiente) per prevedere se il dispositivo + browser corrente ha probabilmente una passkey valida per questo utente.
Se i cookie vengono eliminati o non sono disponibili, Corbado ricorre a euristiche aggiuntive (ad es. ambiente noto esistente dell'utente, suggerimenti utente forniti dal merchant) per decidere se è sicuro avviare automaticamente un flusso di passkey.
Se le prove sono insufficienti per suggerire la presenza di una passkey, l'interfaccia utente offre elegantemente flussi di fallback o chiede all'utente di confermare di avere una passkey.
Corbado non archivia informazioni di identificazione personale (PII) come email complete o nomi.
Invece, il merchant può passare un identificatore hash o mascherato (ad es. un hash dell'email o un ID utente interno). Corbado lo utilizza per cercare potenziali registrazioni di passkey, quindi decide se avviare un'autenticazione con passkey o tornare a un approccio più generico. Se supportato dal fornitore di servizi di pagamento, possiamo cercare le informazioni fornite dal merchant per trovare l'ID utente interno.
Ciò garantisce la privacy dell'utente pur consentendo una corrispondenza dell'ambiente ad alta precisione.
In scenari in cui la passkey dell'utente potrebbe essere esistita ma non può essere rilevata (ad es. cookie cancellati, nuovo dispositivo), la Passkey Intelligence di Corbado analizza attentamente se ha senso avviare automaticamente un prompt di passkey.
Invece, l'utente vedrebbe flussi di fallback alternativi o un'opzione "scansiona passkey da un altro dispositivo", preservando comunque un percorso rapido per tornare all'uso della passkey se l'utente può confermare manualmente di averne una.
Ogni volta che Corbado sceglie di avviare o saltare un prompt di passkey one-tap, tale decisione viene registrata. Nel tempo, è possibile vedere con precisione quali browser o tipi di dispositivo producono la massima copertura di passkey rispetto a quelli che ricorrono frequentemente al fallback.
Questo ciclo di feedback analitico consente di identificare ambienti poco performanti (ad es. versioni specifiche di iOS o Android) o segmenti di utenti in cui l'uso delle passkey rimane basso, in modo da poter affinare le strategie di onboarding o di formazione.
Indipendentemente dal fatto che l'utente provenga da una campagna di creazione di passkey di una banca o direttamente dal checkout di un merchant, la logica one-tap rimane coerente.
Corbado garantisce che se viene trovata una passkey (in base a cookie di dominio, token di archiviazione locale o segnali di passkey intelligence), all'utente venga immediatamente presentato il flusso di login/pagamento più fluido.
Riepilogo
In breve, l'uso di passkey one-tap è il vantaggio finale della creazione di passkey. Sfruttando la Passkey Intelligence - una miscela di rilevamento dell'ambiente, uso minimo di PII e logica di fallback - Corbado garantisce che agli utenti venga presentata l'autenticazione con passkey solo quando è veramente probabile che abbia successo. Ciò riduce drasticamente i tentativi falliti, evita la frustrazione dell'utente e favorisce un uso abituale delle passkey, culminando in un flusso di pagamento one-tap che rivaleggia con la comodità di Apple Pay o altre esperienze di pagamento native.
Oltre a semplicemente abilitare le passkey, è fondamentale capire con quale efficacia vengono adottate e utilizzate su diversi dispositivi, browser e percorsi utente. I fornitori di servizi di pagamento necessitano di dati concreti per sapere se le passkey riducono veramente l'attrito, diminuiscono le frodi e migliorano la conversione. Attingendo alle best practice della Guida Passkey: Comprare o Costruire, Corbado offre un ricco livello di analytics che consente di tracciare, segmentare e ottimizzare le prestazioni delle passkey in tempo reale.
Di seguito sono riportati i punti salienti.
Corbado organizza tutti gli eventi delle passkey in un funnel: dal momento in cui a un utente viene richiesto di creare una passkey, attraverso la registrazione riuscita, fino ai successivi login/pagamenti (utilizzo della passkey).
Questa visualizzazione a imbuto consente di vedere dove gli utenti abbandonano, ad esempio quanti non iniziano mai la creazione, quanti abbandonano a metà cerimonia o quanti tornano a metodi di fallback al momento del login.
Sulla base della nostra vasta esperienza nell'aiutare le aziende a implementare le passkey, ci concentriamo su metriche che hanno un impatto diretto sul ROI e sulla soddisfazione dell'utente:
Tasso di accettazione delle passkey: Quanti utenti che vedono un prompt di creazione completano effettivamente la registrazione della passkey?
Tasso di successo nella creazione di passkey: Di coloro che iniziano la cerimonia (cliccano su "Crea Passkey"), quale percentuale finalizza senza errori o abbandoni?
Tasso di utilizzo delle passkey: Con quale frequenza gli utenti di ritorno scelgono effettivamente le passkey per l'autenticazione o il pagamento quotidiano, piuttosto che password o OTP?
Tasso di successo del login con passkey: La percentuale di tentativi di passkey che riescono senza fallback o frustrazione dell'utente.
Utilizzo del fallback: Quanti utenti avviano un flusso di passkey ma tornano a metodi più vecchi? Questo segnala potenziali barriere tecniche o di UX.
Corbado etichetta automaticamente ogni evento con il sistema operativo (Windows, macOS, iOS, Android) e il browser (Chrome, Safari, Edge, Firefox, ecc.).
Con questa segmentazione, puoi vedere se, ad esempio, Safari su iOS ha un tasso di abbandono delle passkey più elevato, o se Chrome su Windows produce una migliore adozione delle passkey.
Questi dati aiutano anche a perfezionare le strategie di fallback, specialmente se le restrizioni cross-origin di Apple influenzano la tua base di utenti più del previsto.
Forniamo viste dashboard per ogni fase del funnel delle passkey: prompt di creazione, registrazioni riuscite, login degli utenti, utilizzo del fallback.
I grafici in tempo reale consentono ai product manager di individuare rapidamente le tendenze (ad es. se un nuovo aggiornamento del sistema operativo interrompe i flussi di passkey).
Gli avvisi automatici possono notificare al tuo team se i tassi di successo delle passkey diminuiscono in modo significativo, in modo da poter indagare prontamente su un nuovo bug del browser o un problema di configurazione.
Ogni flusso di passkey (dalla creazione al login) viene registrato con eventi passo-passo con timestamp, consentendo un'analisi forense approfondita.
Puoi cercare rapidamente per hash utente, ID di sessione o firma del dispositivo per vedere esattamente dove un utente ha avuto difficoltà o quale codice di errore è stato restituito.
Questo è fondamentale per le implementazioni su larga scala, dove non puoi fare affidamento su ticket di supporto aneddotici ma hai bisogno di dati precisi per risolvere i problemi degli utenti.
La piattaforma di analytics di Corbado supporta i test A/B integrati nel funnel delle passkey: testa diversi testi di CTA, prompt di creazione, messaggi di fallback o posizionamento dei pulsanti "Crea Passkey" nel flusso di checkout.
Metriche come "Tasso di accettazione delle passkey" o "Tasso di fallback" possono essere misurate fianco a fianco per ogni variante.
Questo approccio garantisce un miglioramento continuo, rispecchiando il successo dei principali adottatori di passkey che affinano i flussi nel tempo.
Mentre le dashboard di Corbado forniscono un'interfaccia visiva pronta all'uso, puoi anche esportare o inviare tramite webhook i punti dati chiave (ad es. successo nella creazione di passkey, login) ai tuoi strumenti di BI o SIEM.
Ciò consente ai fornitori di servizi di pagamento di incorporare i KPI delle passkey in suite di analytics più ampie, monitorando il ROI delle passkey insieme ad altre metriche di sicurezza, marketing o operative.
Riepilogo
Misurando e visualizzando ogni passo del percorso della passkey - attraverso combinazioni di OS/browser, flussi di creazione e scenari di login - Corbado ti fornisce le informazioni necessarie per affinare continuamente la tua offerta di passkey. Questi analytics non si limitano a confermare che le passkey sono abilitate; dimostrano se gli utenti le stanno effettivamente adottando su larga scala, identificano i punti di attrito e ti aiutano a portare i tassi di utilizzo al punto in cui le passkey sostituiscono genuinamente le password per pagamenti sicuri e senza attriti.
Per i fornitori di servizi di pagamento, creare semplicemente una passkey per utente spesso non è sufficiente per offrire un'esperienza di autenticazione veramente fluida. In realtà, gli utenti cambiano spesso dispositivo: dai laptop al lavoro agli smartphone personali, ai tablet e persino ai computer di famiglia condivisi. Garantire che ogni dispositivo abbia una passkey valida per lo stesso account è fondamentale per ridurre l'attrito e prevenire il ricorso alle password. Apple Pay raggiunge questo obiettivo potendo sfruttare l'account iCloud su tutti i dispositivi connessi a iCloud.
Di seguito è riportato come Corbado aiuta a mantenere la copertura multi-dispositivo durante tutto il ciclo di vita dell'utente.
Schermate di creazione della passkey primaria: Corbado si concentra inizialmente sul far registrare a ogni utente almeno una passkey - la passkey "primaria" - ovunque incontrino per la prima volta il tuo flusso di pagamento (ad es. al checkout, nel portale online di una banca o nelle impostazioni del tuo account).
Schermate di creazione della passkey secondaria: Dopo che un utente ha registrato con successo la sua prima passkey, i login successivi su altri dispositivi possono attivare automaticamente un breve flusso "Aggiungi questo dispositivo". Ciò garantisce che l'utente ottenga rapidamente un accesso senza attriti con passkey su tutti i dispositivi pertinenti senza reinserire una password o passare a metodi di fallback.
Anche se un utente ha una passkey su un dispositivo, potrebbe apparire senza una passkey locale su un secondo dispositivo (a causa di nuove installazioni del sistema operativo, cancellazione dei cookie o semplicemente non avendo mai creato una passkey su quel dispositivo).
L'approccio di Corbado utilizza spesso un passaggio ibrido: l'utente può accedere con una passkey esistente sul proprio telefono o un metodo di fallback, quindi "ripristinare" istantaneamente la lacuna creando una passkey sul dispositivo corrente.
Questo processo di autoriparazione aiuta a mantenere alta la copertura ed elimina l'uso ripetuto del fallback in futuro.
Attraverso segnali cross-device e la "Passkey Intelligence" di Corbado, il sistema può rilevare quando un utente con una passkey esistente è passato a un dispositivo non registrato.
Se la tua strategia UX mira alla massima copertura, Corbado può chiedere automaticamente: "Vuoi aggiungere una passkey su questo dispositivo per non dover ricorrere al fallback la prossima volta?"
Gli utenti possono saltare questo passaggio se si trovano su un dispositivo occasionale, ma in genere apprezzano la comodità del login biometrico basato su passkey una volta che viene spiegato.
L'SDK di Corbado fornisce flussi di schermate distinti per la "creazione della prima passkey" (cioè la primissima volta che l'utente registra una credenziale) e la creazione su un "dispositivo secondario".
La messaggistica può differire: ad es. "Proteggi questo nuovo dispositivo con una passkey" vs. "Imposta la tua prima passkey".
Ciò garantisce chiarezza per gli utenti finali, che comprendono la differenza tra l'iscrizione iniziale e l'espansione della copertura a dispositivi aggiuntivi.
A volte la creazione della passkey può fallire a metà cerimonia o il sistema operativo dell'utente è obsoleto. In questi scenari, Corbado registra il tentativo parziale e suggerisce elegantemente possibili rimedi (reindirizzamento, fallback manuale o flusso QR cross-device).
L'utente può sempre riprovare ad aggiungere una passkey su quel dispositivo al successivo tentativo di login, o fare affidamento su una passkey esistente da un altro dispositivo.
Gli analytics di Corbado mostrano non solo quanti utenti hanno creato una passkey inizialmente, ma anche quanti hanno esteso le passkey a più dispositivi.
Puoi tracciare i tassi di copertura dei dispositivi (ad es. 1 dispositivo vs. 2 o più) e vedere come ciò si correla con un ridotto utilizzo del fallback o un miglior successo dei pagamenti.
Questo aiuta il tuo team a dare priorità alla formazione degli utenti, ai prompt delle app o ai flussi di iscrizione basati sulla banca per aumentare la penetrazione delle passkey multi-dispositivo.
Riepilogo: perché la copertura multi-dispositivo è importante
Senza una copertura coerente su tutti i dispositivi dell'utente, si rischia che gli utenti siano costretti a tornare a misure di autenticazione di fallback ogni volta che si trovano su un dispositivo "senza passkey". Questo interrompe l'esperienza fluida e mantiene alti i costi operativi (ad es. costi SMS, costi di supporto). Offrendo schermate di creazione di passkey secondarie, ripristino tramite fallback ibrido e prompt guidati dall'ambiente, Corbado garantisce che ogni utente possa alla fine mantenere le passkey su tutti i dispositivi che utilizza, promuovendo un'adozione complessiva più elevata e minimizzando quei frustranti momenti di fallback.
Uno dei più grandi malintesi nella creazione di un SDK di passkey di terze parti è che la
parte più difficile sia implementare le chiamate WebAuthn (ad es.
navigator.credentials.create()
o navigator.credentials.get()
).
In realtà, questa è la parte "facile" - una o due chiamate API per attivare la cerimonia di base. La vera complessità, e il vero determinante del successo, risiede nel garantire l'adozione su larga scala e nel costruire un intero ecosistema attorno a quelle chiamate API.
Di seguito sono riportati i punti chiave - rafforzati dalla Guida Passkey: Comprare o Costruire - che evidenziano perché le implementazioni minimali, limitate alla sola cerimonia, spesso non riescono a fornire risultati nel mondo reale.
Implementazione della cerimonia: Creare o autenticare una passkey di solito comporta
solo poche righe di JavaScript per chiamare navigator.credentials.create()
o
navigator.credentials.get()
.
Complessità reale: Garantire che il flusso di passkey funzioni su molti browser, gestisca elegantemente i fallimenti e offra un fallback per i sistemi più vecchi. Avrai anche bisogno di una gestione robusta delle sessioni, registrazione degli errori, analytics, strategie di copertura dei dispositivi e altro ancora.
Insidie impreviste: Una volta superata una "demo tecnica" delle passkey, si scoprono casi limite come blocchi cross-origin, restrizioni delle WebView integrate e complessità di sincronizzazione multi-dispositivo. Queste sono le incognite che fanno deragliare le implementazioni interne ingenue.
Cerimonia vs. Adozione: Anche se hai una cerimonia WebAuthn perfetta, una bassa adozione da parte degli utenti (ad es. <5% di tasso di utilizzo delle passkey) produrrà benefici minimi in termini di sicurezza o UX.
Approccio olistico: Un'implementazione di successo delle passkey richiede tutto, da prompt utente convincenti e copywriting testato con A/B a flussi di copertura multi-dispositivo, gestione dei fallback e analytics continui - ben oltre le chiamate di base della cerimonia.
Approfondimenti dalla Guida Comprare vs. Costruire: La guida sottolinea che promuovere l'adozione delle passkey - non solo abilitarle - determina in ultima analisi il ROI. Se gli utenti non si iscrivono e non usano attivamente le passkey, il progetto è effettivamente bloccato a "MFA 2.0" senza un miglioramento del tasso di conversione.
Fallback e gestione degli errori incompleti: La mancanza di una logica di fallback avanzata o di un debug in tempo reale può portare a blocchi degli utenti e a costi di supporto più elevati.
Copertura multi-dispositivo frammentata: Senza un piano per la sincronizzazione di dispositivi aggiuntivi o per "riparare" le lacune delle passkey, gli utenti tornano alle password ogni volta che cambiano piattaforma.
Analytics e test A/B limitati: La mancanza di dati sui funnel di creazione delle passkey o sull'utilizzo dell'ambiente significa che non puoi migliorare sistematicamente l'adozione o risolvere rapidamente i nuovi capricci dei browser.
UI pre-costruita e best practice: Invece di esporre solo gli endpoint della cerimonia, una soluzione adeguata (come Corbado) include schermate white-label, flussi di fallback, gestione degli errori e copertura cross-device.
Intelligenza adattiva e logging: Rilevamento automatico della probabile presenza di passkey, guida degli utenti a creare o correggere passkey mancanti e cattura di log di eventi granulari.
"Incognite" focalizzate sull'adozione: Molti dettagli - come il fallback basato su e-mail o come gestire i dispositivi aziendali - non sono ovvi finché gli utenti non iniziano a incontrarli nelle implementazioni reali.
Approfondimento sulla strategia di adozione: La Guida Passkey: Comprare o Costruire evidenzia come bilanciare costi, time-to-market e le complessità nascoste di una soluzione di passkey robusta.
Benchmark del mondo reale: Scopri come le implementazioni su larga scala di importanti banche e fornitori di e-commerce hanno superato le incognite che emergono dopo aver codificato la "semplice" logica della cerimonia.
Successo sostenuto: Investire in una piattaforma consolidata con modelli di adozione comprovati garantisce di non rimanere bloccati a reinventare la ruota e a scoprire costose sorprese lungo il percorso.
In sintesi
Collegare semplicemente la cerimonia WebAuthn non è sufficiente per ottenere un'adozione significativa delle passkey. Il vero successo dipende dall'orchestrazione di flussi end-to-end, come fallback, analytics, espansioni multi-dispositivo e percorsi utente testati con A/B. Affrontando le complessità sfumate che vanno oltre "solo la cerimonia", puoi trasformare il tuo progetto di passkey da una curiosità tecnica a una soluzione di autenticazione genuinamente fluida, ampiamente utilizzata e che consente di risparmiare sui costi.
Oltre alle complessità legate ai flussi cross-origin, all'adozione da parte degli utenti e alla gestione del ciclo di vita delle passkey, le considerazioni su hosting e deployment sono fondamentali per qualsiasi soluzione di passkey su larga scala. I fornitori di servizi di pagamento spesso devono affrontare rigide esigenze di conformità, residenza dei dati e resilienza che possono variare in modo significativo tra le regioni. Di seguito è riportato come Corbado (o soluzioni altrettanto robuste) affronta queste preoccupazioni:
Per conformarsi alla sovranità dei dati o a quadri normativi (ad es. GDPR in Europa, PIPEDA in Canada o NIST/HIPAA negli Stati Uniti), alcuni fornitori devono mantenere i dati entro specifici confini geografici.
Un'architettura agnostica per regione garantisce che il servizio di passkey possa essere implementato in qualsiasi regione AWS desiderata, soddisfacendo i mandati di conformità locali senza sacrificare le prestazioni o la scalabilità.
Questa flessibilità è particolarmente importante se la tua base di utenti si estende su più paesi, ognuno dei quali applica regole diverse per la gestione dei dati.
Per i flussi di autenticazione di pagamento critici, il downtime non è un'opzione. Corbado impiega deployment multi-AZ, distribuendo i componenti chiave su più zone di disponibilità.
Questa configurazione aiuta a garantire che se una AZ subisce un'interruzione o un problema di connettività, la tua infrastruttura di passkey in altre zone rimanga online, in modo che gli utenti possano continuare ad autenticarsi.
Il risultato è un sistema più resiliente che soddisfa rigorosi SLA per i servizi finanziari e i siti di e-commerce, dove anche un breve downtime può portare a un significativo impatto sui ricavi.
Alcuni fornitori di servizi di pagamento preferiscono un cluster privato dedicato, sia per un isolamento dei dati più stretto, controlli di conformità personalizzati o un maggiore controllo su patch e aggiornamenti.
Una soluzione flessibile può supportare entrambi gli estremi:
SaaS / Multi-Tenant: Veloce da implementare, costo inferiore, adatto a molti deployment di medie dimensioni.
Istanza Cloud dedicata: Un account e un'istanza di database separati nella regione scelta, per coloro che necessitano di isolamento o conformità aggiuntivi.
Le passkey devono gestire carichi di lavoro con picchi: enormi aumenti di traffico (ad es. picchi di shopping natalizio o vendite di biglietti per eventi) possono sovraccaricare i sistemi a capacità fissa.
Un back-end di passkey moderno scala orizzontalmente in tempo reale, aggiungendo o rimuovendo istanze di calcolo in base ai modelli di utilizzo. Questo auto-scaling garantisce prestazioni costanti senza intervento manuale.
Standard di settore come PCI-DSS, PSD2 SCA o ISO 27001 si applicano spesso ai fornitori di servizi di pagamento. Un fornitore di passkey robusto si integra tipicamente con i quadri di conformità noti fin da subito:
Crittografia a riposo e in transito: Proteggere i dati con TLS forte e crittografia lato server o lato client per le credenziali archiviate.
Logging e Audit Trail: Log dettagliati per ogni operazione di passkey, adatti per i regolatori o le indagini sugli incidenti.
Patch di sicurezza regolari: Patch automatiche del sistema operativo e dei container per tenere a bada le vulnerabilità, particolarmente rilevante in un ambiente multi-AZ fluido.
La vera resilienza si estende oltre una singola regione. Alcuni fornitori richiedono la replica cross-region per mantenere la continuità operativa durante disastri su larga scala.
La geo-ridondanza può replicare i dati delle passkey in una regione o continente diverso, garantendo che il downtime di un'intera regione non interrompa i flussi di autenticazione.
Riepilogo: Multi-AZ e indipendente dalla regione
Scegliere una soluzione di passkey che si adatti facilmente geograficamente, scali e resista sia a interruzioni locali che a disastri su larga scala è essenziale per i moderni fornitori di servizi di pagamento, specialmente quelli che operano in più paesi o sotto stretta conformità. Supportando deployment multi-AZ e configurazioni agnostiche per regione, Corbado (o soluzioni comparabili) garantisce che i servizi di passkey per i pagamenti rimangano sia disponibili che conformi, indipendentemente da dove risiedano i tuoi utenti o i tuoi dati.
Le passkey rappresentano davvero la prossima generazione di autenticazione sicura e facile da usare. Tuttavia, i fornitori di servizi di pagamento affrontano sfide uniche che il design tradizionale di WebAuthn non affronta direttamente. Queste limitazioni sono più pronunciate in:
Il rifiuto di Safari di consentire la creazione di passkey cross-origin (in particolare negli iframe), costringendo a un approccio basato su reindirizzamento o a fare affidamento su passkey create in precedenza.
La mancanza di supporto da parte di Apple per la Secure Payment Confirmation (SPC), che impedisce un flusso di pagamento standardizzato e senza attriti tra browser e piattaforme.
Tuttavia, le passkey rimangono essenziali per i fornitori di servizi di pagamento che desiderano offrire un'esperienza di checkout simile a quella di Apple Pay: semplificata, sicura e deliziosamente semplice per gli utenti finali. Di seguito è riportato come queste sfide possono essere affrontate e come Corbado aiuta.
Restrizioni cross-origin: Safari (e alcuni browser più vecchi) bloccano
navigator.credentials.create()
quando integrato tramite un iframe. Ciò significa che
non è possibile creare senza problemi nuove passkey in un flusso integrato nel merchant
su quei browser.
Mancato supporto SPC: Il rifiuto di Apple di adottare la SPC limita la capacità di standardizzare le conferme di pagamento cross-origin, costringendo i fornitori a mantenere approcci separati per Safari rispetto a Chrome/Edge.
Vincoli di WebView e app native: Le WebView integrate spesso interrompono i flussi di passkey, richiedendo sessioni del browser di sistema o altri approcci specializzati per gestire l'allineamento dell'origine del dominio.
Copertura frammentata dei dispositivi: Anche se l'utente crea una passkey su un dispositivo o browser, potrebbe non avere copertura su altri, causando l'uso di fallback.
Sfruttare una strategia ibrida (Iframe + Reindirizzamento):
Iframe per i browser che supportano pienamente le passkey cross-origin, offrendo un'interfaccia utente integrata e fluida.
Reindirizzamento come fallback per Safari o configurazioni incompatibili, garantendo che la creazione robusta di passkey sia sempre possibile.
WebView di sistema o reindirizzamento al browser nelle app native:
Invece di integrare iframe nelle app dei merchant, passare a ASWebAuthenticationSession (iOS) o Chrome Custom Tabs (Android) per preservare la continuità del dominio.
Toolkit focalizzato sull'adozione: Fornire prompt di creazione di passkey convincenti, flussi di copertura multi-dispositivo e passaggi di "ripristino" tramite fallback per mantenere alto l'utilizzo.
Analytics avanzati e test A/B:
Misurare continuamente i tassi di successo/fallback delle passkey, la copertura dell'ambiente e il feedback degli utenti per affinare i flussi.
Usare l'intelligenza delle passkey per presentare automaticamente le passkey solo quando il successo è probabile.
In questa guida, abbiamo evidenziato che collegare semplicemente
navigator.credentials.create()
non è sufficiente. Il vero successo dipende da un'elevata
adozione delle passkey, un'esperienza utente coerente e una copertura multi-dispositivo
resiliente. È qui che Corbado eccelle:
Supporto unificato per Iframe e Reindirizzamento: L'SDK di Corbado rileva automaticamente se un flusso di passkey integrato è fattibile (ad es. su Chrome o Edge) o se è necessario un reindirizzamento (ad es. Safari). Ciò massimizza la compatibilità senza richiedere ai merchant di mantenere più percorsi di codice.
Esperienza di pagamento One-Tap: Con la Passkey Intelligence, Corbado rileva istantaneamente se l'ambiente di un utente ha probabilmente una passkey valida, attivando un flusso "paga con passkey" senza attriti. Questo approccio è parallelo al checkout one-tap di Apple Pay, aumentando l'uso quotidiano delle passkey invece di relegarle a un passaggio MFA usato raramente.
Copertura multi-dispositivo robusta: Corbado fornisce flussi speciali per la creazione iniziale di passkey rispetto alle espansioni di passkey secondarie, in modo che ogni utente possa aggiungere rapidamente la copertura per nuovi dispositivi dopo aver effettuato l'accesso tramite fallback o QR cross-device.
Focus sull'adozione full-stack: Attraverso analytics integrati, test A/B e gestione degli errori, Corbado aiuta i fornitori a identificare i punti di attrito e a ottimizzare sistematicamente l'accettazione delle passkey. Questo si estende dai primi prompt di passkey delle banche alle esperienze di checkout dei merchant.
Hosting flessibile e conforme: I deployment multi-AZ e agnostici per regione di Corbado si allineano con la rigida conformità del settore dei pagamenti (PCI DSS, PSD2 SCA, ecc.), garantendo uptime e aderenza alle regole di residenza dei dati in tutto il mondo.
Mentre le politiche restrittive di Apple creano un attrito inevitabile, i fornitori di servizi di pagamento possono comunque implementare con successo le passkey di terze parti:
Combinando l'approccio integrato (iframe) con un fallback di reindirizzamento.
Adottando webview di sistema specializzate o flussi di browser esterni per le app native.
Concentrandosi su strategie di adozione robuste: copertura multi-dispositivo, "ripristino" tramite fallback, analytics avanzati e test A/B.
Corbado riunisce tutti questi elementi, offrendo una piattaforma di passkey aziendale che copre la registrazione delle passkey, l'uso one-tap, l'ottimizzazione guidata dagli analytics e l'hosting su scala globale. Il risultato: un'esperienza veramente fluida come quella di Apple Pay per il tuo servizio di pagamento, offrendo sia una maggiore sicurezza che un percorso utente superiore.
Next Step: Ready to implement passkeys at your bank? Our 80-page Banking Passkeys Report is available. Book a 15-minute briefing and get the report for free.
Get the Report
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.
Related Articles
Table of Contents