---
url: 'https://www.corbado.com/it/blog/passkey-fornitori-pagamento-sdk-terze-parti'
title: 'Passkey per fornitori di servizi di pagamento: come creare un SDK di terze parti'
description: '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.'
lang: 'it'
author: 'Vincent Delitz'
date: '2025-07-15T13:41:46.177Z'
lastModified: '2026-03-25T10:05:52.982Z'
keywords: 'psp, fornitore di servizi di pagamento, passkey per fornitori di pagamento'
category: 'Passkeys Strategy'
---

# Passkey per fornitori di servizi di pagamento: come creare un SDK di terze parti

## 1. Introduzione: perché i fornitori di servizi di pagamento hanno bisogno delle passkey?

Le passkey si stanno affermando come il metodo più efficace per proteggere e autorizzare
le transazioni online, migliorando significativamente la
[sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) e la praticità rispetto alla
tradizionale
[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) a più
fattori (MFA). Di recente,
[PayPal ha adottato le passkey come soluzione MFA principale e autonoma](https://www.forbes.com/sites/daveywinder/2025/03/01/paypal-security-2fa-codes-to-be-replaced-by-single-step-login/),
definendo una chiara tendenza per i fornitori di
[servizi di pagamento](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/passkeys-for-payment), al contrario, operano tipicamente in
contesti di terze parti, dove i loro servizi (come i moduli di
[pagamento](https://www.corbado.com/passkeys-for-payment) o gli SDK) sono integrati nei siti web e nelle app dei
[merchant](https://www.corbado.com/glossary/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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/iframe-passkeys-webauthn) in Safari
e il mancato supporto dello standard
[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) rappresentano un
ostacolo significativo, complicando l'adozione fluida
dell'[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless)
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.

## 2. I vantaggi delle passkey nell'ecosistema dei pagamenti

Le passkey portano un login basato su dati biometrici e resistente al
[phishing](https://www.corbado.com/glossary/phishing) a ogni livello dello stack di pagamento. Di seguito è
riportata un'analisi di come ogni attore nella catena del valore dei
[pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) può
beneficiare dell'integrazione
dell'[autenticazione](https://www.corbado.com/it/blog/come-passare-autenticazione-completamente-passwordless) con
passkey.

### 2.1 Passkey per i merchant

**Impatto:** Checkout più rapido, conversioni più elevate, meno carrelli abbandonati.
**Opportunità:** I [merchant](https://www.corbado.com/glossary/merchant) che offrono passkey tramite SDK o flussi
di reindirizzamento possono imitare una UX al livello di
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) e ridurre la dipendenza da password o OTP,
portando a una maggiore fiducia e a un aumento delle vendite.

### 2.2 Passkey per i titolari di carta / clienti

**Impatto:** [Autenticazione senza password](https://www.corbado.com/it/glossary/ctap) fluida su tutti i
dispositivi. **Opportunità:** Le passkey offrono una UX migliore rispetto a OTP o codici
SMS ed eliminano il rischio di [phishing](https://www.corbado.com/glossary/phishing). Un'ampia adozione potrebbe
trasformare le passkey nel nuovo standard per la verifica del titolare della carta.

### 2.3 Passkey per gli emittenti (banca emittente)

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

### 2.4 Passkey per gli acquirenti (banca acquirente)

**Impatto:** Maggiore accettazione delle transazioni e meno autenticazioni fallite.
**Opportunità:** Supportare le passkey tramite i
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) può migliorare i risultati dei
[merchant](https://www.corbado.com/glossary/merchant) e ridurre l'attrito durante il checkout o i flussi di
fatturazione ricorrente.

### 2.5 Passkey per i fornitori di servizi di pagamento (PSP) / Gateway di pagamento

**Impatto:** Riduzione delle frodi, migliore UX per i merchant e maggiore conformità.
**Opportunità:** Integrando o reindirizzando i flussi di passkey, i
[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) possono fornire un'autenticazione
di nuova generazione mantenendo la compatibilità tra browser e app native.

### 2.6 Passkey per gli elaboratori di pagamento

**Impatto:** Approvazioni delle transazioni semplificate con meno
[pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet) rifiutati.
**Opportunità:** Le
[aziende di elaborazione dei pagamenti](https://dashdevs.com/blog/best-payment-processing-companies/)
possono integrare la verifica con passkey nelle loro API per ridurre i rischi e supportare
alternative biometriche [SCA](https://www.corbado.com/it/blog/psd2-passkey) per flussi conformi.

### 2.7 Passkey per i fornitori di tokenizzazione e wallet

**Impatto:** Archiviazione sicura delle credenziali e riautenticazione senza attriti.
**Opportunità:** I fornitori di [wallet](https://www.corbado.com/blog/digital-wallet-assurance) come
[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)
utilizzano già flussi simili alle passkey.

## 3. Quali fornitori di servizi di pagamento hanno introdotto le 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:

### 3.1 Passkey di Mastercard

![utilizzo di una passkey di pagamento Mastercard](https://www.corbado.com/website-assets/using_mastercard_payment_passkey_7f8121856f.png)

[Mastercard](https://www.corbado.com/blog/mastercard-passkeys) ha lanciato ufficialmente il suo **Payment Passkey
Service**, fornendo un'esperienza di [autenticazione senza password](https://www.corbado.com/it/glossary/ctap)
integrata nei flussi EMV 3DS. Gli utenti possono creare e utilizzare passkey legate al
dominio di autenticazione di [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) (ad es.
verify.[mastercard](https://www.corbado.com/blog/mastercard-passkeys).com), consentendo un
[login biometrico](https://www.corbado.com/it/faq/cosa-sono-le-passkey) sicuro tra i merchant partecipanti.
Questo lancio rappresenta un passo importante verso un'autenticazione resistente al
[phishing](https://www.corbado.com/glossary/phishing) e conforme a [PSD2](https://www.corbado.com/blog/psd2-passkeys) nel settore dei
[pagamenti](https://www.corbado.com/it/blog/credenziali-digitali-pagamenti-apple-vs-google-wallet). Leggi di più:
Passkey di Mastercard

### 3.2 Passkey di Visa

[Visa](https://www.corbado.com/blog/visa-passkeys) 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](https://www.corbado.com/it/blog/biometria-consapevolezza-pagatore-dynamic-linking) invece di password
o OTP, [Visa](https://www.corbado.com/blog/visa-passkeys) mira a modernizzare l'esperienza di checkout online con
maggiore [sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) e praticità per l'utente.
Leggi di più: Passkey di [VISA](https://www.corbado.com/blog/visa-passkeys)

### 3.3 Passkey di American Express

American Express non ha ancora lanciato pubblicamente un'offerta di passkey. Tuttavia, in
qualità di membro del consiglio di amministrazione della
[FIDO Alliance](https://www.corbado.com/glossary/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.

### 3.4 Passkey di PayPal

![login con passkey di PayPal](https://www.corbado.com/website-assets/paypal_login_passkeys_3c664c9248.png)

[PayPal](https://www.corbado.com/blog/paypal-passkeys) è stato uno dei primi fornitori di servizi di pagamento ad
adottare le passkey. La loro implementazione supporta il
[login biometrico](https://www.corbado.com/it/faq/cosa-sono-le-passkey) senza interruzioni per account personali
e aziendali su tutti i dispositivi. La passkey è legata al dominio di
[PayPal](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/blog/paypal-passkeys)

### 3.5 Passkey di Klarna

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) limitano la
creazione di passkey in [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) /
[WebView](https://www.corbado.com/blog/native-app-passkeys), questo potrebbe essere uno dei motivi per cui Klarna
non ha ancora implementato le passkey.

### 3.6 Passkey di Block (Square)

Square ha introdotto il
[login con passkey](https://www.corbado.com/it/blog/migliori-pratiche-adozione-passkey-login) 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.

### 3.7 Passkey di Stripe

Stripe ha implementato il
[login con passkey](https://www.corbado.com/it/blog/migliori-pratiche-adozione-passkey-login) per la sua
dashboard, consentendo agli sviluppatori di autenticarsi tramite
[biometria](https://www.corbado.com/it/blog/biometria-consapevolezza-pagatore-dynamic-linking). 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.

### 3.8 Passkey di BILL

Ad oggi, BILL non ha fatto annunci pubblici o aggiornamenti di prodotto relativi alle
passkey per l'autenticazione.

### 3.9 Passkey di Remitly

Remitly non ha rivelato alcun piano o informazione pubblica sull'implementazione
dell'autenticazione con passkey nei suoi servizi.

### 3.10 Passkey di Payoneer

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.

### 3.11 Passkey di Adyen

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.

### 3.12 Passkey di Worldpay

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.

### 3.13 Passkey di Checkout.com

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.

### 3.14 Passkey di AliPay

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.

### 3.15 Passkey di Mollie

Mollie non ha rilasciato dichiarazioni pubbliche o aggiornamenti di prodotto riguardanti
l'adozione delle passkey nei suoi sistemi di autenticazione o checkout.

### 3.16 Passkey di Amazon Pay

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.

### 3.17 Passkey di Braintree

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.

### 3.18 Passkey di Link

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.

![login con passkey di Link](https://www.corbado.com/website-assets/link_passkeys_login_88b6b731dd.png)

### 3.19 Passkey di Afterpay

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](https://www.corbado.com/blog/native-app-passkeys) integrate.

## 4. Perché gli sforzi del settore per standardizzare le passkey sono bloccati da Apple?

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:

- [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC)
- Creazione di passkey di terze parti in [Iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)

### 4.1 Dove Apple blocca la Secure Payment Confirmation (SPC)?

La [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) rappresenta lo
sforzo più significativo del settore - guidato principalmente da Google - per consentire
un uso fluido e [cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) delle passkey,
specificamente progettato per autorizzazioni di pagamento sicure. La
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) standardizza il modo in cui i fornitori di
servizi di pagamento autenticano gli utenti su più siti di merchant senza compromettere la
[sicurezza](https://www.corbado.com/it/blog/come-abilitare-passkey-su-android) o l'esperienza utente. Tuttavia,
Apple ha costantemente negato il supporto per la [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
all'interno di Safari, probabilmente come mossa strategica per garantire che
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) rimanga la soluzione di pagamento preferita e più
fluida all'interno del suo ecosistema. Il rifiuto di Apple di adottare la
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-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.

### 4.2 In che modo le restrizioni degli Iframe di Safari influenzano la creazione di passkey di terze parti

Un'altra barriera critica riguarda la restrizione deliberata di Apple sulla creazione di
passkey all'interno di [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn)
[cross-origin](https://www.corbado.com/blog/iframe-passkeys-webauthn). 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.

## 5. Come creare un SDK di pagamento con passkey di terze parti per il web

### 5.1 Strategia A: Integrare un iframe cross-origin (Pro e contro)

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](https://www.corbado.com/glossary/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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/publickey-credentials-get)
  e
  [publickey-credentials-create](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy/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"](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation)
  (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.

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

### 5.2 Strategia B: Approccio basato su reindirizzamento per una maggiore compatibilità

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

![Approccio con reindirizzamento per una maggiore compatibilità](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_approach_for_broader_compatibility_701166520a.png)

## 6. SDK di pagamento con passkey di terze parti per app native

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) che su
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) spesso integrano i flussi di pagamento
all'interno dell'applicazione utilizzando [WebView](https://www.corbado.com/blog/native-app-passkeys) 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.

### 6.1 Perché le passkey dei fornitori di servizi di pagamento non possono essere utilizzate direttamente nelle app native dei merchant

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios) che su
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Di conseguenza,
un'[app nativa](https://www.corbado.com/it/blog/app-native-passkey) 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](https://www.corbado.com/it/blog/app-native-passkey) 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](https://www.corbado.com/blog/native-app-passkeys) su iOS o Chrome Custom Tabs su
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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.

### 6.2 Sfide con le WebView integrate: perché rompono le passkey

Le WebView integrate (ad es. [WKWebView](https://www.corbado.com/blog/native-app-passkeys) 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.

### 6.3 Utilizzo di WebView di sistema o reindirizzamento per passkey di terze parti

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:

#### 6.3.1 Usare la WebView di sistema

**iOS (ASWebAuthenticationSession):**

Apple fornisce [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) 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](https://www.corbado.com/blog/native-app-passkeys), che condivide il suo stato con i
cookie di Safari, consentendo l'avvio immediato del dialogo della passkey.

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

**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](https://www.corbado.com/it/blog/app-native-passkey) di BOSS su Android
qui:

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

#### 6.3.2 Reindirizzamento al browser predefinito

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.

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

## 7. Iframe o reindirizzamento: quale approccio scegliere per il checkout con passkey?

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.

### 7.1 Tabella di confronto dettagliata degli approcci integrato e con reindirizzamento

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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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. |

### 7.2 Riepilogo: scegliere il flusso migliore per il tuo SDK di pagamento

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.

## 8. Best practice e raccomandazioni per SDK di passkey cross-origin

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.

### 8.1 Come impostare un approccio SDK per i flussi di passkey

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](https://www.corbado.com/faq/enable-passkeys-iframe) 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](https://www.corbado.com/it/blog/migliori-pratiche-adozione-passkey-login) 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.

### 8.2 Rilevamento delle capacità del browser (Safari vs. Chrome vs. Edge vs. Firefox)

Rilevare accuratamente le capacità del browser rimane una sfida a causa della ridotta
granularità dello [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) e del
supporto incoerente per i
[Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) tra le piattaforme.

#### 8.2.1 Complessità del parsing dello User-Agent

Il parsing tradizionale è sempre più inaffidabile poiché i browser riducono i dettagli
nelle stringhe dello [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) per
proteggere la privacy degli utenti. Differenziare dettagli essenziali - come Windows 10
vs. [Windows 11](https://www.corbado.com/blog/passkeys-windows-11), versioni precise di macOS o architetture
della CPU - è ora difficile o impossibile usando solo lo
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox).

#### 8.2.2 Supporto incoerente dei Client Hints

Mentre i [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) 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.

#### 8.2.3 Vincoli delle app integrate e native:

Le WebView integrate tipicamente limitano l'accesso a informazioni dettagliate sul
dispositivo e raramente supportano i
[Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox). 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.

### 8.3 Gestire attentamente le app native: WebView integrata vs. WebView di sistema

Le app native dei merchant spesso integrano contenuti web in
[WKWebView](https://www.corbado.com/blog/native-app-passkeys) (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.

### 8.4 Garantire sicurezza e conformità (PCI)

Come fornitore di servizi di pagamento, una forte sicurezza e la conformità normativa
(PCI, [PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/it/blog/psd2-passkey), ecc.) sono fondamentali:

- **Header e sicurezza dei contenuti**: Implementare header
  [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) 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à.

### 8.5 Test e monitoraggio continui delle passkey

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](https://www.corbado.com/glossary/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.

### 8.6 KPI essenziali per le passkey: come tracciare creazione e login

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.

#### 8.6.1 Tasso di accettazione delle passkey

- **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%

#### 8.6.2 Tasso di successo nella creazione di passkey

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

#### 8.6.3 Tasso di utilizzo delle passkey

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

#### 8.6.4 Tasso di successo del login con 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".

#### 8.6.5 Utilizzo del fallback

- **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%

#### 8.6.6 Metriche di conversione e frode

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](https://www.corbado.com/glossary/3d-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.

## 9. Come Corbado aiuta i fornitori di servizi di pagamento ad avere successo con le passkey

### 9.1 Creazione fluida di passkey: ambienti di banche, piattaforme e merchant

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:

#### 9.1.1 Schermate di creazione e componenti UI uniformi

Indipendentemente da dove a un utente venga richiesto di
[creare una passkey](https://www.corbado.com/it/blog/migliori-pratiche-creazione-passkey) - che si tratti di un
ambiente di [online banking](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/blog/vicroads-passkeys):

![UX ottimizzata per le passkey di Corbado](https://www.corbado.com/website-assets/Corbado_optimized_ux_passkeys_e5deec9ed9.png)

#### 9.1.2 Tracciamento e analytics centralizzati

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.

#### 9.1.3 KPI e test A/B

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.

#### 9.1.4 Contesto di creazione flessibile: banca, fornitore di servizi di pagamento o merchant

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](https://www.corbado.com/passkeys-for-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.

#### 9.1.5 Metadati coerenti e collegamento degli identificatori

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

#### 9.1.6 UI adattiva e gestione degli errori

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.

#### 9.1.7 La profonda esperienza di Corbado nei flussi di creazione di passkey

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.

### 9.2 Massimizzare l'uso delle passkey per un checkout simile a quello di 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.

![checkout con passkey di Apple Pay](https://www.corbado.com/website-assets/apple_pay_passkeys_checkout_f63fb27017.jpeg)

In Corbado, abbiamo sviluppato un meccanismo di
"[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)"
che rileva automaticamente quando l'ambiente di un utente contiene probabilmente una
passkey valida, consentendo una vera esperienza di pagamento
[one-tap](https://docs.corbado.com/corbado-connect/features/one-tap-login). Di seguito
sono riportati gli elementi fondamentali che lo rendono possibile.

#### 9.2.1 Flusso One-Tap: nessuna reinserimento delle credenziali

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.

![Uno screenshot di una pagina di login. Il contenuto generato dall'IA potrebbe non essere corretto.](bc386dced8be285ec3788060ed5cdb7b.png)

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](https://www.corbado.com/it/blog/biometria-consapevolezza-pagatore-dynamic-linking)/PIN, senza
passaggi aggiuntivi o inserimenti di moduli.

#### 9.2.2 Passkey Intelligence: rilevamento e punteggio dell'ambiente

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.

#### 9.2.3 Nessuna archiviazione di PII, ma consapevole del contesto

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.

#### 9.2.4 Logica di fallback e ripristino automatico

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](https://docs.corbado.com/corbado-connect/features/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.

#### 9.2.5 Tracciamento avanzato e informazioni sulla copertura

![panoramica degli eventi di trigger del processo](https://www.corbado.com/website-assets/process_events_trigger_overview_e101d943f1.png)

Ogni volta che Corbado sceglie di avviare o saltare un prompt di passkey
[one-tap](https://docs.corbado.com/corbado-connect/features/one-tap-login), 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.

#### 9.2.6 Esperienza one-tap unificata tra i casi d'uso

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](https://docs.corbado.com/corbado-connect/features/one-tap-login) 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](https://docs.corbado.com/corbado-connect/features/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.

### 9.3 Analytics avanzati per i KPI di creazione e login delle passkey

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](https://www.corbado.com/it/blog/tutorial-passkey-come-implementare-le-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.

#### 9.3.1 Funnel unificato delle passkey: dalla creazione all'utilizzo

![analisi del funnel delle passkey](https://www.corbado.com/website-assets/passkeys_funnel_analysis_436af30b87.png)

Corbado organizza tutti gli eventi delle passkey in un funnel: dal momento in cui a un
utente viene richiesto di
[creare una passkey](https://www.corbado.com/it/blog/migliori-pratiche-creazione-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.

#### 9.3.2 KPI principali dalla Guida Passkey: Comprare o Costruire

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:

![KPI principali della guida alle passkey](https://www.corbado.com/website-assets/core_kpis_passkey_guide_e37543f9f2.png)

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

#### 9.3.3 Segmentazione granulare per sistema operativo e browser

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.

#### 9.3.4 Report dinamici e dashboard in tempo reale

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.

#### 9.3.5 Debug e log di processo

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.

#### 9.3.6 Ottimizzazione del funnel con test A/B

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.

#### 9.3.7 Accesso flessibile ai dati e integrazione

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.

### 9.4 Sincronizzazione multi-dispositivo e "Intelligence" per un'alta adozione

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.

#### 9.4.1 Creazione della prima passkey vs. dispositivi aggiuntivi

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

#### 9.4.2 Autenticazione ibrida per il "ripristino" del dispositivo

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.

#### 9.4.3 Rilevare e guidare gli utenti ad aggiungere dispositivi mancanti

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?"

![strategia UX per le passkey di Corbado](https://www.corbado.com/website-assets/ux_strategy_passkeys_corbado_9884e5167c.png)

Gli utenti possono saltare questo passaggio se si trovano su un dispositivo occasionale,
ma in genere apprezzano la comodità del [login biometrico](https://www.corbado.com/it/faq/cosa-sono-le-passkey)
basato su passkey una volta che viene spiegato.

#### 9.4.4 Flussi UI adattivi

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.

#### 9.4.5 Gestione di mancate corrispondenze ed errori

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.

#### 9.4.6 Metriche di copertura continue

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.

### 9.5 Time-to-market accelerato: perché le soluzioni olistiche sono importanti

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](https://www.corbado.com/it/blog/tutorial-passkey-come-implementare-le-passkey): Comprare o
Costruire - che evidenziano perché le implementazioni minimali, limitate alla sola
cerimonia, spesso non riescono a fornire risultati nel mondo reale.

#### 9.5.1 Incognite e oltre la cerimonia

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

#### 9.5.2 L'adozione è il vero obiettivo

- **Cerimonia vs. Adozione**: Anche se hai una cerimonia WebAuthn perfetta, una bassa
  adozione da parte degli utenti (ad es. &lt;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](https://www.corbado.com/it/blog/psd2-passkey) 2.0" senza un miglioramento del
  tasso di conversione.

#### 9.5.3 Rischi di un'implementazione minimale "fai da te"

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

#### 9.5.4 Soluzioni olistiche: più di una semplice API

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

#### 9.5.5 Raccomandazione di leggere la Guida Comprare vs. Costruire

- **Approfondimento sulla strategia di adozione**: La
  [Guida Passkey](https://www.corbado.com/it/blog/tutorial-passkey-come-implementare-le-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](https://www.corbado.com/passkeys-for-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](https://www.corbado.com/it/blog/costo-implementazione-passkey-fte) sui costi.

### 9.6 Hosting e deployment flessibili (Multi-AZ, agnostico per regione)

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:

#### 9.6.1 Deployment cloud agnostici per regione

Per conformarsi alla sovranità dei dati o a quadri normativi (ad es. GDPR in Europa,
[PIPEDA](https://www.corbado.com/blog/pipeda) in Canada o [NIST](https://www.corbado.com/blog/nist-passkeys)/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](https://www.corbado.com/blog/passkeys-amazon-cognito) 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.

#### 9.6.2 Alta disponibilità Multi-AZ (Availability Zone)

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](https://www.corbado.com/passkeys-for-critical-infrastructure)
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](https://www.corbado.com/passkeys-for-banking) e i siti di
[e-commerce](https://www.corbado.com/passkeys-for-e-commerce), dove anche un breve downtime può portare a un
significativo impatto sui ricavi.

#### 9.6.3 Hosting gestito autonomo o ibrido

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.

#### 9.6.4 Infrastruttura scalabile ed elastica

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.

#### 9.6.5 Strumenti di sicurezza e conformità

Standard di settore come [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)-DSS,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/it/blog/psd2-passkey) o
[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks) 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.

#### 9.6.6 Disaster Recovery e geo-ridondanza

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.

## 10. Conclusione: superare le barriere di Apple e adottare le passkey

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:

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

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

### 10.1 Domande chiave con risposta: limitazioni cross-origin e SPC

1. Quali sono i limiti attuali dell'uso delle passkey in contesti di terze parti per i
   fornitori di servizi di pagamento?

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

2. Come possono i fornitori di servizi di pagamento superare questi limiti per
   implementare con successo le integrazioni di passkey di terze parti?

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

### 10.2 Come Corbado colma il divario per i fornitori di servizi di pagamento

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

### 10.3 Conclusione finale: costruire un'esperienza passkey fluida e scalabile

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:

1. Combinando l'approccio integrato (iframe) con un fallback di reindirizzamento.

2. Adottando webview di sistema specializzate o flussi di browser esterni per le app
   native.

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