Saltar para o conteúdo principal
Um plugin Flutter multiplataforma que encapsula os SDK nativos de iOS e Android, oferecendo uma API Dart unificada para verificação de identidade.

Repositório no GitHub

Consulte o código-fonte e os exemplos no GitHub

Pacote no pub.dev

didit_sdk

SDK nativo: Esta é a abordagem recomendada para aplicações Flutter. O SDK encapsula os SDK nativos de iOS e Android através de canais de plataforma, para oferecer a melhor experiência ao utilizador, com gestão otimizada da câmara e suporte total a NFC.


Requisitos

Requisitos da plataforma

O consentimento biométrico requer o SDK nativo 4.10.0 ou posterior. Para pessoas abrangidas pela legislação do Illinois, do Texas ou do Colorado, a Didit pode pedir um consentimento biométrico explícito antes da primeira captura facial. Uma versão do Flutter SDK que fixe o SDK nativo de iOS e Android na versão 4.10.0 ou posterior apresenta essa etapa. As versões anteriores não conseguem apresentá-la: as respetivas sessões decorrem como antes, e a decisão indica que o consentimento não foi recolhido (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize se verificar pessoas nesses estados.

Instalação

Ou adicione-o manualmente ao seu pubspec.yaml:
Depois execute:

Variantes do SDK nativo

didit_sdk inclui o SDK nativo completo. Para obter um binário mais pequeno, declare como dependência um pacote de variante: expõe exatamente a mesma API Dart e fixa o SDK nativo correspondente em ambas as plataformas.
Declare apenas um destes pacotes como dependência e importe a partir do que escolheu, por exemplo package:didit_sdk_core/sdk_flutter.dart.

Configuração do iOS

O plugin suporta os dois gestores de dependências do iOS do Flutter: Swift Package Manager e CocoaPods.

Swift Package Manager

Se a sua versão do Flutter tiver o suporte ao Swift Package Manager ativado (ative-o com flutter config --enable-swift-package-manager no Flutter 3.24+), o plugin é consumido automaticamente como pacote Swift. Não é necessária nenhuma configuração do Podfile: a dependência nativa DiditSDK é resolvida automaticamente a partir do GitHub. Defina o destino de implementação do iOS da sua aplicação no Xcode (o destino Runner e o projeto) com o valor mínimo exigido pelo pacote escolhido: 15.0 para didit_sdk e didit_sdk_nfc, 13.0 para didit_sdk_core e didit_sdk_autodetection.

CocoaPods

Com didit_sdk, o plugin seleciona a variante do SDK nativo para iOS a partir de $DiditSdkIosVariant, uma variável global Ruby que define no ios/Podfile da sua aplicação (o pod DiditSDK não está no CocoaPods trunk):
Se usar um pacote de variante (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), este fixa diretamente o respetivo subspec nativo e ignora $DiditSdkIosVariant. Mantenha a linha pod do Podfile e o destino de implementação alinhados com essa variante (por exemplo pod 'DiditSDK/Core', :podspec => ... com platform :ios, '13.0').
As variantes all e nfc exigem um destino de implementação iOS 15.0+; core e autodetection podem ter como alvo o iOS 13.0. Ao mudar de variante, limpe primeiro o CocoaPods (rm -rf Pods Podfile.lock) para que a variante anterior do SDK não seja reutilizada.
A tag no URL do podspec tem de corresponder à versão do SDK nativo para iOS que a sua versão de didit_sdk fixa (4.13.2 fixa o SDK nativo na versão 4.13.2). Se o URL apontar para uma tag mais antiga, o pod install falha ao resolver: o CocoaPods encontra um podspec que declara essa versão mais antiga, enquanto o plugin exige uma correspondência exata. Ao atualizar o didit_sdk, atualize a tag deste URL para a mesma versão.

Configuração do Android

Por predefinição, o plugin depende do SDK completo para Android, incluindo NFC. Para compilar sem NFC, adicione o seguinte a android/gradle.properties:
Isto altera a dependência de me.didit:didit-sdk para me.didit:didit-sdk-core, removendo o módulo de leitura NFC e as respetivas dependências JMRTD/SCUBA/BouncyCastle. Quando o NFC está ativado (predefinição), adicione esta regra de empacotamento a android/app/build.gradle.kts para resolver um ficheiro de metadados duplicado do BouncyCastle:
Sem esta regra, a compilação falha com um erro mergeDebugJavaResource. A regra não é necessária quando diditSdkAndroidNfcEnabled=false.
O SDK nativo para Android é resolvido a partir de um repositório Maven remoto no GitHub (desde o plugin 3.4.0): não é necessária nenhuma configuração manual do Maven na sua aplicação.

Permissões

iOS

Adicione as seguintes chaves ao ficheiro Info.plist da sua aplicação:
Se alguma chave de privacidade obrigatória do iOS estiver em falta, o iOS termina a aplicação assim que o SDK tentar aceder a esse recurso protegido. Por exemplo, a falta de NSCameraUsageDescription provoca uma falha quando o utilizador toca no botão de tirar foto da câmara de documentos.

Configuração de NFC

Para ativar a leitura de NFC em passaportes e cartões de identidade com chip:
  1. Adicione a capacidade NFC no Xcode:
    • Selecione o seu target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Adicione os identificadores ISO7816 ao Info.plist:
D392F000260100000001 permite que o SDK leia o Cartão Individual de Número (My Number Card) do Japão através da JPKI: sem ele, o iOS não comunica o cartão ao SDK. A leitura do My Number Card ainda não está ativa em produção, e o identificador não altera nada nos outros documentos, por isso pode adicioná-lo desde já.
  1. Adicione um ficheiro de direitos (entitlements) com a leitura de tags NFC ativada:
Certifique-se de que o perfil de aprovisionamento da aplicação inclui a capacidade NFC Tag Reading. Se o Bundle ID não estiver configurado para NFC na sua conta do Apple Developer, o Xcode falha ao assinar devido à ausência do direito com.apple.developer.nfc.readersession.formats. Esta configuração de NFC não é necessária para as variantes core ou autodetection ($DiditSdkIosVariant), nem para os pacotes didit_sdk_core / didit_sdk_autodetection, uma vez que nenhum deles lê chips.

Android

As seguintes permissões estão declaradas no AndroidManifest.xml do SDK e são integradas automaticamente: As funcionalidades de hardware de câmara e NFC estão declaradas como opcionais (android:required="false"), pelo que a sua aplicação pode ser instalada em dispositivos sem essas funcionalidades. Quando diditSdkAndroidNfcEnabled=false, o SDK não adiciona a permissão nem a funcionalidade NFC do Android.

Permissões em tempo de execução

O SDK trata dos pedidos de permissões em tempo de execução do Android automaticamente. Quando o utilizador chega a um passo que requer acesso à câmara:
  1. O SDK pede a permissão da câmara, caso ainda não tenha sido concedida
  2. Se o utilizador recusar a permissão, é apresentada uma mensagem de erro com o botão Tentar novamente
  3. Se o utilizador conceder a permissão, o fluxo de verificação continua
Não é necessário pedir a permissão da câmara no código da sua aplicação antes de chamar startVerification(), uma vez que o SDK gere isto internamente.

Início rápido


Métodos de integração

O SDK suporta dois métodos de integração:

Método 1: Token de sessão (recomendado para produção)

Crie uma sessão no seu backend com a API de criação de sessão de verificação e, em seguida, passe o token para o SDK:
Esta abordagem dá-lhe controlo total sobre:
  • A associação das sessões aos seus utilizadores (vendor_data)
  • A definição de metadados personalizados
  • A configuração de chamadas de retorno por sessão

Método 2: ID do fluxo (integração mais simples)

Para integrações mais simples, o SDK pode criar sessões diretamente com o seu ID de fluxo, sem necessidade de backend:
Os parâmetros avançados de sessão (contact_details, expected_details, metadata) são suportados apenas através do método de token de sessão, em que o seu backend chama a API de criação de sessão com suporte total a parâmetros. Passe o session_token devolvido para DiditSdk.startVerification().

Configuração

Personalize o comportamento do SDK passando um objeto DiditConfig:
Para startVerificationWithWorkflow, passe config como parâmetro nomeado:

Opções de configuração

Opções de câmara

As opções de câmara correspondem às opções de câmara do SDK Web. Cada objetiva é CameraLens.front ou CameraLens.back. Se o dispositivo não tiver a objetiva pedida, o SDK usa a primeira câmara de que dispõe. O seletor de câmara também fica oculto em dispositivos que têm apenas uma câmara. Defina uma opção de seletor como false para fixar o utilizador na objetiva predefinida desse passo.
Temas e cores: As cores, os fundos e as definições do ecrã de introdução são configurados através das suas definições de marca branca na Didit Console, e não na configuração do SDK. Assim, a identidade visual é consistente em todas as plataformas.

Suporte de idiomas

O SDK suporta 54 idiomas. Se não for indicado nenhum idioma, o SDK usa o idioma do dispositivo, com o inglês como alternativa.
Ver todos os idiomas suportados →

Parâmetros avançados da sessão

Parâmetros como contact_details, expected_details e metadata são suportados apenas através do método de token de sessão. O seu backend chama POST /v3/session/ com suporte total dos parâmetros e, depois, transmite o session_token devolvido ao SDK.
O método Dart startVerificationWithWorkflow aceita apenas workflowId, vendorData e config. As versões anteriores à 3.4.0 expunham os parâmetros contactDetails, expectedDetails e metadata, mas estes foram removidos porque o endpoint Unilink não os respeita.

Tratamento dos resultados

Tanto startVerification como startVerificationWithWorkflow devolvem um Future<VerificationResult>. O resultado é uma classe selada, por isso use a correspondência de padrões para determinar o resultado.

Casos de resultado

Propriedades de SessionData

Tipos de erro

A enumeração VerificationErrorType expõe os seguintes casos:

Ligação perdida

Se o dispositivo perder a ligação durante a verificação, o SDK cobre o fluxo com um ecrã «Sem ligação à Internet», em vez de deixar um passo a carregar. Continua a verificar em segundo plano e fecha o ecrã automaticamente assim que a Didit voltar a estar acessível, e o utilizador prossegue a partir do passo em que estava. O ecrã oferece Tentar novamente e, a menos que o botão de fecho esteja desativado, Sair da verificação. Ao sair, a verificação termina com um resultado VerificationFailed cujo tipo de erro é networkError, para que a sua aplicação saiba que o utilizador saiu por causa da ligação.

Exemplo completo de tratamento de resultados


Exemplo de ponta a ponta (sessão no backend → SDK Flutter → webhook)

A integração pronta para produção: o seu backend cria a sessão, a sua aplicação Flutter recebe o session_token e o SDK executa o fluxo. A decisão final é enviada ao seu backend por webhook. Nunca confie apenas no resultado do lado do cliente.

1. Backend: criar a sessão

2. Flutter: trocar o token e iniciar o SDK

3. Backend: receber a decisão final por webhook

Consulte o guia de Webhooks para os detalhes da verificação da assinatura HMAC.

Exemplo completo


Última modificação em 7 de novembro de 2026