Credenciais Digitais e Pagamentos: A Estratégia da Apple Wallet vs. Google Wallet

Os pagamentos digitais estão sempre a mudar. Queremos que sejam mais rápidos, mais seguros e mais fáceis de usar. Ao mesmo tempo, as ferramentas de identidade digital, como as Credenciais Verificáveis (VCs) e os documentos de identidade móveis (mdocs), estão a melhorar. Elas oferecem novas formas para as pessoas mostrarem quem são. Então, a grande questão é: estas novas identidades digitais também podem tornar os pagamentos digitais muito melhores ou mais simples?

Este artigo analisa como as credenciais digitais (incluindo mdocs ISO e VCs enviadas usando OpenID4VC) se conectam com o mundo dos pagamentos. Abordaremos:

• Como as atuais carteiras de telemóvel (Apple Wallet, Google Wallet) lidam com informações de identidade versus cartões de pagamento.
• Por que os padrões atuais de identidade digital como os mdocs ISO 18013-5/7 não são realmente adequados como ferramentas de pagamento direto.
• Que papel protocolos como o OpenID4VC poderiam desempenhar em futuros métodos de pagamento.
• Como outras aplicações de carteira (de terceiros) podem lidar com funcionalidades de pagamento.
• Os principais problemas e o que poderia acontecer no futuro ao tentar usar credenciais verificáveis em sistemas de pagamento.

Este texto complementa a nossa outra discussão sobre Credenciais Digitais e Passkeys focando-se apenas nos pagamentos.

Para ver como as credenciais digitais poderiam ser usadas em pagamentos, primeiro precisamos de entender como as principais plataformas móveis de hoje e as suas carteiras integradas (Apple Wallet, Google Wallet) mantêm as informações de identidade separadas de como os pagamentos são processados.

As carteiras de plataforma nativas tornaram-se centros sofisticados para os utilizadores, mas normalmente mantêm uma distinção clara entre credenciais de identidade e instrumentos de pagamento:

• Credenciais de Identidade (ex: mDLs):
  • Apple Wallet: Suporta principalmente carteiras de motorista móveis (mDLs) e documentos de identidade estatais compatíveis com a norma ISO/IEC 18013-5. A partir da WWDC25, a Apple confirmou que o Safari 26 (no iOS 26) suportará a API de Credenciais Digitais do W3C para apresentação online, com um foco exclusivo no protocolo org.iso.mdoc. Isto destina-se a verificar atributos de identidade (ex: nome, idade, morada), não para pagamentos.
  • Google Wallet e Android Credential Manager: A Google Wallet também suporta mDLs baseados na norma ISO 18013-5. O Credential Manager subjacente do Android oferece uma estrutura mais flexível. Embora a sua implementação da API de Credenciais Digitais seja agnóstica em relação ao protocolo, o Android fornece uma implementação padrão que usa o OpenID4VP como mecanismo de transporte.
• Instrumentos de Pagamento (ex: Cartões de Crédito/Débito):
  • Tanto o Apple Pay (dentro da Apple Wallet) como o Google Pay (dentro da Google Wallet) utilizam tecnologias de pagamento estabelecidas e altamente regulamentadas. Estas baseiam-se principalmente nos padrões EMV (Europay, Mastercard, Visa), envolvendo tokenização (PANs de Dispositivo ou DPANs que substituem os números reais dos cartões para transações), elementos seguros ou segurança baseada em hardware para armazenar tokens de pagamento, e criptogramas dinâmicos para a segurança das transações.
  • Estes sistemas de pagamento interagem diretamente com as redes de pagamento existentes (Visa, Mastercard, Amex, etc.) e bancos adquirentes.

Ponto Principal: As carteiras de plataforma nativas operam atualmente com "pilhas" ou tecnologias separadas para credenciais de identidade versus cartões de pagamento. Um mdoc é apresentado para provar um atributo de identidade; um cartão tokenizado é apresentado para fazer um pagamento. Não há uso direto de um mdoc como um instrumento de pagamento dentro destes ecossistemas nativos.

A norma ISO/IEC 18013-5 define a estrutura de dados para mDLs e outros documentos de identidade móveis (mdocs). Embora excelente para verificação de identidade, o seu design não é adequado para uso direto como instrumento de pagamento:

Mesmo que um mdoc pudesse teoricamente ter campos de dados personalizados adicionados para conter um PAN ou um token de pagamento (como a ISO 18013-5 permite para namespaces personalizados), o padrão mdoc em si não define:

• Como gerar ou processar criptogramas de pagamento dinâmicos.
• Como realizar autorização online com uma rede de pagamentos.
• Os mecanismos de segurança necessários específicos para transações de pagamento (além da integridade dos dados de identidade).

Assim, atualmente não há forma de usar um mdoc ISO 18013-5 como um instrumento de pagamento direto.

Embora um mdoc não seja uma ferramenta de pagamento, pode desempenhar um papel num fluxo de "autenticação step-up", onde a identidade de um utilizador deve ser explicitamente verificada para uma ação de alto risco. Isto é distinto de usá-lo para executar o pagamento em si. O fluxo normalmente seria assim:

1. Autenticação Primária: O utilizador inicia sessão num serviço, muitas vezes com um método de baixo atrito como uma passkey.
2. Gatilho para Step-Up: Para uma ação de alta garantia (ex: uma grande transferência bancária, atualização de dados pessoais), o serviço requer uma verificação de identidade explícita.
3. Apresentação do mdoc: O serviço solicita a apresentação do mdoc do utilizador (ex: carteira de motorista). O utilizador apresenta os atributos necessários da sua carteira.
4. Verificação: O serviço verifica criptograficamente os dados do mdoc contra uma fonte confiável ou uma identidade previamente registada.

Neste modelo, o mdoc fornece uma prova de identidade forte e resistente a phishing para um momento específico de alto risco. No entanto, a transação financeira que se segue ainda utiliza os trilhos de pagamento estabelecidos. O mdoc verifica a pessoa, não o método de pagamento.

Embora os mdocs em si não sejam instrumentos de pagamento, protocolos como o OpenID for Verifiable Credentials (OpenID4VC – que abrange o OpenID4VP para apresentação e o OpenID4VCI para emissão) oferecem uma camada de transporte mais flexível.

Características Chave do OpenID4VC:

• Protocolo, Não Payload: O OID4VC define como solicitar e apresentar VCs, mas é largamente agnóstico sobre o formato do payload da VC em si. Pode transportar mdocs, VCs padrão do W3C (ex: em formato JWT ou SD-JWT), ou outros tipos de credenciais personalizadas.
• Amplitude de Casos de Uso: Esta flexibilidade permite que plataformas como o Android (através do seu Credential Manager) suportem pedidos de vários tipos de credenciais através de um mecanismo comum.
• Compatibilidade Futura para VCs de Pagamento: Se a indústria de pagamentos padronizasse um formato de credencial de "token de pagamento" ou "autorização de pagamento" verificável, o OID4VC poderia teoricamente transportar tal credencial entre a carteira de um utilizador e um comerciante/PSP.

No entanto, o OID4VC em si não é uma Solução de Pagamento:

• O papel do OID4VC é facilitar a troca de uma credencial. Ele não define o conteúdo da credencial de pagamento, as suas características de segurança, ou como interage com os sistemas de processamento de pagamentos.
• Para que o OID4VC seja útil para pagamentos, um formato de credencial de pagamento verificável amplamente adotado, seguro e padronizado precisaria primeiro de ser desenvolvido e suportado pelo ecossistema de pagamentos (emissores, adquirentes, redes). Isto não existe atualmente.

Além das carteiras de plataforma nativas, está a emergir um ecossistema crescente de carteiras de terceiros (ex: EUDI Wallet, carteiras fornecidas por bancos, carteiras especializadas da indústria). Estas carteiras devem navegar a diferença fundamental entre autenticação rápida e de baixo atrito e verificação de atributos de alta garantia, especialmente em contextos de pagamento.

O consenso emergente é que as passkeys são ideais para a autenticação central num serviço de pagamento, pois são resistentes a phishing e projetadas para uma experiência de utilizador sem interrupções. Injetar uma apresentação de credencial digital no passo crítico de confirmação de pagamento adicionaria um atrito significativo e provavelmente prejudicaria as taxas de conversão. Portanto, o papel principal das credenciais digitais está na fase única e de alta garantia de onboarding e KYC, que habilita as capacidades de pagamento, em vez de na transação em si. Como é que estas carteiras poderiam abordar os pagamentos, especialmente em conjunto com funcionalidades de identidade digital?

Para que uma carteira de terceiros autorize um pagamento, precisa de uma forma de ser invocada pela aplicação ou site do comerciante. Existem vários modelos de interação estabelecidos para isso, cada um com diferentes níveis de integração de plataforma e experiência do utilizador:

• Deep Linking App-to-App: Este é um método universal onde a aplicação do comerciante (nativa ou web) redireciona o utilizador para a aplicação da carteira de terceiros usando um esquema de URL personalizado (ex: eudi-wallet://...). Os detalhes da transação são passados como parâmetros no URL. Depois de o utilizador confirmar o pagamento na aplicação da carteira, esta redireciona de volta para a aplicação do comerciante usando outro deep link. Isto funciona tanto no iOS como no Android, mas envolve uma mudança de contexto visível entre aplicações.
• Seleção de Carteira Nativa: Com a Seleção de Carteira Nativa, uma aplicação pode invocar um serviço de sistema genérico que exibe todos os gestores de pagamento ou carteiras registados. O utilizador pode então selecionar a sua carteira preferida a partir de uma UI fornecida pelo sistema. Isto oferece uma sensação mais integrada do que o simples deep linking (API de Credenciais Digitais).
• Pagamentos Simples Baseados em Código QR: Este modelo é ideal para fluxos de desktop para móvel. O site do comerciante exibe um código QR contendo os detalhes da transação ou um URL. O utilizador digitaliza este código com a sua aplicação de carteira móvel, que depois lida independentemente com a confirmação no telemóvel. O backend da carteira comunica então a aprovação de volta ao sistema do comerciante.
• Fluxos Padronizados Entre Dispositivos (FIDO CTAP): Uma evolução do método de código QR, este usa protocolos como o Client to Authenticator Protocol (CTAP) da FIDO para criar um canal direto, seguro e encriptado entre o navegador do desktop (cliente) e a carteira móvel (atuando como um autenticador). Isto é mais seguro do que simples códigos QR, pois o navegador e o telemóvel comunicam diretamente, um modelo fortemente apoiado pela Google tanto para passkeys como para credenciais digitais.
• Integração Direta de Backend: Em alguns sistemas de circuito fechado, a aplicação da carteira de terceiros pode interagir diretamente com um Provedor de Serviços de Pagamento (PSP) ou com o backend de uma instituição financeira para processar pagamentos, muitas vezes usando APIs proprietárias.

Estes modelos fornecem a "camada de transporte" para iniciar uma confirmação de pagamento, dentro da qual um fluxo criptográfico (como o detalhado para a EUDI Wallet) pode então ocorrer.

Com os anúncios na WWDC25, o cenário de como os navegadores lidam com credenciais digitais tornou-se muito mais claro, solidificando a separação entre verificação de identidade e processamento de pagamentos. As plataformas estão a permitir que carteiras de terceiros interajam com navegadores para verificação de identidade através da API de Credenciais Digitais do W3C, mas as abordagens estão a divergir:

• Posição da Apple (Confirmada na WWDC25): A Apple anunciou oficialmente o suporte para a API de Credenciais Digitais no Safari 26 (a ser lançado com o iOS 26). Conforme detalhado na sua sessão "Verify identity documents on the web", a implementação suporta exclusivamente o protocolo org.iso.mdoc. Isto permite que os sites solicitem informações verificáveis de mdocs na Apple Wallet ou em outras aplicações de provedor de documentos de terceiros registadas, mas não suporta o protocolo mais genérico OpenID4VP. Com o suporte crescente para credenciais digitais e integrações web aprimoradas, manter o desempenho e a segurança do sistema torna-se ainda mais crucial - ferramentas como o CleanMyMac ajudam a garantir que seu Mac funcione sem problemas à medida que essas tecnologias evoluem.
• Posição da Google: O Credential Manager do Android permite que carteiras de terceiros se registem como gestores de pedidos de credenciais. A sua implementação da API de Credenciais Digitais no Chrome foca-se no uso do OpenID4VP como o principal protocolo de transporte. Embora o OpenID4VP possa transportar um mdoc como payload, o protocolo em si é diferente da abordagem direta org.iso.mdoc da Apple.

Crucialmente, estas integrações de navegador são para atributos de identidade, não para tratar o mDoc ou VC apresentado como um instrumento de pagamento.

Se um utilizador apresentar um mDL da sua carteira a um site através da API de Credenciais Digitais do navegador, esse site pode usar a informação para preenchimento automático de morada ou verificação de idade durante o checkout. No entanto, o passo de pagamento real ainda exigiria uma interação separada com um método de pagamento (ex: Apple Pay, Google Pay, ou inserir detalhes do cartão). A API do navegador em si não foi projetada para iniciar ou processar uma transação financeira usando uma credencial de identidade.

A Carteira de Identidade Digital da UE (EUDI) serve como um excelente estudo de caso de como uma carteira de terceiros deve navegar no cenário complexo e real dos sistemas operativos e da disponibilidade de APIs. Entre as suas muitas funções, dois dos casos de uso mais proeminentes são a verificação de identidade e a confirmação de pagamento, e os caminhos técnicos para realizar estas duas tarefas são diferentes, especialmente ao comparar a estrutura flexível do Android com a implementação mais rígida da Apple.

A tabela seguinte detalha como a EUDI Wallet pode ser invocada para verificação de identidade ou autorização de pagamento, destacando o suporte diferente entre as plataformas.

Principais Conclusões da Comparação:

• API de Credenciais Digitais: Este padrão emergente do W3C é agnóstico em relação ao protocolo e bem suportado para identidade em ambas as plataformas. Para a sua implementação, o Android fornece um fluxo padrão usando o protocolo flexível OpenID4VP, que pode transportar vários formatos de credenciais. A implementação da Apple, em contraste, é estritamente para o formato org.iso.mdoc. Crucialmente, os navegadores definem o âmbito desta API para casos de uso de identidade, não para iniciar pagamentos.
• Seletor de Carteira Nativo: Ambos os sistemas operativos fornecem uma UI nativa para selecionar uma carteira, mas com limitações diferentes. O Android oferece um seletor tanto para aplicações de identidade como de pagamento. O iOS fornece um seletor para aplicações "Provedor de Documentos" de identidade registadas, mas não oferece um para aplicações de pagamento de terceiros.
• Deep Linking App-to-App: Este é o método universal e confiável, funcionando de forma segura para casos de uso de identidade e pagamento em ambas as plataformas. Continua a ser o método principal para invocar uma carteira de terceiros para pagamentos no iOS.
• Padronizado Entre Dispositivos: Este fluxo baseado em FIDO CTAP é atualmente uma característica do ecossistema Google/Android e não é suportado no iOS.

(*) Nota sobre Pagamentos via API DC: Embora o uso do OpenID4VP pelo Android torne um fluxo de pagamento tecnicamente viável através da API de Credenciais Digitais, este não é o seu foco principal de design. A integração perfeita para pagamentos através desta API específica, em oposição a outros métodos nativos, ainda está por ver e exigiria suporte explícito dos fornecedores de navegadores.

Esta comparação deixa claro que, embora a verificação de identidade esteja a ser cada vez mais padronizada através da API de Credenciais Digitais, a autorização de pagamento para carteiras de terceiros como a EUDI Wallet ainda depende fortemente de padrões de integração nativa mais tradicionais, como o deep linking app-to-app, especialmente no iOS.

Independentemente do modelo de integração de pagamento usado para invocar a carteira, o núcleo da confirmação de pagamento da EUDI Wallet baseia-se num fluxo criptográfico padronizado detalhado no EWC RFC008.

Abaixo está uma visão geral de alto nível deste processo:

Este é um exemplo não normativo do objeto payment_data que é enviado para a carteira, detalhando a transação para o utilizador confirmar.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

Depois de o utilizador aprovar, a carteira cria um JWT de vinculação de chave. As suas reivindicações provam que o utilizador confirmou os dados específicos da transação.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

Enquanto os padrões técnicos evoluem, a indústria de pagamentos não está parada. Os principais intervenientes estão a explorar ativamente como fundir a segurança das credenciais digitais com a funcionalidade dos pagamentos.

Uma forma poderosa de entender o potencial das Credenciais Verificáveis (VCs) é compará-las com os bem-sucedidos sistemas de tokenização de pagamentos de rede (como o Visa Token Service ou o Mastercard MDES).

• Tokenização de Pagamentos substituiu o sensível Número de Conta Primário (PAN) por um token seguro e um criptograma de uso único. Isto protege o ativo principal — o número do cartão — durante as transações.
• Credenciais Verificáveis visam fazer pelos dados pessoais o que a tokenização fez pelos PANs. Em vez de partilhar dados brutos (nome, data de nascimento, morada), o utilizador apresenta uma credencial assinada criptograficamente de um emissor confiável.

Em essência, uma VC está para os dados pessoais como um token de pagamento e um criptograma estão para os dados do cartão: um substituto seguro e verificável que reduz o risco e aumenta a privacidade.

Com base neste paralelo, os organismos da indústria estão a trabalhar no conceito de uma "credencial de pagamento verificável". Seria uma credencial, emitida por um banco, que agrega um instrumento de pagamento (como um cartão tokenizado) e pode ser usada para autorizar transações.

• A EMVCo, o organismo de normalização para pagamentos seguros, está a integrar ativamente os padrões FIDO no protocolo EMV 3-D Secure. Isto permite que autenticações prévias com passkey sejam usadas como um sinal forte para aprovações sem atrito, ao mesmo tempo que se prepara para que a Confirmação de Pagamento Seguro (SPC) sirva como uma alternativa moderna e resistente a phishing aos desafios tradicionais de OTP. Existem também discussões em curso sobre como as credenciais verificáveis poderiam ser incorporadas nestes fluxos no futuro.
• A Visa anunciou o Visa Payment Passkey Service, que vincula de forma segura um autenticador FIDO a credenciais de pagamento. Este serviço foi projetado para confirmar a identidade e autorizar pagamentos num único passo, sem atrito e sem interromper a experiência de checkout.
• A Mastercard está a seguir uma estratégia paralela com o seu Mastercard Payment Passkey Service, que aproveita o seu Token Authentication Service (TAS) para substituir palavras-passe e OTPs por autenticação biométrica baseada em passkey, fortemente integrada com os seus serviços de tokenização (MDES).

Isto mostra uma tendência clara: a indústria está a mover-se em direção a um futuro onde uma carteira pode apresentar uma prova criptograficamente verificável tanto da identidade como da autorização de pagamento num único fluxo padronizado.

Grande parte desta inovação está a ser acelerada por fortes ventos regulatórios, particularmente da União Europeia.

O regulamento eIDAS 2.0 da UE não se trata apenas de fornecer aos cidadãos uma identidade digital; ele prevê explicitamente a EUDI Wallet como um método para realizar a SCA para pagamentos online. Isto significa que, no futuro, os bancos e provedores de pagamento na UE poderão ser obrigados a aceitar a EUDI Wallet como uma forma de os utilizadores confirmarem transações online, fornecendo uma alternativa baseada em padrões às aplicações bancárias proprietárias ou códigos SMS.

Um acordo antitrust histórico na UE já forçou a Apple a abrir a sua interface NFC anteriormente fechada nos iPhones. A partir do iOS 17.4 (lançado a 5 de março de 2024), a Apple implementou as APIs necessárias e permitiu que os utilizadores selecionassem uma aplicação de pagamento sem contacto padrão, cumprindo o prazo vinculativo da Comissão Europeia de 25 de julho de 2024. Isto já não é uma perspetiva futura; é a realidade atual no Espaço Económico Europeu (EEE).

Esta mudança significa que as aplicações de carteira de terceiros podem agora oferecer as suas próprias soluções de "tap-to-pay" no iOS, pondo fim ao monopólio de longa data do Apple Pay. As principais capacidades agora disponíveis para os programadores incluem:

• Escolha de Carteira Padrão: Os utilizadores no EEE podem definir uma aplicação de terceiros elegível como a sua aplicação de pagamento sem contacto padrão, que pode ser invocada através de um duplo clique no botão lateral.
• Integração Completa: Estas carteiras podem usar as funcionalidades de segurança nativas do iPhone, incluindo o Face ID e o Touch ID, para autorização de pagamento.
• Adoção no Mundo Real: Vários grandes players já lançaram as suas soluções, incluindo o Vipps MobilePay na Noruega e o PayPal na Alemanha.

As implicações desta abertura são significativas e já se estão a desenrolar:

• Aumento da Concorrência: Bancos e fintechs podem agora competir diretamente com o Apple Pay na sua própria plataforma, o que se espera que reduza as taxas dos emissores e estimule a inovação.
• Uso Mais Amplo de Credenciais: As mesmas APIs podem ser usadas para mais do que apenas pagamentos, incluindo crachás corporativos, passes de transporte e chaves de hotel, sem necessidade de estarem na Apple Wallet.
• Um Caminho para Credenciais Padronizadas: Isto estabelece um precedente crucial. A mesma lógica regulatória que abriu a interface NFC para aplicações de pagamento poderia eventualmente ser usada para exigir o suporte a "Credenciais de Pagamento Verificáveis" padronizadas e neutras (como as que estão a ser pilotadas para a EUDI Wallet), permitindo que funcionem ao lado de soluções proprietárias.
• Precedente Global: Embora a mudança esteja atualmente limitada ao EEE, estabelece um poderoso precedente global. Reguladores noutras regiões, incluindo os EUA, estão a observar atentamente, e isto poderá acelerar aberturas semelhantes em todo o mundo.

Para os emissores de pagamentos (bancos, esquemas, fintechs), navegar na transição para as credenciais digitais requer uma estratégia pragmática e faseada. O objetivo é construir sobre os ativos que controla hoje para se preparar para o ecossistema de amanhã. Este manual descreve essa estratégia, passando de ações imediatas e de baixo risco para avaliações mais estratégicas e de longo prazo.

A base de qualquer estratégia futura de carteira é uma aplicação nativa segura e amplamente adotada. A prioridade imediata é maximizar o alcance da sua aplicação e fortalecer a sua autenticação tanto para o login como para os pagamentos.

1. Impulsione a Adoção da Aplicação Nativa: A sua aplicação móvel é a sua futura carteira. O objetivo principal é torná-la uma ferramenta indispensável para os seus clientes. Esta distribuição e envolvimento são a base crítica para qualquer futura emissão de credenciais ou funcionalidade de carteira.

2. Use Passkeys para Pagamentos, Seguindo o Modelo do PayPal: Implemente passkeys imediatamente, não apenas para login, mas para autorização de pagamento. Procure uma experiência com paridade próxima às soluções de plataforma nativas como o Apple Pay. Para ambientes regulatórios que exigem Autenticação Forte do Cliente (SCA), adote a abordagem pragmática do PayPal:

   • Aproveite as passkeys como um fator de autenticação primário.
   • Combine-as com sinais de dispositivo confiáveis (ex: "dispositivos lembrados" geridos através da sua aplicação ou cookies seguros) para cumprir o fator de "posse" da SCA.
   • Esta combinação permite-lhe fornecer uma experiência de confirmação de pagamento sem atrito, que é altamente segura e compatível, sem esperar pelo suporte universal de VCs.

Com uma aplicação segura e protegida por passkey como base, pode começar a integrar seletivamente novas tecnologias de credenciais onde elas oferecem um valor claro.

3. Monitore a Ascensão das Credenciais de Pagamento Verificáveis: O conceito de uma VC que transporta um token de pagamento é poderoso, mas ainda não está padronizado. O seu papel aqui é ser um observador e participante ativo.

   • Ação: Acompanhe de perto o progresso dentro de organismos de normalização como a EMVCo e o W3C. Esteja preparado para alavancar Credenciais de Pagamento Verificáveis padronizadas se e quando elas fornecerem uma vantagem clara sobre os fluxos existentes baseados em passkey.

4. Integre Credenciais Digitais para Casos de Uso de Identidade: À medida que as carteiras de identidade digital (como a EUDI Wallet) ganham tração, integre a API de Credenciais Digitais para tarefas relacionadas com a identidade, não para pagamentos.

   • Ação: Use apresentações de VC para processos de alta garantia onde elas se destacam:
     • Onboarding e KYC: Simplifique a criação de novas contas.
     • Autenticação Step-Up: Verifique a identidade para ações de alto risco.
     • Recuperação de Conta: Forneça um caminho seguro para utilizadores que perderam os seus dispositivos.

A barreira final para a adoção de qualquer nova tecnologia de pagamento é o atrito para o utilizador. Antes de substituir um fluxo simples de passkey, uma alternativa baseada em VC deve provar que não é apenas mais segura, mas igualmente fluida.

5. Compare Incansavelmente com a Experiência de Um Clique: O padrão para uma experiência de pagamento moderna é definido por líderes como o Apple Pay e o seu seguidor próximo na Web, o PayPal. Qualquer novo fluxo que introduza deve competir com a sua confirmação quase instantânea de um clique. Todos os sinais atuais indicam que, para a grande maioria das transações, a resistência ao phishing das passkeys fornece um nível suficiente de proteção e uma experiência de utilizador superior. Não adicione um passo de apresentação de VC a um fluxo de pagamento se isso introduzir qualquer atrito discernível.

6. Fique Atento aos Sinais de Dispositivo In-Band no WebAuthn: A evolução das passkeys não é estática. Embora as primeiras tentativas de fornecer sinais específicos do dispositivo tenham sido descontinuadas, os organismos de normalização estão a trabalhar ativamente na integração de sinais de confiança de vinculação de dispositivo mais fortes diretamente no protocolo WebAuthn. Isto permitiria que um RP identificasse um dispositivo confiável durante uma autenticação com passkey, fortalecendo ainda mais o sinal para os motores de risco sem exigir uma apresentação de VC separada e fora de banda. Monitore este espaço de perto, pois é o caminho mais provável para uma segurança aprimorada sem sacrificar a experiência sem atrito da passkey.

Ao seguir este manual faseado, um emissor pode construir uma estratégia robusta e prática que maximiza a segurança e melhora a experiência do utilizador hoje, enquanto se prepara para adotar ponderadamente as tecnologias de pagamento verificáveis de amanhã.

Para que as credenciais digitais se tornem parte integrante dos processos de pagamento, para além de apenas apoiar o KYC ou autenticar utilizadores em contas de pagamento, vários desafios significativos devem ser superados:

1. Padronização de VCs Específicas para Pagamentos: É necessário desenvolver um formato de credencial verificável dedicado, seguro e amplamente aceite para pagamentos. Este precisaria de encapsular tokens de pagamento, dados específicos da transação e, potencialmente, elementos de segurança dinâmicos, excedendo em muito o âmbito dos atuais mdocs focados na identidade ou VCs genéricas.
2. Integração com Redes de Pagamento: Qualquer solução de pagamento baseada em VC deve integrar-se perfeitamente com as redes de pagamento globais existentes (Visa, Mastercard, etc.) ou propor novos trilhos viáveis. Isto envolve alinhamentos técnicos, de segurança e de modelo de negócio complexos.
3. Conformidade Regulatória: Os pagamentos são fortemente regulados (ex: PSD2/SCA na Europa, PCI DSS globalmente). Um sistema de pagamento baseado em VC precisaria de cumprir todas as regulamentações financeiras relevantes, incluindo as de segurança, proteção do consumidor e antifraude.
4. Adoção por Emissores e Adquirentes: Bancos, instituições financeiras (como emissores de VCs de pagamento) e adquirentes de comerciantes precisariam de investir na infraestrutura para suportar tal sistema.
5. Modelo de Segurança: Um modelo de segurança robusto especificamente para VCs de pagamento seria essencial, cobrindo a emissão, armazenamento (idealmente em elementos seguros baseados em hardware), apresentação e revogação num contexto financeiro.
6. Experiência do Utilizador: Embora as VCs possam oferecer controlo ao utilizador, a experiência de pagamento deve permanecer rápida, intuitiva e fiável para obter uma adoção generalizada.

Possibilidades Futuras:

• VCs para Comprovativos de Autorização de Pagamento: As VCs poderiam representar uma "autorização" assinada criptograficamente para pagar a partir de uma conta vinculada, apresentada via OpenID4VP, com a transferência de fundos real ainda a ocorrer através de trilhos tradicionais.
• VCs Contendo Tokens de Pagamento: Uma VC padronizada poderia ser definida para conter de forma segura um token de pagamento (semelhante a um DPAN EMV), que é então processado pelas infraestruturas de pagamento existentes.
• VCs de Pagamento de Circuito Fechado: Emissores ou comunidades específicas podem criar VCs para pagamentos dentro dos seus próprios sistemas de circuito fechado.

No entanto, estas são em grande parte conceptuais no momento. O principal impulso por trás do desenvolvimento atual de VCs e mdocs, agora solidificado pelas implementações concretas de APIs de navegador, permanece focado na verificação de identidade e atestação de atributos, não na execução de pagamentos.

A convergência da identidade digital e dos pagamentos apresenta um cenário complexo, mas navegável. Embora a promessa de uma única e universal "credencial de pagamento verificável" seja atraente, este artigo conclui que a estratégia mais eficaz e prática para os emissores de pagamentos hoje está fundamentada numa realidade diferente: a batalha pela melhor experiência do utilizador é primordial, e as passkeys são a arma mais poderosa.

O manual estratégico é claro. A jogada imediata e de baixo risco é focar-se em estabelecer uma aplicação nativa imbatível, usando-a como um veículo para implementar pagamentos baseados em passkey que possam rivalizar com o padrão de "um clique" sem atrito estabelecido pelo Apple Pay e pelo PayPal. Esta abordagem aborda as necessidades centrais de segurança (através da resistência ao phishing) e da experiência do utilizador hoje, usando tecnologia madura e amplamente adotada.

Neste modelo, as Credenciais Verificáveis encontram o seu papel crucial, mas distinto. Elas ainda não são a ferramenta para o ato de pagamento em si, mas são indispensáveis para as tarefas de identidade de alta garantia que o rodeiam: onboarding seguro, recuperação de conta robusta e KYC regulatório.

O futuro dos pagamentos não será determinado por uma única tecnologia, mas por um foco implacável no utilizador. O sucesso virá para os emissores que dominarem primeiro a experiência impulsionada por passkeys nas suas próprias aplicações, enquanto monitorizam atentamente a evolução das credenciais verificáveis e dos sinais de confiança de passkey in-band. Eles devem estar prontos para integrar estas novas tecnologias não quando estiverem meramente disponíveis, mas apenas quando puderem cumprir o formidável padrão de uma experiência de pagamento verdadeiramente fluida, segura e superior.