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

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 multifator (MFA). Recentemente, o PayPal adotou as passkeys como a sua principal solução de MFA autónoma, definindo uma tendência clara para os provedores de pagamento 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, em contrapartida, operam tipicamente em contextos de terceiros, onde os seus serviços (como formulários de pagamento 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 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 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.

As passkeys trazem o login biométrico e resistente a phishing para todas as camadas da pilha de pagamentos. Abaixo está uma análise de como cada interveniente na cadeia de valor dos pagamentos pode beneficiar da integração da autenticação com passkeys.

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 e reduzir a dependência de palavras-passe ou OTPs - levando a maior confiança e vendas.

Impacto: Autenticação sem palavra-passe 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. A adoção generalizada poderia transformar as passkeys no novo padrão para verificação do titular do cartão.

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.

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.

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.

Impacto: Aprovações de transações simplificadas com menos pagamentos recusados. Oportunidade: As empresas de processamento de pagamentos podem integrar a verificação por passkey nas suas APIs para reduzir o risco e suportar alternativas biométricas de SCA para fluxos conformes.

Impacto: Armazenamento seguro de credenciais e reautenticação sem atritos. Oportunidade: Provedores de carteiras como o Apple Pay e o Google Pay já usam fluxos semelhantes a 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:

A Mastercard lançou oficialmente o seu Serviço de Passkey de Pagamento, proporcionando uma experiência de autenticação sem palavra-passe que está incorporada nos fluxos EMV 3DS. Os utilizadores podem criar e usar passkeys associadas ao domínio de autenticação da Mastercard (por exemplo, verify.mastercard.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 e compatível com a PSD2 na indústria de pagamentos. Leia mais: Passkeys da Mastercard

A Visa 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 em vez de palavras-passe ou OTPs, a Visa pretende modernizar a experiência de checkout online com segurança e conveniência do utilizador melhoradas. Leia mais: Passkeys da VISA

A American Express ainda não lançou publicamente uma oferta de passkeys. No entanto, como membro do conselho da Aliança FIDO, é 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.

O PayPal 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 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

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

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.

A Stripe lançou o login com passkeys para o seu painel, permitindo que os programadores se autentiquem usando biometria. 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

A Braintree, uma empresa do PayPal, 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.

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.

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 devido a restrições de WebView incorporado.

A adoção de passkeys 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

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 de passkeys, especificamente adaptado para autorizações de pagamento seguras. A 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 no Safari, provavelmente como uma jogada estratégica para garantir que o 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 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.

Outra barreira crítica envolve a restrição deliberada da Apple à criação de passkeys em iframes de origem cruzada. Embora o Safari permita o uso de passkeys existentes para autenticação (navigator.credentials.get()) num iframe 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.

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 incorporado e autentica-se com uma passkey vinculada ao ID da Relying Party pay.provider.com.

Pontos Chave:

• Origem Cruzada: Como o iframe está num domínio diferente, deve configurar políticas de permissão para publickey-credentials-get e 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” (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.

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

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

As passkeys estão inerentemente ligadas a um domínio específico (o “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 como no Android. Como resultado, a aplicação nativa 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 e roubo de credenciais.

Do ponto de vista do dispositivo, a aplicação nativa 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 baseado no sistema (como o ASWebAuthenticationSession no iOS ou os Chrome Custom Tabs no 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.

Os WebViews incorporados (por exemplo, WKWebView no iOS ou o WebView 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.

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:

iOS (ASWebAuthenticationSession):

A Apple fornece o ASWebAuthenticationSession 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 é aberto, que partilha o seu estado com os cookies do Safari, permitindo que o diálogo da passkey comece imediatamente.

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 da BOSS no Android aqui:

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.

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.

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 técnica.

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.

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.

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

Detetar as capacidades do navegador com precisão continua a ser um desafio devido à granularidade reduzida do User-Agent e ao suporte inconsistente para Client Hints entre plataformas.

A análise tradicional é cada vez menos fiável, pois os navegadores reduzem os detalhes nas strings do User-Agent para proteger a privacidade do utilizador. Diferenciar detalhes essenciais - como Windows 10 vs. Windows 11, versões precisas do macOS ou arquiteturas de CPU - é agora difícil ou impossível usando apenas o User-Agent.

Embora os Client Hints 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, restringindo severamente a deteção precisa de funcionalidades em dispositivos Apple.

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.

As aplicações nativas de comerciantes frequentemente incorporam conteúdo web em WKWebView (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.

Como provedor de pagamento, a segurança forte e a conformidade regulatória (PCI, PSD2 SCA, etc.) são fundamentais:

• Cabeçalhos e Segurança de Conteúdo: Implementar cabeçalhos Permissions-Policy 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.

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

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.

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

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

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

• Definição: Percentagem de tentativas de login com passkey 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”.

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

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

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:

Independentemente de onde um utilizador é solicitado a criar uma passkey - seja no ambiente de banca 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 com a marca do design da VicRoads:

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.

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.

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.

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

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

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.

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

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.

Na Corbado, desenvolvemos um mecanismo de “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. Abaixo estão os elementos centrais que tornam isto possível.

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.

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/PIN - sem passos adicionais ou entradas de formulário necessárias.

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.

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.

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

Sempre que a Corbado escolhe iniciar ou saltar um prompt de passkey de um toque, 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.

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

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.

A Corbado organiza todos os eventos de passkeys num funil: desde o momento em que um utilizador é solicitado a criar uma passkey, 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.

Com base na nossa vasta experiência a ajudar empresas a implementar passkeys, focamo-nos em métricas que impactam diretamente o ROI e a satisfação do utilizador:

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

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.

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.

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.

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.

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.

Para os provedores de pagamento, simplesmente criar uma passkey 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.

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

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.

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

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.

O SDK da Corbado fornece fluxos de ecrã distintos para a “primeira criação de passkey” (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.

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.

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

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.

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

• Cerimónia vs. Adoção: Mesmo que tenha uma cerimónia WebAuthn perfeita, uma baixa adoção pelo utilizador (por exemplo, <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.

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

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

• Aprofundamento da Estratégia de Adoção: O Guia Comprar vs. Construir Passkeys destaca como equilibrar custo, 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 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.

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:

Para cumprir com a soberania de dados ou quadros regulatórios (por exemplo, RGPD na Europa, PIPEDA no Canadá ou NIST/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 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.

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 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 e sites de comércio eletrónico, onde mesmo uma breve interrupção pode levar a um impacto significativo na receita.

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

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.

Padrões da indústria como PCI-DSS, PSD2 SCA ou ISO 27001 aplicam-se frequentemente a provedores de pagamento. Um provedor de 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.

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.

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.

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.

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.

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.