---
url: 'https://www.corbado.com/pt/blog/passkeys-provedores-pagamento-sdk-terceiros'
title: 'Passkeys para Provedores de Pagamento: Como Construir um SDK de Terceiros'
description: 'Descubra como criar passkeys de origem cruzada como um provedor de pagamento. Comparamos iframes vs. redirecionamentos, mostramos como oferecer uma UX ao nível do Apple Pay e como usar analytics para aumentar a adoção.'
lang: 'pt'
author: 'Vincent Delitz'
date: '2025-07-15T13:24:50.262Z'
lastModified: '2026-03-25T10:03:51.427Z'
keywords: 'psp, provedor de serviços de pagamento, passkeys para provedores de pagamento'
category: 'Passkeys Strategy'
---

# Passkeys para Provedores de Pagamento: Como Construir um SDK de Terceiros

## 1. Introdução: Porque é que os Provedores de Pagamento precisam de Passkeys?

As passkeys estão a emergir como o método mais eficaz para proteger e autorizar transações
online, melhorando significativamente a segurança e a conveniência em comparação com a
tradicional [autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) multifator (MFA). Recentemente, o
[PayPal adotou as passkeys como a sua principal solução de MFA autónoma](https://www.forbes.com/sites/daveywinder/2025/03/01/paypal-security-2fa-codes-to-be-replaced-by-single-step-login/),
definindo uma tendência clara para os provedores de [pagamento](https://www.corbado.com/passkeys-for-payment) em
todo o mundo.

No entanto, as passkeys foram originalmente concebidas a pensar em contextos primários
(first-party), o que significa que funcionam de forma ótima quando os utilizadores se
autenticam diretamente no site ou na aplicação que detém as credenciais. Os provedores de
[pagamento](https://www.corbado.com/passkeys-for-payment), em contrapartida, operam tipicamente em contextos de
terceiros, onde os seus serviços (como formulários de [pagamento](https://www.corbado.com/passkeys-for-payment)
ou SDKs) são incorporados nos sites e aplicações dos comerciantes. Esta incompatibilidade
fundamental entre o design das passkeys e os modelos operacionais dos provedores de
pagamento apresenta limitações críticas para uma integração perfeita. Para enfrentar estes
desafios, devemos explorar duas questões críticas:

**1. Quais são as limitações atuais do uso de passkeys em contextos de terceiros para
provedores de pagamento?** **2. Como podem os provedores de pagamento superar estas
limitações para implementar com sucesso integrações de passkeys de terceiros?**

Ao examinar estas questões, revelaremos que os esforços contínuos da indústria para
adaptar as passkeys a contextos de terceiros - particularmente através de padrões web como
a Confirmação de Pagamento Segura (SPC) - são bloqueados por barreiras estratégicas
implicitamente impostas pela Apple. Especificamente, o suporte limitado da Apple para a
criação de passkeys de [origem cruzada](https://www.corbado.com/pt/blog/passkeys-iframes-webauthn) no Safari e a
falta de suporte do Padrão de Confirmação de Pagamento Segura representam um obstáculo
significativo, complicando a adoção transparente da
[autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) baseada em passkeys por provedores de pagamento
de terceiros. Compreender e superar estes obstáculos é essencial para qualquer provedor
que pretenda oferecer experiências de pagamento seguras e sem atritos.

## 2. Benefícios das Passkeys em todo o Ecossistema de Pagamentos

As passkeys trazem o login biométrico e
[resistente a phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo) para todas as camadas
da pilha de [pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos). Abaixo está uma
análise de como cada interveniente na cadeia de valor dos
[pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) pode beneficiar da integração da
[autenticação](https://www.corbado.com/pt/blog/passkeys-revolut) com passkeys.

### 2.1 Passkeys para Comerciantes

**Impacto:** Checkout mais rápido, maior conversão, menos abandonos de carrinho.
**Oportunidade:** Os comerciantes que oferecem passkeys através de SDKs ou fluxos de
redirecionamento podem imitar uma UX ao nível do [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) e
reduzir a dependência de palavras-passe ou OTPs - levando a maior confiança e vendas.

### 2.2 Passkeys para Titulares de Cartão / Clientes

**Impacto:** [Autenticação sem palavra-passe](https://www.corbado.com/pt/faq/bancos-que-oferecem-passkeys) e
fluida entre dispositivos. **Oportunidade:** As passkeys oferecem uma UX melhor do que os
OTPs ou códigos SMS e eliminam o risco de [phishing](https://www.corbado.com/glossary/phishing). A adoção
generalizada poderia transformar as passkeys no novo padrão para verificação do titular do
cartão.

### 2.3 Passkeys para Emissores (Banco Emissor)

**Impacto:** Prevenção de fraude mais forte. **Oportunidade:** Os emissores podem oferecer
autenticação step-up baseada em passkeys em fluxos 3DS, reduzindo os custos com OTPs e
melhorando a satisfação do utilizador.

### 2.4 Passkeys para Adquirentes (Banco Adquirente)

**Impacto:** Maior aceitação de transações e menos autenticações falhadas.
**Oportunidade:** Suportar passkeys através de PSPs pode melhorar os resultados dos
comerciantes e reduzir o atrito durante o checkout ou fluxos de faturação recorrente.

### 2.5 Passkeys para Provedores de Serviços de Pagamento (PSP) / Gateways de Pagamento

**Impacto:** Redução de fraude, melhor UX para o comerciante e conformidade melhorada.
**Oportunidade:** Ao incorporar ou redirecionar fluxos de passkeys, os PSPs podem fornecer
autenticação de última geração, mantendo a compatibilidade entre navegadores e aplicações
nativas.

### 2.6 Passkeys para Processadores de Pagamento

**Impacto:** Aprovações de transações simplificadas com menos
[pagamentos](https://www.corbado.com/pt/blog/credenciais-digitais-pagamentos) recusados. **Oportunidade:** As
[empresas de processamento de pagamentos](https://dashdevs.com/blog/best-payment-processing-companies/)
podem integrar a verificação por passkey nas suas APIs para reduzir o risco e suportar
alternativas biométricas de [SCA](https://www.corbado.com/pt/blog/psd2-passkeys) para fluxos conformes.

### 2.7 Passkeys para Provedores de Tokenização e Carteiras Digitais

**Impacto:** Armazenamento seguro de credenciais e reautenticação sem atritos.
**Oportunidade:** Provedores de carteiras como o [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) e
o [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) já usam fluxos semelhantes a passkeys.

## 3. Que Provedores de Pagamento já Lançaram Passkeys?

De seguida, analisamos brevemente os principais provedores de pagamento e de cartões de
crédito e vemos se e como implementaram as passkeys:

### 3.1 Passkeys da Mastercard

![a usar a passkey de pagamento da mastercard](https://www.corbado.com/website-assets/using_mastercard_payment_passkey_7f8121856f.png)

A [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) lançou oficialmente o seu **Serviço de Passkey
de Pagamento**, proporcionando uma experiência de
[autenticação sem palavra-passe](https://www.corbado.com/pt/faq/bancos-que-oferecem-passkeys) que está
incorporada nos fluxos EMV 3DS. Os utilizadores podem criar e usar passkeys associadas ao
domínio de autenticação da [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) (por exemplo,
verify.[mastercard](https://www.corbado.com/blog/mastercard-passkeys).com), permitindo um login biométrico seguro
em comerciantes participantes. Este lançamento representa um passo importante em direção à
autenticação [resistente a phishing](https://www.corbado.com/pt/blog/como-eliminar-senhas-por-completo) e
compatível com a [PSD2](https://www.corbado.com/blog/psd2-passkeys) na indústria de pagamentos. Leia mais:
[Passkeys da Mastercard](https://www.corbado.com/pt/blog/mastercard-passkeys)

### 3.2 Passkeys da Visa

A [Visa](https://www.corbado.com/blog/visa-passkeys) introduziu o seu **Serviço de Passkey de Pagamento Visa**,
integrando as passkeys no fluxo “Click to Pay”. Ao permitir que os utilizadores se
autentiquem de forma fluida usando [biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador) em
vez de palavras-passe ou OTPs, a [Visa](https://www.corbado.com/blog/visa-passkeys) pretende modernizar a
experiência de checkout online com segurança e conveniência do utilizador melhoradas. Leia
mais: [Passkeys da VISA](https://www.corbado.com/pt/blog/passkeys-da-visa)

### 3.3 Passkeys da American Express

A American Express ainda não lançou publicamente uma oferta de passkeys. No entanto, como
membro do conselho da Aliança [FIDO](https://www.corbado.com/pt/glossary/attestation), é provável que a American
Express lance uma solução de autenticação baseada em passkeys num futuro próximo, em linha
com as tendências mais amplas da indústria.

### 3.4 Passkeys do PayPal

![login com passkeys no paypal](https://www.corbado.com/website-assets/paypal_login_passkeys_3c664c9248.png)

O [PayPal](https://www.corbado.com/blog/paypal-passkeys) foi um dos primeiros provedores de pagamento a adotar as
passkeys. O seu lançamento suporta o login biométrico fluido para contas pessoais e
empresariais em todos os dispositivos. A passkey está vinculada ao domínio do
[PayPal](https://www.corbado.com/blog/paypal-passkeys) e já está disponível em muitas regiões. No entanto, a sua
implementação tem espaço para melhorias, especialmente no que diz respeito a fluxos
multidispositivo e deteção de plataforma. Leia mais:
[Passkeys do PayPal](https://www.corbado.com/pt/blog/passkeys-paypal-implementacao)

### 3.5 Passkeys da Klarna

A Klarna ainda não introduziu oficialmente o suporte a passkeys. Pelas nossas observações,
a Klarna depende muito de **WebViews incorporados** na sua aplicação e SDKs de checkout.
Como o Safari e o [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) restringem a criação de passkeys
em iframes / WebViews, esta pode ser uma razão pela qual a Klarna ainda não lançou as
passkeys.

### 3.6 Passkeys da Block (Square)

A Square introduziu o login com passkeys para o seu painel de programador e consola de
gestão, permitindo acesso seguro e sem palavra-passe a ferramentas internas. No entanto,
não foi feito nenhum anúncio sobre o suporte a passkeys em fluxos de pagamento ou APIs
para utilizadores finais ou comerciantes.

### 3.7 Passkeys da Stripe

A Stripe lançou o login com passkeys para o seu painel, permitindo que os programadores se
autentiquem usando [biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador). As passkeys para o
Stripe Checkout ou Elements ainda não estão disponíveis. Dada a forte defesa da Stripe por
**fluxos baseados em redirecionamento**, é provável que as passkeys - se implementadas em
pagamentos - sigam essa mesma arquitetura de redirecionamento.

### 3.8 Passkeys da BILL

Até ao momento, a BILL não fez quaisquer anúncios públicos ou atualizações de produtos
relacionadas com passkeys para autenticação.

### 3.9 Passkeys da Remitly

A Remitly não divulgou quaisquer planos ou informações públicas sobre a implementação da
autenticação com passkeys nos seus serviços.

### 3.10 Passkeys da Payoneer

Não existem relatórios públicos ou documentação de produtos que indiquem que a Payoneer
adotou ou está a testar o login ou fluxos de transação baseados em passkeys.

### 3.11 Passkeys da Adyen

A Adyen ainda não introduziu as passkeys nos seus fluxos de autenticação ou pagamento.
Nenhuma declaração pública ou documentação para programadores menciona o suporte a
passkeys.

### 3.12 Passkeys da Worldpay

A Worldpay não anunciou qualquer suporte para passkeys até ao momento. A sua pilha de
autenticação ainda depende de métodos tradicionais como palavras-passe, OTPs e fluxos
baseados em 3DS.

### 3.13 Passkeys da Checkout.com

A Checkout.com não lançou publicamente o suporte a passkeys. Não há atualizações para
programadores, publicações em blogues ou anúncios oficiais sobre a
[adoção de passkeys](https://www.corbado.com/pt/blog/passkeys-adocao-business-case).

### 3.14 Passkeys da AliPay

A AliPay não lançou oficialmente as passkeys. Dada a tendência crescente na autenticação
biométrica nos ecossistemas de pagamento chineses, um lançamento pode acontecer no futuro,
mas nenhuma documentação atual confirma isso.

### 3.15 Passkeys da Mollie

A Mollie não fez quaisquer declarações públicas ou atualizações de produtos sobre a adoção
de passkeys nos seus sistemas de autenticação ou checkout.

### 3.16 Passkeys da Amazon Pay

A Amazon lançou o suporte a passkeys para logins de utilizadores na sua plataforma
principal. Estender esta tecnologia ao **Amazon Pay** seria um passo natural,
especialmente porque muitos utilizadores já têm uma passkey registada na Amazon, o que
simplificaria significativamente o onboarding do utilizador durante o checkout.

### 3.17 Passkeys da Braintree

A Braintree, uma empresa do [PayPal](https://www.corbado.com/blog/paypal-passkeys), ainda não adotou oficialmente
a autenticação com passkeys. A sua documentação atual não menciona passkeys no contexto de
login de utilizador ou APIs de comerciante.

### 3.18 Passkeys da Link

A Link, a solução de checkout de um clique da Stripe, lançou passkeys que podem servir de
base para a estratégia de passkeys da Stripe em pagamentos ao consumidor. No entanto, a
Stripe não anunciou oficialmente o suporte a passkeys para a Link ou quaisquer planos
específicos para o lançamento.

![login com passkeys no link](https://www.corbado.com/website-assets/link_passkeys_login_88b6b731dd.png)

### 3.19 Passkeys da Afterpay

A Afterpay não divulgou quaisquer declarações ou funcionalidades relacionadas com o
suporte a passkeys. Tal como a Klarna, a sua integração de checkout é fortemente baseada
em aplicações, o que pode representar obstáculos técnicos para a
[adoção de passkeys](https://www.corbado.com/pt/blog/passkeys-adocao-business-case) devido a restrições de
[WebView](https://www.corbado.com/blog/native-app-passkeys) incorporado.

## 4. Porque é que os Esforços da Indústria para Padronizar as Passkeys são Bloqueados pela Apple?

A [adoção de passkeys](https://www.corbado.com/pt/blog/passkeys-adocao-business-case) por provedores de pagamento
de terceiros enfrenta obstáculos estratégicos, impulsionados principalmente pelas
políticas restritivas da Apple no Safari. Duas tentativas críticas de padronização têm
sido consistentemente impedidas:

- Confirmação de Pagamento Segura (SPC)

- Criação de Passkeys de Terceiros em Iframes

### 4.1 Onde é que a Apple Bloqueia a Confirmação de Pagamento Segura (SPC)?

A Confirmação de Pagamento Segura (SPC) representa o esforço mais significativo da
indústria - impulsionado principalmente pela Google - para permitir o uso fluido e de
[origem cruzada](https://www.corbado.com/pt/blog/passkeys-iframes-webauthn) de passkeys, especificamente adaptado
para autorizações de pagamento seguras. A [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
padroniza como os provedores de pagamento autenticam os utilizadores em vários sites de
comerciantes sem comprometer a segurança ou a experiência do utilizador. No entanto, a
Apple tem consistentemente negado suporte à [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) no
Safari, provavelmente como uma jogada estratégica para garantir que o
[Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) permaneça a solução de pagamento preferida e mais
fluida dentro do seu ecossistema. A recusa da Apple em adotar a
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) não só limita a implementação generalizada de
passkeys em contextos de terceiros, mas também atrasa efetivamente a adoção mais ampla da
autenticação de pagamento padronizada pela indústria.

Leia esta publicação de blogue sobre a SPC se quiser saber mais sobre os detalhes.

### 4.2 Como as Restrições de Iframe do Safari Afetam a Criação de Passkeys de Terceiros

Outra barreira crítica envolve a restrição deliberada da Apple à criação de passkeys em
iframes de [origem cruzada](https://www.corbado.com/pt/blog/passkeys-iframes-webauthn). Embora o Safari permita o
uso de passkeys existentes para autenticação (`navigator.credentials.get()`) num
[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) de terceiros, bloqueia explicitamente o registo
de passkeys (`navigator.credentials.create()`) em tais contextos.

Esta limitação restringe severamente os provedores de pagamento que dependem da criação de
novas passkeys de forma fluida durante o fluxo de checkout do comerciante.
Consequentemente, os provedores são forçados a abordagens baseadas em redirecionamento ou
devem depender de passkeys existentes previamente estabelecidas diretamente nos seus
próprios domínios. Esta decisão da Apple afeta diretamente a praticidade e a fluidez das
integrações dos comerciantes, criando um ponto de atrito significativo para consumidores e
provedores.

## 5. Como Construir um SDK de Pagamento com Passkeys de Terceiros para a Web

### 5.1 Estratégia A: Incorporar um iframe de Origem Cruzada (Prós e Contras)

Nesta abordagem, o comerciante inclui o seu formulário de pagamento num `<iframe>` servido
a partir do seu domínio de provedor de pagamento - por exemplo,
`https://pay.provider.com`. O utilizador permanece no domínio do comerciante (por exemplo,
`https://www.mystore.com`), vê a sua UI de pagamento no
[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) incorporado e autentica-se com uma passkey
vinculada ao ID da [Relying Party](https://www.corbado.com/glossary/relying-party) `pay.provider.com`.

Pontos Chave:

- **Origem Cruzada**: Como o [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) está num domínio
  diferente, deve configurar políticas de permissão para
  [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)
  para permitir operações de passkeys dentro do iframe.

- **Limitação na Criação**: Alguns navegadores (particularmente versões mais antigas e o
  Safari) ainda não permitem a criação de passkeys em iframes de origem cruzada. A
  autenticação (`navigator.credentials.get()`) é mais amplamente suportada, mas o registo
  (`navigator.credentials.create()`) pode falhar em certos ambientes, especialmente no
  Safari.

- **Ativação do Utilizador**: Os fluxos de passkeys normalmente requerem
  [“ativação transitória”](https://developer.mozilla.org/en-US/docs/Glossary/Transient_activation)
  (por exemplo, um clique direto num botão pelo utilizador). Certifique-se de que a sua
  interface de iframe aciona a cerimónia da passkey dentro de um evento iniciado pelo
  utilizador.

- **Segurança e UX**: A abordagem de iframe proporciona uma experiência de checkout fluida
  e em linha, mas se o navegador de um utilizador bloquear ou restringir cookies de
  terceiros ou armazenamento local, pode interromper o fluxo da passkey.

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

### 5.2 Estratégia B: Abordagem Baseada em Redirecionamento para Maior Compatibilidade

Com um fluxo baseado em redirecionamento, envia o utilizador do domínio do comerciante
para o seu domínio de pagamento, ou abre um novo separador/janela apontando para algo como
`https://pay.provider.com/checkout`. As passkeys são então criadas ou usadas diretamente
no seu domínio num contexto primário.

Pontos Chave:

- **Simplicidade Primária**: Todo o fluxo de trabalho da passkey (criação, autenticação)
  acontece no domínio do provedor de pagamento, pelo que não há restrições de origem
  cruzada.
  [Todos os principais navegadores suportam a criação e login com passkeys](https://passkeys.eu/device-support)
  em contextos primários.

- **UX de Redirecionamento**: O utilizador sai da página do comerciante (ou vê um pop-up)
  para completar a autenticação. Isto pode ser menos fluido, mas simplifica a arquitetura
  de passkeys e reduz as complexidades de origem cruzada.

- **Fallback para Navegadores Incompatíveis**: Pode degradar graciosamente se as passkeys
  não estiverem disponíveis (por exemplo, navegadores mais antigos), fornecendo métodos de
  login alternativos no seu domínio de pagamento sem necessitar de tratamento extra de
  permissões de origem cruzada.

![Abordagem de redirecionamento para maior compatibilidade](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_approach_for_broader_compatibility_701166520a.png)

## 6. SDK de Pagamento com Passkeys de Terceiros para Aplicações Nativas

A integração de passkeys em aplicações móveis nativas apresenta desafios únicos em
comparação com cenários baseados na web. As aplicações nativas para comerciantes (tanto no
[iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) como no
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) frequentemente incorporam fluxos de
pagamento dentro da aplicação usando WebViews incorporados para manter uma experiência de
utilizador fluida. No entanto, a implementação de autenticação com passkeys de terceiros
nestes contextos incorporados pode ser problemática devido a políticas rigorosas de origem
do navegador e limitações específicas da plataforma.

### 6.1 Porque é que as Passkeys de Provedores de Passkeys não podem ser usadas diretamente em Aplicações Nativas de Comerciantes

As passkeys estão inerentemente ligadas a um domínio específico (o
“[Relying Party](https://www.corbado.com/glossary/relying-party) ID”), que é um princípio de segurança
fundamental que garante que as credenciais não podem ser usadas indevidamente em sites ou
aplicações não relacionadas. Quando um provedor de pagamento cria passkeys sob o seu
próprio domínio - por exemplo, pay.provider.com - essas passkeys são estritamente
limitadas a esse domínio tanto no [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios) como no
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android). Como resultado, a
[aplicação nativa](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas) de um comerciante (que opera
naturalmente sob o seu próprio identificador de aplicação e domínio) não pode invocar
diretamente as passkeys do provedor como uma credencial “primária”. Fazer isso exigiria a
partilha de chaves privadas entre origens, o que os sistemas operativos e as
especificações WebAuthn proíbem explicitamente para prevenir
[phishing](https://www.corbado.com/glossary/phishing) e roubo de credenciais.

Do ponto de vista do dispositivo, a
[aplicação nativa](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas) do comerciante é uma “origem”
diferente do domínio do provedor de pagamento. Tentar autenticar-se nativamente contra
credenciais registadas numa origem separada quebraria o modelo de segurança fundamental
das passkeys, que é baseado na origem. É precisamente por isso que o uso de passkeys de
terceiros num contexto de comerciante depende de um navegador do sistema ou de um
[WebView](https://www.corbado.com/blog/native-app-passkeys) baseado no sistema (como o
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) no iOS ou os Chrome Custom Tabs no
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)). Estes fluxos especiais preservam o
contexto de domínio original do provedor - garantindo que as passkeys permanecem seguras e
ligadas à origem - enquanto ainda permitem que os utilizadores se autentiquem com o
provedor de pagamento dentro da aplicação de um comerciante. Nas secções seguintes,
exploraremos como isto funciona.

### 6.2 Desafios com WebViews Incorporados: Porque é que Quebram as Passkeys

Os WebViews incorporados (por exemplo, [WKWebView](https://www.corbado.com/blog/native-app-passkeys) no iOS ou o
[WebView](https://www.corbado.com/blog/native-app-passkeys) do Android) são amplamente favorecidos porque
permitem que as aplicações incorporem conteúdo web diretamente nas suas interfaces
nativas, oferecendo uma integração apertada e consistência de UX. No entanto, estes
ambientes incorporados são significativamente restringidos ao lidar com passkeys de
terceiros devido a políticas de origem e segurança:

- **Incompatibilidade de Origem**: As passkeys dependem estritamente das origens de
  domínio para o manuseamento seguro de credenciais. Um WebView incorporado opera sob o
  domínio do conteúdo que exibe (frequentemente o do comerciante), tornando desafiador ou
  impossível criar ou autenticar passkeys ligadas explicitamente ao domínio de um provedor
  de pagamento de terceiros.

- **Restrições de Segurança da Plataforma**: Tanto a Apple (iOS) como a Google (Android)
  têm restringido progressivamente as capacidades dos WebViews incorporados para
  autenticação, particularmente ao lidar com credenciais seguras. Estas restrições são
  projetadas para proteger a privacidade do utilizador e a segurança, mas tornam a
  implementação de passkeys de terceiros notavelmente mais complicada.

No geral, embora os WebViews incorporados sejam atrativos para os comerciantes do ponto de
vista da UX, eles introduzem limitações práticas significativas para a implementação de
fluxos robustos de autenticação com passkeys de terceiros.

### 6.3 Usar WebView do Sistema ou Redirecionamento para Passkeys de Terceiros

Dados os limites associados aos WebViews incorporados, os provedores de pagamento
geralmente adotam uma de duas estratégias alternativas para implementar de forma fiável as
passkeys de terceiros em aplicações móveis nativas:

#### 6.3.1 Usar WebView do Sistema

**iOS (ASWebAuthenticationSession):**

A Apple fornece o [ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) como um ambiente
seguro, semelhante a um navegador, fora do contexto da aplicação anfitriã. Ele partilha o
armazenamento de cookies com o navegador Safari padrão e suporta passkeys de terceiros de
forma fiável porque as credenciais se alinham com o domínio de origem do provedor de
pagamento.

O exemplo seguinte demonstra a funcionalidade “Check out with PayPal” dentro da aplicação
nativa da BOSS. Mostra como um webview do sistema
[ASWebAuthenticationSession](https://www.corbado.com/blog/native-app-passkeys) é aberto, que partilha o seu
estado com os cookies do Safari, permitindo que o diálogo da passkey comece imediatamente.

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

**Android (Chrome Custom Tabs):**

Da mesma forma, os Custom Tabs do Android oferecem um ambiente quase de navegador que
permite a criação e autenticação consistentes de passkeys. Tal como o
ASWebAuthenticationSession, os Custom Tabs são executados separadamente do contexto da
aplicação do comerciante, garantindo a integridade do domínio e das credenciais.

Veja o mesmo exemplo da [aplicação nativa](https://www.corbado.com/pt/blog/passkeys-aplicacoes-nativas) da BOSS
no Android aqui:

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

#### 6.3.2 Redirecionar para o Navegador Padrão

Outra abordagem envolve redirecionar os utilizadores para fora da aplicação nativa para o
navegador web padrão do dispositivo móvel (Safari no iOS, Chrome no Android). Isto garante
que o fluxo de pagamento - e, portanto, a gestão de passkeys - ocorre inteiramente num
contexto primário e confiável, associado ao domínio do provedor de pagamento. Os
utilizadores retornam então à aplicação do comerciante após a autenticação ou conclusão do
pagamento bem-sucedida. Esta opção é muito inconveniente para os clientes porque eles têm
de sair da aplicação.

Ambas as soluções requerem uma transição temporária dos utilizadores para fora do ambiente
da aplicação nativa do comerciante. Embora ligeiramente menos fluidas em comparação com
soluções incorporadas, estas abordagens melhoram significativamente a compatibilidade,
segurança e fiabilidade das operações de passkeys de terceiros.

Em última análise, os provedores de pagamento que desenvolvem SDKs nativos devem
equilibrar cuidadosamente as considerações de experiência do utilizador com as restrições
técnicas práticas. Apesar das preferências dos comerciantes por experiências totalmente
incorporadas, aproveitar os WebViews do sistema ou o redirecionamento para navegadores
externos continua a ser a melhor prática para garantir uma autenticação segura e fiável
com passkeys de terceiros em aplicações nativas.

![Redirecionar para o navegador padrão](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/redirect_to_default_browser_48b9e771a3.png)

## 7. Iframe vs. Redirecionamento: Que Abordagem para o Checkout com Passkey?

Escolher entre uma abordagem incorporada (iframe) e uma abordagem baseada em
redirecionamento para integrar passkeys de terceiros em SDKs de pagamento envolve avaliar
compromissos entre a experiência do utilizador, compatibilidade de navegadores,
complexidade técnica e preferências do comerciante.

### 7.1 Tabela de Comparação Detalhada das Abordagens Incorporada e de Redirecionamento

Ambas as soluções têm vantagens e desvantagens distintas, que os provedores de pagamento
devem considerar cuidadosamente com base no seu mercado-alvo, UX desejada e
[infraestrutura](https://www.corbado.com/passkeys-for-critical-infrastructure) técnica.

| **Aspeto**                                | **Abordagem Incorporada (Iframe)**                                                                                                                                                                                                                                                                              | **Abordagem de Redirecionamento**                                                                                                                                                                                                                                                                                                                |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Experiência do Utilizador**             | ✅ Altamente fluida; os utilizadores permanecem no site do comerciante durante todo o processo de checkout, melhorando a consistência da marca do comerciante.                                                                                                                                                  | ⚠️ Potencialmente disruptiva; os utilizadores saem do site do comerciante ou encontram pop-ups/novos separadores, introduzindo atrito.                                                                                                                                                                                                           |
| **Compatibilidade de Navegadores**        | ⚠️ Limitada devido ao bloqueio da criação de passkeys de origem cruzada pelo Safari da Apple e restrições de navegadores mais antigos; suporte parcial, principalmente para fluxos de autenticação.                                                                                                             | ✅ Robusta; amplamente compatível com todos os principais navegadores, pois opera num contexto de domínio primário.                                                                                                                                                                                                                              |
| **Suporte a Aplicações Nativas**          | ⚠️ Suporte fraco; quebra em webviews incorporados devido a políticas de origem rigorosas e restrições de segurança.                                                                                                                                                                                             | ✅ Forte suporte; facilmente tratado através de webviews do sistema ou navegadores externos, alinhando-se com as diretrizes da plataforma (iOS e Android).                                                                                                                                                                                       |
| **Atratividade para o Comerciante**       | ✅ Maior; os comerciantes preferem experiências totalmente incorporadas, pois mantêm o controlo sobre a UX e a marca.                                                                                                                                                                                           | ⚠️ Média; o redirecionamento pode causar atrito, impactando potencialmente as taxas de conversão do comerciante e a satisfação do cliente, a menos que seja tratado com elegância.                                                                                                                                                               |
| **Complexidade da Implementação Técnica** | ⚠️ Maior complexidade; requer configuração precisa de Políticas de Permissão e tratamento de várias peculiaridades de navegadores com limites em aplicações nativas.                                                                                                                                            | ✅ Menor complexidade; simples de implementar devido à simplicidade primária, reduzindo potenciais armadilhas de integração.                                                                                                                                                                                                                     |
| **Compatibilidade de Passkeys**           | ⚠️ Parcial; a autenticação é amplamente suportada, mas a criação de passkeys é notavelmente problemática devido a limitações de origem cruzada.                                                                                                                                                                 | ✅ Total; suporte completo para registo e autenticação de passkeys sem restrições de origem cruzada.                                                                                                                                                                                                                                             |
| **Manutenção e Suporte**                  | ⚠️ Maior sobrecarga devido a atualizações frequentes de navegadores e desafios de compatibilidade.                                                                                                                                                                                                              | ✅ Menor sobrecarga; manutenção mais simples, menos atualizações de compatibilidade de origem cruzada necessárias.                                                                                                                                                                                                                               |
| **Exemplo de Melhor Prática**             | Klarna: A Klarna sempre esteve extremamente focada em experiências de utilizador incorporadas e desaconselhou o uso de WebViews do sistema. Por esta razão, a Klarna está a ter dificuldades em oferecer uma experiência completa de passkey de terceiros aos seus clientes até à data de redação deste artigo. | PayPal: O PayPal sempre levou os utilizadores para o seu site, impondo uma abordagem baseada em redirecionamento devido ao seu poder de mercado e longa história. Portanto, a integração de passkeys em fluxos de pagamento foi direta e rapidamente alcançável, mesmo em contextos de terceiros, pois os WebViews do sistema já estavam em uso. |

### 7.2 Resumo: Escolher o Melhor Fluxo para o seu SDK de Pagamento

A abordagem incorporada (iframe) oferece uma experiência de utilizador fluida e com a
marca do comerciante, altamente atrativa para os comerciantes, mas é prejudicada pela
compatibilidade limitada de navegadores, particularmente a recusa do Safari em permitir a
criação de passkeys de origem cruzada. Esta limitação força os comerciantes e provedores a
soluções complexas e baseadas em contornos que muitas vezes comprometem a funcionalidade
ou levam a um suporte incompleto para o registo de passkeys.

Por outro lado, a abordagem de redirecionamento oferece compatibilidade abrangente entre
navegadores e plataformas móveis nativas, operando num contexto de domínio primário.
Simplifica significativamente a integração, melhora a fiabilidade e garante suporte total
para a criação e autenticação de passkeys. A principal desvantagem é o atrito potencial
criado ao redirecionar os utilizadores para fora do site ou aplicação do comerciante,
embora isso possa ser mitigado com um design de UX cuidadoso, expectativas claramente
comunicadas ou integrações com plataformas confiáveis como a Corbado.

Considerando estes fatores, uma abordagem híbrida é muitas vezes ideal, permitindo que os
provedores de pagamento aproveitem o modelo de iframe incorporado quando o navegador do
utilizador o suporta e recorram graciosamente a uma abordagem de redirecionamento caso
contrário. Esta estratégia combinada maximiza a compatibilidade, a atratividade para o
comerciante e a satisfação do cliente em diversos ambientes.

## 8. Melhores Práticas e Recomendações para SDKs de Passkeys de Origem Cruzada

A implementação de um SDK de pagamento com passkeys de terceiros envolve equilibrar a
experiência do utilizador, a compatibilidade de navegadores, as restrições de aplicações
nativas, a análise de dados e a segurança - especialmente dadas as barreiras específicas
da Apple (por exemplo, bloqueio da criação de passkeys de origem cruzada, falta de suporte
SPC). Abaixo estão as principais recomendações para garantir o melhor resultado possível
ao integrar passkeys em fluxos de pagamento web ou nativos.

### 8.1 Como Configurar uma Abordagem de SDK para Fluxos de Passkeys

Devido ao suporte variável dos navegadores e aos comportamentos inconsistentes da Apple, é
crucial suportar tanto uma abordagem incorporada (baseada em iframe) como uma abordagem de
redirecionamento:

- **Checkout com Iframe (Incorporado)**
    - Proporciona uma experiência fluida e na página para navegadores modernos que
      permitem operações de passkeys de origem cruzada (principalmente para autenticação).

    - Deve definir a [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) correta para
      publickey-credentials-get/publickey-credentials-create.

    - Note que o Safari e alguns navegadores mais antigos bloqueiam a criação de passkeys
      de origem cruzada em iframes.

- **Fluxo de Redirecionamento**
    - Suporta de forma fiável tanto o registo como o login com passkeys num contexto
      primário.

    - Ligeiramente mais atrito devido ao redirecionamento ou pop-up extra, mas
      universalmente mais seguro para compatibilidade entre navegadores.

    - Fallback ideal para o Safari, que atualmente não permite a criação de passkeys de
      terceiros em iframes.

Ao oferecer ambas as abordagens, pode decidir dinamicamente - ou deixar os comerciantes
decidirem - qual usar, maximizando a compatibilidade para todos os ambientes de
utilizador.

### 8.2 Detetar as Capacidades do Navegador (Safari vs. Chrome vs. Edge vs. Firefox)

Detetar as capacidades do navegador com precisão continua a ser um desafio devido à
granularidade reduzida do
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) e ao suporte
inconsistente para [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox)
entre plataformas.

#### 8.2.1 Complexidade da Análise do User-Agent

A análise tradicional é cada vez menos fiável, pois os navegadores reduzem os detalhes nas
strings do [User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) para proteger
a privacidade do utilizador. Diferenciar detalhes essenciais - como Windows 10 vs.
[Windows 11](https://www.corbado.com/blog/passkeys-windows-11), versões precisas do macOS ou arquiteturas de
CPU - é agora difícil ou impossível usando apenas o
[User-Agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox).

#### 8.2.2 Suporte Inconsistente de Client Hints

Embora os [Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) forneçam
dados de alta entropia de uma forma que respeita a privacidade, apenas os navegadores
baseados em Chromium os suportam totalmente. O Safari e o Firefox não oferecem suporte a
[Client Hints](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox), restringindo
severamente a deteção precisa de funcionalidades em dispositivos Apple.

#### 8.2.3 Restrições de Aplicações Incorporadas e Nativas:

Os WebViews incorporados normalmente restringem o acesso a informações detalhadas do
dispositivo e raramente suportam Client Hints. Esta limitação torna a deteção da
capacidade de passkeys especialmente desafiadora em contextos de aplicações nativas.

Considerando estas restrições, detetar de forma fiável o suporte a passkeys de origem
cruzada - particularmente em SDKs de pagamento de terceiros - requer uma combinação
cuidadosa de consultas dinâmicas de Client Hints (quando disponíveis), heurísticas de
fallback de User-Agent e comportamentos padrão conservadores para navegadores como o
Safari e o Firefox.

### 8.3 Lidar com Aplicações Nativas com Cuidado: WebView Incorporado vs. WebView do Sistema

As aplicações nativas de comerciantes frequentemente incorporam conteúdo web em
[WKWebView](https://www.corbado.com/blog/native-app-passkeys) (iOS) ou Android WebView, que são muito restritivos
para passkeys. As estratégias comuns incluem:

- **Sessões de Navegador do Sistema**: Usar ASWebAuthenticationSession (iOS) ou Custom
  Tabs (Android) para transferir a criação/login com passkeys para um contexto de
  navegador “primário” seguro.

- **Redirecionar para o Navegador Padrão**: Uma abordagem menos fluida, mas altamente
  fiável, para garantir a integridade do domínio para operações de passkeys.

### 8.4 Garantir Segurança e Conformidade (PCI)

Como provedor de pagamento, a segurança forte e a conformidade regulatória (PCI,
[PSD2](https://www.corbado.com/blog/psd2-passkeys) [SCA](https://www.corbado.com/pt/blog/psd2-passkeys), etc.) são fundamentais:

- **Cabeçalhos e Segurança de Conteúdo**: Implementar cabeçalhos
  [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) rigorosos e regras CSP robustas para
  fluxos de origem cruzada.

- **Registo e Monitorização**: Registar exaustivamente os eventos de criação e uso de
  passkeys para prevenção de fraudes e auditorias de conformidade.

- **Armazenamento Mínimo de PII**: Mapear utilizadores para passkeys usando
  identificadores com hash, reduzindo a exposição sob o RGPD ou leis de proteção de dados
  semelhantes.

- **Trilhas de Auditoria**: Registar cada evento de criação e autenticação de passkey para
  detetar anomalias e satisfazer auditorias de conformidade.

### 8.5 Teste e Monitorização Contínuos de Passkeys

As passkeys ainda estão a evoluir, pelo que precisará de verificações contínuas:

- **Testes Entre Navegadores e Sistemas Operativos**: Automatizar testes no Safari,
  Chrome, Edge, Firefox e nas principais versões de SO móvel.

- **Atualizações Frequentes**: Acompanhar as alterações nas especificações WebAuthn do
  W3C, nas diretrizes da Aliança [FIDO](https://www.corbado.com/pt/glossary/attestation) ou nas propostas de SPC.

- **Feedback do Utilizador e Taxas de Erro**: Registar erros de passkeys (criação ou
  login) para corrigir rapidamente os problemas, especialmente para utilizadores baseados
  em Apple.

### 8.6 KPIs Essenciais de Passkeys: Como Rastrear a Criação e o Login

Um quadro robusto de KPIs ajuda a rastrear se a sua integração de passkeys de terceiros
realmente melhora a segurança e a experiência do utilizador. Embora este artigo seja sobre
a implementação de SDKs, é importante ter em mente que a adoção de passkeys também é
fundamental neste caso de uso. A taxa de criação e a taxa de utilização de passkeys
precisam de análise e otimização cuidadosas.

#### 8.6.1 Taxa de Aceitação de Passkeys

- **Definição**: Percentagem de utilizadores que criam uma passkey com sucesso quando
  solicitado (por exemplo, no checkout ou na configuração da conta).

- **Porque é Importante**: Uma alta taxa de criação significa que o seu fluxo de
  onboarding/incentivo para passkeys é convincente e sem atritos.

- **Meta**: Deve visar uma taxa de 50-80%

#### 8.6.2 Taxa de Sucesso na Criação de Passkeys

- **Definição**: Entre os utilizadores que iniciam a cerimónia de criação (clicam em
  “Criar Passkey”), quantos finalizam sem abortar ou erro?

- **Porque é Importante**: Indica quão bem o seu fluxo de origem cruzada ou de
  redirecionamento está a funcionar.

- **Meta**: Idealmente, deve ter um número de \~95–100% assim que um utilizador opta por
  participar.

#### 8.6.3 Taxa de Utilização de Passkeys

- **Definição**: A percentagem do total de autorizações de pagamento (ou logins) feitas
  através de passkeys, em oposição a métodos de fallback.

- **Porque é Importante**: A criação não tem sentido se os utilizadores voltarem a usar
  métodos mais antigos.

- **Meta**: Uma taxa de 50–80% sinaliza uma forte adoção de passkeys.

#### 8.6.4 Taxa de Sucesso no Login com Passkeys

- **Definição**: Percentagem de tentativas de
  [login com passkey](https://www.corbado.com/pt/blog/aumentar-adocao-login-passkeys) que são bem-sucedidas sem
  erro ou fallback.

- **Porque é Importante**: Um reflexo da sua usabilidade no mundo real.

- **Meta**: Normalmente, deve exceder 90–95% para considerar as passkeys “sem atritos”.

#### 8.6.5 Utilização de Fallback

- **Definição**: Com que frequência os utilizadores falham com as passkeys a meio da
  cerimónia e mudam para uma palavra-passe ou OTP?

- **Porque é Importante**: Uma alta utilização de fallback sugere que barreiras técnicas
  ou de UX estão a impedir que as passkeys substituam os métodos legados.

- **Meta**: Idealmente, a utilização de fallback é inferior a 1-5%

#### 8.6.6 Métricas de Conversão e Fraude

Para provedores de pagamento, meça se as passkeys reduzem a fraude, aceleram o checkout ou
diminuem o abandono de carrinho. Combine dados de utilização de passkeys com métricas de
conversão de pagamento ou sucesso do [3-D Secure](https://www.corbado.com/glossary/3d-secure) para uma visão
holística.

Monitorizar estes KPIs ajuda a identificar quais ambientes ou jornadas de utilizador
precisam de melhoria - por exemplo, se o Safari no iOS tem uma taxa de abandono mais alta
devido a bloqueios de origem cruzada, pode direcionar sistematicamente esses utilizadores
para um fluxo de redirecionamento.

## 9. Como a Corbado Ajuda os Provedores de Pagamento a Alcançar o Sucesso com Passkeys

### 9.1 Criação Fluida de Passkeys: Ambientes de Banco, Plataforma e Comerciante

Um dos desafios mais críticos na construção de um SDK de passkeys de terceiros é
orquestrar um fluxo de criação suave e consistente - onde os utilizadores realmente
registam as suas passkeys. Quer isto ocorra no portal de um banco, nas configurações da
conta do próprio provedor de pagamento ou diretamente na página de checkout de um
comerciante, os passos centrais de registo de passkeys são muito semelhantes.
Consequentemente, a abordagem à criação de passkeys não muda fundamentalmente com base no
facto de incorporar o fluxo num iframe ou redirecionar o utilizador para uma página
primária; o que mais importa é fornecer ecrãs claros e fáceis de usar, gerir as restrições
de origem cruzada e rastrear as métricas essenciais que mostram quão eficazmente os
utilizadores adotam as passkeys. Abaixo estão os aspetos chave de um fluxo de criação de
passkeys de melhores práticas e como a Corbado os suporta:

#### 9.1.1 Ecrãs de Criação e Componentes de UI Uniformes

Independentemente de onde um utilizador é solicitado a
[criar uma passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys) - seja no ambiente de
[banca](https://www.corbado.com/passkeys-for-banking) online de um banco, no próprio site/aplicação do provedor
de pagamento ou no checkout de um comerciante - a Corbado fornece componentes
pré-construídos e personalizáveis para os prompts do utilizador, confirmações de sucesso e
tratamento de erros.

Estes componentes garantem uma aparência consistente, permitindo ao mesmo tempo a marca
branca para que cada banco ou comerciante possa reter os seus elementos de design únicos,
se necessário.

Veja o seguinte componente de UI para o ecrã de
[criação de passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys) com a marca do design da
[VicRoads](https://www.corbado.com/blog/vicroads-passkeys):

![UX otimizada da Corbado para passkeys](https://www.corbado.com/website-assets/Corbado_optimized_ux_passkeys_e5deec9ed9.png)

#### 9.1.2 Rastreamento e Análise Centralizados

A Corbado recolhe e unifica dados de todos os pontos de extremidade de criação:

- Sites ou aplicações de bancos onde as passkeys são inicialmente oferecidas.

- As configurações de conta pessoal do provedor de pagamento (onde os utilizadores podem
  gerir credenciais).

- Páginas de checkout de comerciantes que opcionalmente permitem a criação de passkeys “on
  the fly”.

Esta abordagem unificada facilita a medição da taxa de criação de passkeys, taxa de
sucesso na criação, pontos de abandono do utilizador e quaisquer erros técnicos - não
importa qual canal inicia o registo da passkey.

#### 9.1.3 KPIs e Testes A/B

A Corbado oferece funcionalidades de teste A/B para afinar as instruções no ecrã, o texto
dos botões e o timing dos prompts. Mudanças subtis na redação (por exemplo, “Crie uma
passkey agora - sem mais palavras-passe!” vs. “Proteja o seu próximo pagamento com uma
passkey!”) frequentemente produzem diferenças significativas na aceitação do utilizador.

Com base nos resultados do teste A/B, os seguintes KPIs podem ser otimizados:

- **Taxa de Criação**: Percentagem de utilizadores que, uma vez solicitados, configuram
  com sucesso uma passkey.

- **Taxa de Sucesso na Criação**: A proporção de utilizadores que terminam a cerimónia sem
  abortar ou erro.

- **Utilização de Fallback**: A taxa com que os utilizadores saltam a criação de passkeys
  em favor de métodos de login mais antigos.

- **Impacto na Conversão**: Para comerciantes, meça se a criação de passkeys no checkout
  reduz o abandono de carrinho.

#### 9.1.4 Contexto de Criação Flexível: Banco, Provedor de Pagamento ou Comerciante

Os utilizadores podem criar passkeys nos seguintes contextos:

- **Contexto do Banco**: Fluxos de criação acionados após um utilizador fazer login no seu
  banco, aproveitando a confiança e familiaridade do ambiente de
  [banca](https://www.corbado.com/passkeys-for-banking).

- **Configurações da Conta do Provedor de Pagamento**: Os utilizadores configuram passkeys
  diretamente nas suas configurações de “Meu Perfil” ou “Segurança” do domínio do provedor
  de pagamento.

- **Checkout do Comerciante**: Prompt no passo final do pagamento, especialmente se o
  utilizador não tiver criado anteriormente uma passkey. Isto pode ser incorporado
  (iframe) ou via redirecionamento.

Em cada cenário, a cerimónia de passkey subjacente segue os mesmos passos - confirmação do
utilizador, prompt biométrico/PIN e registo de credenciais. O SDK da Corbado garante que
as restrições de origem cruzada (se incorporado) ou o contexto de domínio primário (se
redirecionado) são tratados de forma fluida em segundo plano.

#### 9.1.5 Metadados Consistentes e Ligação de Identificadores

A Corbado anexa cada nova passkey ao identificador de utilizador apropriado - seja
“prefixoBanco_idUtilizador” ou uma referência de utilizador interna no sistema do provedor
de pagamento - para que todo o uso subsequente seja rastreável à conta de utilizador
correta.

Estes metadados também são cruciais para análises avançadas: por exemplo, ver como as
campanhas de criação de passkeys do RBC se comparam com as do TD, ou como as taxas de
criação diferem entre os checkouts de comerciantes e os fluxos diretos de “configurações
de conta”.

#### 9.1.6 UI Adaptativa e Tratamento de Erros

A mesma lógica do SDK da Corbado pode adaptar-se se a criação de passkeys de origem
cruzada é permitida (no Chrome ou Edge modernos) ou deve mudar graciosamente para um
redirecionamento para o Safari.

O relatório de erros integrado ajuda a identificar se algum subconjunto de utilizadores
falha consistentemente na criação de passkeys (por exemplo, versões mais antigas do iOS,
dispositivos Windows corporativos), para que a equipa de produto possa refinar as
instruções ou estratégias de fallback.

#### 9.1.7 Experiência Profunda da Corbado em Fluxos de Criação de Passkeys

A nossa equipa realizou extensos experimentos de criação de passkeys com clientes
empresariais, aprendendo quais frases, posicionamentos de botões e timings produzem as
melhores taxas de adoção.

Incorporamos estas melhores práticas em cada ecrã de criação, permitindo ainda a
personalização total para necessidades de marca e conformidade.

No geral, a criação de passkeys é a fase mais importante para garantir uma alta adoção:
mesmo o fluxo de [login com passkey](https://www.corbado.com/pt/blog/aumentar-adocao-login-passkeys) mais
elegante não importará se os utilizadores nunca registarem credenciais em primeiro lugar.
Ao oferecer ecrãs de criação uniformes e rastreáveis em todos os canais possíveis - banco,
domínio do provedor de pagamento ou checkout do comerciante - e instrumentá-los com
análises de KPIs e testes A/B, a Corbado ajuda os provedores de pagamento a impulsionar
uma adoção de passkeys verdadeiramente escalável, espelhando a experiência do utilizador
de soluções nativas como o Apple Pay.

### 9.2 Maximize o Uso de Passkeys para um Checkout Semelhante ao Apple Pay

Uma vez que um utilizador tenha criado uma passkey, o próximo passo é garantir que ele
realmente use essa passkey para pagamentos rápidos e sem atritos, como o Apple Pay
apresenta num fluxo de pagamento Apple Pay.

![checkout com passkeys apple pay](https://www.corbado.com/website-assets/apple_pay_passkeys_checkout_f63fb27017.jpeg)

Na Corbado, desenvolvemos um mecanismo de
“[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)”
que deteta automaticamente quando o ambiente de um utilizador provavelmente contém uma
passkey válida, permitindo uma verdadeira experiência de pagamento com
[um toque](https://docs.corbado.com/corbado-connect/features/one-tap-login). Abaixo estão
os elementos centrais que tornam isto possível.

#### 9.2.1 Fluxo One-Tap: Sem Reinserção de Credenciais

Quando um utilizador recorrente é reconhecido, o front-end da Corbado exibe um botão
dedicado (por exemplo, “Pagar com Passkey”) em vez de forçar a inserção de credenciais de
fallback.

![Uma captura de ecrã de uma página de login. O conteúdo gerado por IA pode estar incorreto.](bc386dced8be285ec3788060ed5cdb7b.png)

Um toque neste botão aciona o fluxo `get()` do WebAuthn (ou o prompt de passkey nativo),
permitindo que o utilizador se autentique instantaneamente via
[biometria](https://www.corbado.com/pt/blog/biometria-confirmacao-pagador)/PIN - sem passos adicionais ou
entradas de formulário necessárias.

#### 9.2.2 Passkey Intelligence: Deteção e Pontuação de Ambiente

O SDK da Corbado recolhe sinais (por exemplo, cookies de armazenamento local, uso anterior
bem-sucedido de passkeys, deteções de ambiente) para prever se o dispositivo + navegador
atual provavelmente tem uma passkey válida para este utilizador.

Se os cookies forem eliminados ou indisponíveis, a Corbado recorre a heurísticas
adicionais (por exemplo, ambiente conhecido existente do utilizador, dicas de utilizador
fornecidas pelo comerciante) para decidir se é seguro iniciar automaticamente um fluxo de
passkey.

Se evidências insuficientes sugerirem que uma passkey está presente, a UI oferece
graciosamente fluxos de fallback ou solicita ao utilizador que confirme que tem uma
passkey.

#### 9.2.3 Sem Armazenamento de PII, mas Consciente do Contexto

A Corbado não armazena informações de identificação pessoal (PII) como e-mails completos
ou nomes.

Em vez disso, o comerciante pode passar um identificador com hash ou mascarado (por
exemplo, um hash de e-mail ou um ID de utilizador interno). A Corbado usa isso para
procurar registos de passkeys potenciais e, em seguida, decide se inicia uma autenticação
com passkey ou reverte para uma abordagem mais genérica. Se suportado pelo provedor de
pagamento, podemos procurar a informação fornecida pelo comerciante para encontrar o ID de
utilizador interno.

Isto garante a privacidade do utilizador enquanto ainda permite uma correspondência de
ambiente de alta precisão.

#### 9.2.4 Lógica de Fallback e Recuperação Automática

Em cenários onde a passkey do utilizador pode ter existido, mas não pode ser detetada (por
exemplo, cookies foram limpos, novo dispositivo), a
[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)
da Corbado analisa cuidadosamente se faz sentido iniciar automaticamente um prompt de
passkey.

Em vez disso, o utilizador veria fluxos de fallback alternativos ou uma opção de
“digitalizar passkey de outro dispositivo”, preservando ainda um caminho rápido de volta
ao uso de passkeys se o utilizador puder confirmar manualmente que tem uma.

#### 9.2.5 Rastreamento Avançado e Insights de Cobertura

![visão geral dos gatilhos de eventos de processo](https://www.corbado.com/website-assets/process_events_trigger_overview_e101d943f1.png)

Sempre que a Corbado escolhe iniciar ou saltar um prompt de passkey de
[um toque](https://docs.corbado.com/corbado-connect/features/one-tap-login), essa decisão
é registada. Com o tempo, pode ver precisamente quais navegadores ou tipos de dispositivos
produzem a maior cobertura de passkeys em comparação com aqueles que frequentemente
revertem para fallback.

Este ciclo de feedback analítico permite identificar ambientes com baixo desempenho (por
exemplo, versões específicas do iOS ou Android) ou segmentos de utilizadores onde o uso de
passkeys permanece baixo - para que possa refinar as estratégias de onboarding ou
educação.

#### 9.2.6 Experiência Unificada de Um Toque em Todos os Casos de Uso

Independentemente de o utilizador chegar de uma campanha de criação de passkeys de um
banco ou diretamente no checkout de um comerciante, a lógica de
[um toque](https://docs.corbado.com/corbado-connect/features/one-tap-login) permanece
consistente.

A Corbado garante que, se uma passkey for encontrada (com base em cookies de domínio,
tokens de armazenamento local ou sinais de
[passkey intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)),
o utilizador é imediatamente apresentado com o fluxo de login/pagamento mais sem atritos.

**Resumo**

Em suma, o uso de passkeys com um toque é a recompensa final por criar passkeys em
primeiro lugar. Ao alavancar a Passkey Intelligence - uma mistura de deteção de ambiente,
uso mínimo de PII e lógica de fallback - a Corbado garante que os utilizadores são
apresentados com a autenticação por passkey apenas quando é verdadeiramente provável que
tenha sucesso. Isto reduz drasticamente as tentativas falhadas, evita a frustração do
utilizador e fomenta o uso habitual de passkeys, culminando num fluxo de pagamento de um
toque que rivaliza com a conveniência do Apple Pay ou outras experiências de pagamento
nativas.

### 9.3 Análise Rica para KPIs de Criação e Login de Passkeys

Além de simplesmente habilitar as passkeys, compreender quão eficazmente elas são adotadas
e usadas em diferentes dispositivos, navegadores e jornadas de utilizador é crucial. Os
provedores de pagamento precisam de dados concretos sobre se as passkeys genuinamente
reduzem o atrito, diminuem a fraude e melhoram a conversão. Com base nas melhores práticas
do Guia Comprar vs. Construir Passkeys, a Corbado oferece uma camada de análise rica que
permite rastrear, segmentar e otimizar o desempenho das passkeys em tempo real.

Abaixo estão os principais destaques.

#### 9.3.1 Funil de Passkeys Unificado: Criação → Utilização

![análise do funil de passkeys](https://www.corbado.com/website-assets/passkeys_funnel_analysis_436af30b87.png)

A Corbado organiza todos os eventos de passkeys num funil: desde o momento em que um
utilizador é solicitado a
[criar uma passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys), passando pelo registo
bem-sucedido, até aos logins/pagamentos subsequentes (utilização de passkeys).

Esta visualização do funil permite ver onde os utilizadores desistem - por exemplo,
quantos nunca iniciam a criação, quantos abandonam a meio da cerimónia ou quantos revertem
para métodos de fallback no login.

#### 9.3.2 KPIs Centrais do Guia Comprar vs. Construir Passkeys

Com base na nossa vasta experiência a ajudar empresas a
[implementar passkeys](https://www.corbado.com/pt/blog/tutorial-passkeys-como-implementar-em-apps-web),
focamo-nos em métricas que impactam diretamente o ROI e a satisfação do utilizador:

![kpis principais do guia de passkeys](https://www.corbado.com/website-assets/core_kpis_passkey_guide_e37543f9f2.png)

- **Taxa de Aceitação de Passkeys**: Quantos utilizadores que veem um prompt de criação
  realmente completam o registo da passkey?

- **Taxa de Sucesso na Criação de Passkeys**: Daqueles que iniciam a cerimónia (clicam em
  “Criar Passkey”), que percentagem finaliza sem erro ou abandono?

- **Taxa de Utilização de Passkeys**: Com que frequência os utilizadores recorrentes
  realmente escolhem passkeys para autenticação ou pagamento diário, em vez de
  palavras-passe ou OTP?

- **Taxa de Sucesso no Login com Passkeys**: A percentagem de tentativas de passkey que
  são bem-sucedidas sem fallback ou frustração do utilizador.

- **Utilização de Fallback**: Quantos utilizadores iniciam um fluxo de passkey, mas
  revertem para métodos mais antigos? Isto sinaliza potenciais barreiras de UX ou
  técnicas.

#### 9.3.3 Segmentação Granular por SO e Navegador

A Corbado etiqueta automaticamente cada evento com o sistema operativo (Windows, macOS,
iOS, Android) e o navegador (Chrome, Safari, Edge, Firefox, etc.).

Com esta segmentação, pode ver se, por exemplo, o Safari no iOS tem uma taxa de abandono
de passkeys mais alta, ou se o Chrome no Windows produz uma melhor adoção de passkeys.

Estes dados também ajudam a afinar as estratégias de fallback - especialmente se as
restrições de origem cruzada da Apple afetam a sua base de utilizadores mais do que o
previsto.

#### 9.3.4 Relatórios Dinâmicos e Dashboards em Tempo Real

Fornecemos vistas de dashboard para cada etapa do funil de passkeys: prompts de criação,
registos bem-sucedidos, logins de utilizadores, utilização de fallback.

Gráficos em tempo real permitem que os gestores de produto identifiquem tendências
rapidamente (por exemplo, se uma nova atualização do SO quebra os fluxos de passkeys).

Alertas automatizados podem notificar a sua equipa se as taxas de sucesso das passkeys
caírem significativamente - para que possa investigar prontamente um novo bug de navegador
ou problema de configuração.

#### 9.3.5 Depuração e Registos de Processo

Cada fluxo de passkey (da criação ao login) é registado com eventos passo a passo com
carimbo de data/hora, permitindo uma análise forense profunda.

Pode pesquisar rapidamente por hash de utilizador, ID de sessão ou assinatura de
dispositivo para ver exatamente onde um utilizador teve dificuldades ou qual código de
erro foi retornado.

Isto é crítico para implementações em larga escala, onde não pode depender de tickets de
suporte anedóticos, mas precisa de dados precisos para resolver os problemas dos
utilizadores.

#### 9.3.6 Otimização do Funil com Testes A/B

A plataforma de análise da Corbado suporta testes A/B integrados no funil de passkeys:
teste diferentes textos de CTA, prompts de criação, mensagens de fallback ou
posicionamento de botões “Criar Passkey” no fluxo de checkout.

Métricas como “Taxa de Aceitação de Passkeys” ou “Taxa de Fallback” podem ser medidas lado
a lado para cada variante.

Esta abordagem garante a melhoria contínua, espelhando o sucesso dos principais adotantes
de passkeys que refinam os fluxos ao longo do tempo.

#### 9.3.7 Acesso Flexível a Dados e Integração

Embora os dashboards da Corbado forneçam uma interface visual pronta a usar, também pode
exportar ou usar webhooks para pontos de dados chave (por exemplo, sucesso na criação de
passkeys, logins) para as suas ferramentas de BI ou SIEM.

Isto permite que os provedores de pagamento incorporem KPIs de passkeys em conjuntos de
análise mais amplos - rastreando o ROI das passkeys juntamente com outras métricas de
segurança, marketing ou operacionais.

**Resumo**

Ao medir e visualizar cada passo da jornada da passkey - através de combinações de
SO/navegador, fluxos de criação e cenários de login - a Corbado dá-lhe os insights
necessários para refinar continuamente a sua oferta de passkeys. Estas análises não apenas
confirmam que as passkeys estão habilitadas; elas provam se os utilizadores as estão
realmente a adotar em escala, identificam pontos de atrito e ajudam a impulsionar as taxas
de utilização ao ponto em que as passkeys genuinamente substituem as palavras-passe por
pagamentos seguros e sem atritos.

### 9.4 Sincronização Multidispositivo e “Inteligência” para Alta Adoção

Para os provedores de pagamento, simplesmente
[criar uma passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys) por utilizador muitas
vezes não é suficiente para oferecer uma experiência de autenticação verdadeiramente
fluida. Na realidade, os utilizadores trocam frequentemente de dispositivos - de portáteis
no trabalho para smartphones pessoais, tablets e até computadores familiares partilhados.
Garantir que cada dispositivo tem uma passkey válida para a mesma conta é crítico para
reduzir o atrito e prevenir o recurso a palavras-passe. O Apple Pay consegue isto ao poder
alavancar a Conta iCloud em todos os dispositivos ligados ao iCloud.

Abaixo está como a Corbado ajuda a manter a cobertura multidispositivo ao longo do ciclo
de vida do utilizador.

#### 9.4.1 Primeira Criação de Passkey vs. Dispositivos Adicionais

- **Ecrãs de Criação de Passkey Primária**: A Corbado foca-se inicialmente em fazer com
  que cada utilizador registe pelo menos uma passkey - a passkey “primária” - onde quer
  que encontrem pela primeira vez o seu fluxo de pagamento (por exemplo, no checkout, no
  portal online de um banco ou nas configurações da sua conta).

- **Ecrãs de Criação de Passkey Secundária**: Depois de um utilizador ter registado com
  sucesso a sua primeira passkey, os logins subsequentes noutros dispositivos podem
  acionar automaticamente um fluxo curto de “Adicionar este dispositivo”. Isto garante que
  o utilizador ganha rapidamente acesso sem atritos com passkey em todos os dispositivos
  relevantes sem reinserir uma palavra-passe ou recorrer a métodos de fallback.

#### 9.4.2 Autenticação Híbrida para “Reparação” de Dispositivos

Mesmo que um utilizador tenha uma passkey num dispositivo, ele pode aparecer sem passkey
local num segundo dispositivo (devido a instalações de SO novas, eliminação de cookies ou
simplesmente nunca ter criado uma passkey nesse dispositivo).

A abordagem da Corbado utiliza frequentemente um passo híbrido: o utilizador pode fazer
login com uma passkey existente no seu telemóvel ou um método de fallback, e depois
“reparar” instantaneamente a lacuna criando uma passkey no dispositivo atual.

Este processo de autorreparação ajuda a manter a cobertura alta e elimina o uso repetido
de fallback no futuro.

#### 9.4.3 Detetar e Guiar os Utilizadores para Adicionar Dispositivos em Falta

Através de sinais entre dispositivos e da “Passkey Intelligence” da Corbado, o sistema
pode detetar quando um utilizador com uma passkey existente mudou para um dispositivo não
registado.

Se a sua estratégia de UX [visa](https://www.corbado.com/blog/visa-passkeys) a cobertura máxima, a Corbado pode
solicitar automaticamente: “Gostaria de adicionar uma passkey neste dispositivo para não
ter de recorrer a fallback da próxima vez?”

![estratégia de ux para passkeys da corbado](https://www.corbado.com/website-assets/ux_strategy_passkeys_corbado_9884e5167c.png)

Os utilizadores podem saltar isto se estiverem num dispositivo de uso único, mas
normalmente apreciam a conveniência do login biométrico baseado em passkey assim que lhes
é explicado.

#### 9.4.4 Fluxos de UI Adaptativos

O SDK da Corbado fornece fluxos de ecrã distintos para a “primeira
[criação de passkey](https://www.corbado.com/pt/blog/melhores-praticas-criacao-passkeys)” (ou seja, a primeira
vez que o utilizador regista uma credencial) e a criação de “dispositivo secundário”.

A mensagem pode diferir: por exemplo, “Proteja este novo dispositivo com uma passkey” vs.
“Configure a sua primeira passkey”.

Isto garante clareza para os utilizadores finais, que entendem a diferença entre a
inscrição inicial e a expansão da cobertura para dispositivos adicionais.

#### 9.4.5 Lidar com Incompatibilidades e Erros

Por vezes, a criação de passkeys pode falhar a meio da cerimónia ou o SO do utilizador
está desatualizado. Nesses cenários, a Corbado regista a tentativa parcial e sugere
graciosamente possíveis soluções (redirecionamento, fallback manual ou fluxo de QR entre
dispositivos).

O utilizador pode sempre tentar novamente adicionar uma passkey nesse dispositivo na
próxima tentativa de login, ou confiar numa passkey existente de outro dispositivo.

#### 9.4.6 Métricas de Cobertura Contínuas

As análises da Corbado mostram não só quantos utilizadores criaram uma passkey
inicialmente, mas também quantos expandiram as passkeys para múltiplos dispositivos.

Pode rastrear as taxas de cobertura de dispositivos (por exemplo, 1 dispositivo vs. 2 ou
mais) e ver como isso se correlaciona com a redução do uso de fallback ou o melhor sucesso
de pagamento.

Isto ajuda a sua equipa a priorizar a educação do utilizador, os prompts da aplicação ou
os fluxos de inscrição baseados em bancos para aumentar a penetração de passkeys
multidispositivo.

**Resumo: Porque é que a Cobertura Multidispositivo Importa**

Sem uma cobertura consistente em todos os dispositivos do utilizador, corre o risco de os
utilizadores serem forçados a recorrer a medidas de autenticação de fallback sempre que
estiverem num dispositivo “sem passkey”. Isto quebra a experiência sem atritos e mantém os
custos operacionais altos (por exemplo, [taxas de SMS](https://www.corbado.com/pt/blog/custos-sms), sobrecarga de
suporte). Ao oferecer ecrãs de criação de passkeys secundárias, reparação de fallback
híbrida e prompts orientados pelo ambiente, a Corbado garante que cada utilizador pode
eventualmente manter passkeys em todos os dispositivos que usa - impulsionando uma maior
adoção geral e minimizando esses momentos frustrantes de fallback.

### 9.5 Tempo de Lançamento Acelerado: Porque é que as Soluções Holísticas Importam

Uma das maiores conceções erradas ao construir um SDK de passkeys de terceiros é que a
parte mais difícil é implementar as chamadas WebAuthn (por exemplo,
`navigator.credentials.create()` ou `navigator.credentials.get()`).

Na realidade, esta é a parte “fácil” - uma ou duas chamadas de API para acionar a
cerimónia básica. A verdadeira complexidade, e o verdadeiro determinante do sucesso,
reside em garantir a adoção em larga escala e construir um ecossistema completo em torno
dessas chamadas de API.

Abaixo estão os pontos chave - reforçados pelo Guia Comprar vs. Construir Passkeys - que
destacam por que as implementações mínimas, apenas de cerimónia, muitas vezes não
conseguem entregar resultados no mundo real.

#### 9.5.1 Desconhecidos Desconhecidos e Além da Cerimónia

- **Implementação da Cerimónia**: Criar ou autenticar uma passkey geralmente envolve
  apenas algumas linhas de JavaScript para chamar `navigator.credentials.create()` ou
  `navigator.credentials.get()`.

- **Complexidade Real**: Garantir que o fluxo de passkey funciona em muitos navegadores,
  lida graciosamente com falhas e oferece fallback para sistemas mais antigos. Também
  precisará de gestão de sessão robusta, registo de erros, análises, estratégias de
  cobertura de dispositivos e muito mais.

- **Armadilhas Imprevistas**: Assim que ultrapassa uma “demonstração técnica” de passkeys,
  descobre casos extremos como bloqueios de origem cruzada, restrições de WebView
  incorporado e complexidades de sincronização multidispositivo. Estes são os
  desconhecidos desconhecidos que descarrilam as construções internas ingénuas.

#### 9.5.2 A Adoção é o Verdadeiro Objetivo

- **Cerimónia vs. Adoção**: Mesmo que tenha uma cerimónia WebAuthn perfeita, uma baixa
  adoção pelo utilizador (por exemplo, &lt;5% de taxa de utilização de passkeys) produzirá
  benefícios mínimos de segurança ou UX.

- **Abordagem Holística**: Um lançamento bem-sucedido de passkeys exige tudo, desde
  prompts de utilizador convincentes e copywriting testado com A/B até fluxos de cobertura
  multidispositivo, tratamento de fallback e análises contínuas - muito além das chamadas
  básicas da cerimónia.

- **Insights do Guia Comprar vs. Construir**: O guia enfatiza que impulsionar a adoção de
  passkeys - não apenas habilitá-las - determina em última análise o ROI. Se os
  utilizadores não se inscreverem e não usarem ativamente as passkeys, o projeto fica
  efetivamente parado em “MFA 2.0” sem melhoria da taxa de conversão.

#### 9.5.3 Riscos de uma Implementação Mínima “Faça Você Mesmo”

- **Fallback e Tratamento de Erros Incompletos**: A falta de lógica de fallback avançada
  ou depuração em tempo real pode levar a bloqueios de utilizadores e custos de suporte
  mais elevados.

- **Cobertura Multidispositivo Fragmentada**: Sem um plano para sincronizar dispositivos
  adicionais ou “reparar” lacunas de passkeys, os utilizadores revertem para
  palavras-passe sempre que mudam de plataforma.

- **Análises e Testes A/B Limitados**: A falta de dados sobre os funis de criação de
  passkeys ou a utilização do ambiente significa que não pode melhorar sistematicamente a
  adoção ou resolver rapidamente novas peculiaridades dos navegadores.

#### 9.5.4 Soluções Holísticas: Mais do que Apenas uma API

- **UI Pré-construída e Melhores Práticas**: Em vez de apenas expor pontos de extremidade
  da cerimónia, uma solução adequada (como a Corbado) agrupa ecrãs de marca branca, fluxos
  de fallback, tratamento de erros e cobertura entre dispositivos.

- **Inteligência Adaptativa e Registo**: Deteção automática da provável presença de
  passkeys, guiando os utilizadores para criar ou corrigir passkeys em falta e capturando
  registos de eventos granulares.

- **“Desconhecidos Desconhecidos” Focados na Adoção**: Muitos detalhes - como fallback
  baseado em e-mail ou como lidar com dispositivos corporativos - não são óbvios até que
  os utilizadores comecem a encontrá-los em implementações reais.

#### 9.5.5 Recomendação para Ler o Guia Comprar vs. Construir

- **Aprofundamento da Estratégia de Adoção**: O Guia Comprar vs. Construir Passkeys
  destaca como equilibrar [custo](https://www.corbado.com/pt/blog/custos-sms), tempo de lançamento e as
  complexidades ocultas de uma solução robusta de passkeys.

- **Benchmarks do Mundo Real**: Aprenda como implementações em larga escala de grandes
  bancos e provedores de [comércio eletrónico](https://www.corbado.com/passkeys-for-e-commerce) superaram os
  desconhecidos desconhecidos que surgem depois de ter codificado a lógica “simples” da
  cerimónia.

- **Sucesso Sustentado**: Investir numa plataforma estabelecida com padrões de adoção
  comprovados garante que não fica preso a reinventar a roda - e a descobrir surpresas
  dispendiosas pelo caminho.

**Em Resumo**

Simplesmente ligar a cerimónia WebAuthn não é suficiente para alcançar uma adoção
significativa de passkeys. O verdadeiro sucesso depende da orquestração de fluxos de ponta
a ponta - como fallbacks, análises, expansões multidispositivo e jornadas de utilizador
testadas com A/B. Ao abordar as complexidades matizadas para além de “apenas a cerimónia”,
pode transformar o seu projeto de passkeys de uma curiosidade técnica numa solução de
autenticação genuinamente sem atritos, amplamente utilizada e que economiza custos.

### 9.6 Hospedagem e Implementação Flexíveis (Multi-AZ, Agnóstico à Região)

Além das complexidades em torno dos fluxos de origem cruzada, adoção pelo utilizador e
gestão do ciclo de vida das passkeys, as considerações de hospedagem e implementação são
críticas para qualquer solução de passkeys em larga escala. Os provedores de pagamento
lidam frequentemente com conformidade rigorosa, exigências de residência de dados e
requisitos de resiliência que podem variar significativamente entre regiões. Abaixo está
como a Corbado (ou soluções igualmente robustas) aborda estas preocupações:

#### 9.6.1 Implementações na Nuvem Agnósticas à Região

Para cumprir com a soberania de dados ou quadros regulatórios (por exemplo, RGPD na
Europa, [PIPEDA](https://www.corbado.com/blog/pipeda) no Canadá ou [NIST](https://www.corbado.com/blog/nist-passkeys)/HIPAA nos Estados
Unidos), alguns provedores devem manter os dados dentro de fronteiras geográficas
específicas.

Uma arquitetura agnóstica à região garante que o serviço de passkeys pode ser implementado
em qualquer região [AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) desejada, cumprindo os mandatos de
conformidade locais sem sacrificar o desempenho ou a escalabilidade.

Esta flexibilidade é particularmente importante se a sua base de utilizadores abrange
vários países, cada um aplicando diferentes regras de tratamento de dados.

#### 9.6.2 Alta Disponibilidade Multi-AZ (Zona de Disponibilidade)

Para fluxos críticos de autenticação de pagamento, o tempo de inatividade não é uma opção.
A Corbado emprega implementações multi-AZ, distribuindo componentes chave por múltiplas
zonas de disponibilidade.

Esta configuração ajuda a garantir que, se uma AZ sofrer uma interrupção ou problema de
conectividade, a sua [infraestrutura](https://www.corbado.com/passkeys-for-critical-infrastructure) de passkeys
noutras zonas permanece online - para que os utilizadores possam continuar a
autenticar-se.

O resultado é um sistema mais resiliente que cumpre SLAs rigorosos para
[serviços financeiros](https://www.corbado.com/passkeys-for-banking) e sites de
[comércio eletrónico](https://www.corbado.com/passkeys-for-e-commerce), onde mesmo uma breve interrupção pode
levar a um impacto significativo na receita.

#### 9.6.3 Hospedagem Gerida Autónoma ou Híbrida

Alguns provedores de pagamento preferem um cluster privado dedicado - seja para um
isolamento de dados mais rigoroso, verificações de conformidade personalizadas ou um
controlo mais profundo sobre patches e atualizações.

Uma solução flexível pode suportar ambos os extremos:

- **SaaS / Multi-Tenant**: Rápido de implementar, menor [custo](https://www.corbado.com/pt/blog/custos-sms), bem
  adequado para muitas implementações de médio porte.

- **Instância de Nuvem Dedicada:** Uma conta e instância de base de dados separadas na sua
  região escolhida, para aqueles que necessitam de isolamento ou conformidade adicional.

#### 9.6.4 Infraestrutura Escalável e Elástica

As passkeys devem lidar com cargas de trabalho com picos: grandes surtos de tráfego (por
exemplo, picos de compras de fim de ano ou vendas de bilhetes para eventos) podem
sobrecarregar sistemas de capacidade fixa.

Um back-end de passkeys moderno escala horizontalmente em tempo real, adicionando ou
removendo instâncias de computação com base nos padrões de uso. Este auto-scaling garante
um desempenho consistente sem intervenção manual.

#### 9.6.5 Ferramentas de Segurança e Conformidade

Padrões da indústria como [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/pt/blog/psd2-passkeys) ou
[ISO 27001](https://www.corbado.com/blog/cybersecurity-frameworks) aplicam-se frequentemente a provedores de
pagamento. Um [provedor de passkeys](https://www.corbado.com/pt/blog/fornecedores-passkeys) robusto normalmente
integra-se com quadros de conformidade conhecidos de fábrica:

- **Encriptação em Repouso e em Trânsito**: Proteger dados com TLS forte e encriptação do
  lado do servidor ou do cliente para credenciais armazenadas.

- **Registos e Trilhas de Auditoria**: Registos detalhados para cada operação de passkey,
  adequados para reguladores ou investigações de incidentes.

- **Patching de Segurança Regular**: Patching automático de SO e contentores para manter
  as vulnerabilidades afastadas, especialmente relevante num ambiente multi-AZ fluido.

#### 9.6.6 Recuperação de Desastres e Georredundância

A verdadeira resiliência estende-se para além de uma única região. Alguns provedores
exigem replicação entre regiões para manter a continuidade dos negócios durante desastres
em larga escala.

A georredundância pode replicar dados de passkeys numa região ou continente diferente,
garantindo que a interrupção de uma região inteira não paralisa os fluxos de autenticação.

**Resumo: Multi-AZ e Independente da Região**

Escolher uma solução de passkeys que escala facilmente, adapta-se geograficamente e
resiste tanto a interrupções locais como a desastres em larga escala é essencial para os
provedores de pagamento modernos - especialmente aqueles que operam em vários países ou
sob conformidade rigorosa. Ao suportar implementações multi-AZ e configurações agnósticas
à região, a Corbado (ou soluções comparáveis) garante que os serviços de passkeys de
pagamento permanecem disponíveis e conformes, não importa onde os seus utilizadores ou
dados residam.

## 10. Conclusão: Superar as Barreiras da Apple e Adotar as Passkeys

As passkeys representam de facto a próxima geração de autenticação segura e fácil de usar.
No entanto, os provedores de pagamento enfrentam desafios únicos que o design tradicional
do WebAuthn não aborda diretamente. Estas limitações são mais pronunciadas em:

1. A recusa do Safari em permitir a criação de passkeys de origem cruzada (particularmente
   em iframes), forçando uma abordagem baseada em redirecionamento ou a dependência de
   passkeys criadas anteriormente.

2. A falta de suporte da Apple para a Confirmação de Pagamento Segura (SPC), impedindo um
   fluxo de pagamento padronizado e sem atritos entre navegadores e plataformas.

No entanto, as passkeys continuam a ser essenciais para os provedores de pagamento que
procuram oferecer uma experiência de checkout semelhante à do Apple Pay: simplificada,
segura e deliciosamente simples para os utilizadores finais. Abaixo está como estes
desafios podem ser abordados e como a Corbado ajuda.

### 10.1 Questões Chave Respondidas: Limitações de Origem Cruzada e SPC

1. Quais são as limitações atuais do uso de passkeys em contextos de terceiros para
   provedores de pagamento?

- **Restrições de Origem Cruzada**: O Safari (e alguns navegadores mais antigos) bloqueiam
  o `navigator.credentials.create()` quando incorporado através de um iframe. Isto
  significa que não pode criar novas passkeys de forma fluida num fluxo incorporado no
  comerciante nesses navegadores.

- **Falta de Suporte SPC**: A recusa da Apple em adotar a SPC limita a capacidade de
  padronizar as confirmações de pagamento de origem cruzada, forçando os provedores a
  manter abordagens separadas para o Safari vs. Chrome/Edge.

- **Restrições de WebView e Aplicações Nativas:** Os WebViews incorporados frequentemente
  quebram os fluxos de passkeys, exigindo sessões de navegador do sistema ou outras
  abordagens especializadas para gerir o alinhamento da origem do domínio.

- **Cobertura de Dispositivos Fragmentada**: Mesmo que o utilizador crie uma passkey num
  dispositivo ou navegador, pode não ter cobertura noutros, causando o uso de fallback.

2. Como podem os provedores de pagamento superar estas limitações para implementar com
   sucesso integrações de passkeys de terceiros?

- Alavancar uma Estratégia Híbrida (Iframe + Redirecionamento):
    - Iframe para navegadores que suportam totalmente passkeys de origem cruzada,
      oferecendo uma UI incorporada fluida.

    - Redirecionamento como fallback para o Safari ou configurações incompatíveis,
      garantindo que a criação robusta de passkeys é sempre possível.

- WebView do Sistema ou Redirecionamento para o Navegador em Aplicações Nativas:
    - Em vez de incorporar iframes em aplicações de comerciantes, mude para
      ASWebAuthenticationSession (iOS) ou Chrome Custom Tabs (Android) para preservar a
      continuidade do domínio.

    - Kit de Ferramentas Focado na Adoção: Forneça prompts de criação de passkeys
      convincentes, fluxos de cobertura multidispositivo e passos de “reparação” de
      fallback para manter a utilização alta.

    - Análises Avançadas e Testes A/B:
        - Meça continuamente as taxas de sucesso/fallback de passkeys, a cobertura do
          ambiente e o feedback do utilizador para refinar os seus fluxos.

        - Use a inteligência de passkeys para apresentar automaticamente as passkeys
          apenas quando o sucesso é provável.

### 10.2 Como a Corbado Preenche a Lacuna para os Provedores de Pagamento

Ao longo deste guia, destacámos que simplesmente ligar o `navigator.credentials.create()`
não é suficiente. O verdadeiro sucesso depende da alta adoção de passkeys, experiência de
utilizador consistente e cobertura multidispositivo resiliente. É aí que a Corbado se
destaca:

- **Suporte Unificado para Iframe e Redirecionamento**: O SDK da Corbado deteta
  automaticamente se um fluxo de passkey incorporado é viável (por exemplo, no Chrome ou
  Edge) ou se um redirecionamento é necessário (por exemplo, Safari). Isto maximiza a
  compatibilidade sem exigir que os comerciantes mantenham múltiplos caminhos de código.
    - **Experiência de Pagamento com Um Toque**: Com a Passkey Intelligence, a Corbado
      deteta instantaneamente se o ambiente de um utilizador provavelmente tem uma passkey
      válida - acionando um fluxo “pagar com passkey” sem atritos. Esta abordagem paralela
      ao checkout de um toque do Apple Pay, impulsionando o uso diário de passkeys em vez
      de relegá-lo a um passo de MFA raramente usado.

    - **Cobertura Multidispositivo Robusta**: A Corbado fornece fluxos especiais para a
      criação inicial de passkeys versus expansões de passkeys secundárias, para que cada
      utilizador possa adicionar rapidamente cobertura para novos dispositivos após fazer
      login via fallback ou QR entre dispositivos.

    - **Foco na Adoção Full-Stack**: Através de análises integradas, testes A/B e
      tratamento de erros, a Corbado ajuda os provedores a identificar pontos de atrito e
      a otimizar sistematicamente a aceitação de passkeys. Isto estende-se desde os
      primeiros prompts de passkeys dos bancos até às experiências de checkout dos
      comerciantes.

    - **Hospedagem Flexível e Conforme**: As implementações multi-AZ e agnósticas à região
      da Corbado alinham-se com a conformidade rigorosa da indústria de pagamentos (PCI
      DSS, PSD2 SCA, etc.), garantindo o tempo de atividade e a adesão às regras de
      residência de dados em todo o mundo.

### 10.3 Conclusão Final: Construir uma Experiência de Passkey sem Atritos e Escalável

Embora as políticas restritivas da Apple criem um atrito inevitável, os provedores de
pagamento ainda podem implementar com sucesso passkeys de terceiros ao:

1. Combinar a abordagem incorporada (iframe) com o fallback de redirecionamento.

2. Adotar webviews de sistema especializados ou fluxos de navegador externos para
   aplicações nativas.

3. Focar em estratégias de adoção robustas: cobertura multidispositivo, “reparação” de
   fallback, análises avançadas e testes A/B.

A Corbado reúne todos estes elementos, oferecendo uma plataforma de passkeys empresarial
que cobre a inscrição de passkeys, o uso com um toque, a otimização orientada por análises
e a hospedagem em escala global. O resultado: uma experiência verdadeiramente sem atritos
como o Apple Pay para o seu próprio serviço de pagamento, oferecendo tanto segurança
reforçada como uma jornada de utilizador superior. experiência.