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
pubspec.yaml:
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.
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 comflutter 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
Comdidit_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):
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.Configuração do Android
Por predefinição, o plugin depende do SDK completo para Android, incluindo NFC. Para compilar sem NFC, adicione o seguinte aandroid/gradle.properties:
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:
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 ficheiroInfo.plist da sua aplicação:
Configuração de NFC
Para ativar a leitura de NFC em passaportes e cartões de identidade com chip:-
Adicione a capacidade NFC no Xcode:
- Selecione o seu target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
-
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á.
- Adicione um ficheiro de direitos (entitlements) com a leitura de tags NFC ativada:
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 noAndroidManifest.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:- O SDK pede a permissão da câmara, caso ainda não tenha sido concedida
- Se o utilizador recusar a permissão, é apresentada uma mensagem de erro com o botão Tentar novamente
- Se o utilizador conceder a permissão, o fluxo de verificação continua
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:- 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 objetoDiditConfig:
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.Parâmetros avançados da sessão
Parâmetros comocontact_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
TantostartVerification 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çãoVerificationErrorType 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 resultadoVerificationFailed 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 osession_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.