Repositório no GitHub
Veja o código-fonte e exemplos no GitHub
Pacote no pub.dev
didit_sdk
SDK nativo: esta é a abordagem recomendada para apps Flutter. O SDK encapsula os SDKs nativos de iOS e Android por meio de platform channels, para oferecer a melhor experiência ao usuário, gerenciamento otimizado da câmera e suporte completo a NFC.
Requisitos
Requisitos de plataforma
O consentimento biométrico requer o SDK nativo 4.10.0 ou posterior. Para pessoas abrangidas pelas leis de Illinois, Texas ou Colorado, a Didit pode solicitar consentimento biométrico explícito antes da primeira captura facial. Uma versão do SDK para Flutter que fixa os SDKs nativos de iOS e Android na versão 4.10.0 ou posterior exibe essa etapa. Versões anteriores não conseguem exibir a etapa: as sessões funcionam como antes, e a decisão informa que o consentimento não foi coletado (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize se você verifica pessoas nesses estados.Instalação
pubspec.yaml:
Variantes do SDK nativo
Odidit_sdk inclui o SDK nativo completo.
Para distribuir um binário menor, use como dependência um pacote de variante. Ele expõe exatamente a mesma API Dart e fixa o SDK nativo correspondente nas duas plataformas:
package:didit_sdk_core/sdk_flutter.dart.
Configuração no iOS
O plugin é compatível com os dois gerenciadores de dependências do Flutter para iOS: Swift Package Manager e CocoaPods.Swift Package Manager
Se a sua versão do Flutter tiver o suporte ao Swift Package Manager ativado (ative comflutter config --enable-swift-package-manager no Flutter 3.24+), o plugin é usado automaticamente como um pacote Swift.
Nenhuma configuração no Podfile é necessária: a dependência nativa DiditSDK é resolvida a partir do GitHub por conta própria.
Defina o deployment target de iOS do seu app no Xcode (target do Runner e projeto) com o 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 odidit_sdk, o plugin seleciona a variante do SDK nativo de iOS a partir de $DiditSdkIosVariant, uma variável global Ruby que você define no ios/Podfile do seu app (o pod DiditSDK não está no trunk do CocoaPods):
didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), ele fixa diretamente o seu subspec nativo e ignora $DiditSdkIosVariant. Mantenha a linha pod e o deployment target do seu Podfile de acordo com essa variante (por exemplo, pod 'DiditSDK/Core', :podspec => ... com platform :ios, '13.0').
As variantes
all e nfc exigem deployment target iOS 15.0+; core e autodetection podem usar iOS 13.0. Ao trocar de variante, limpe o CocoaPods antes (rm -rf Pods Podfile.lock) para que a variante anterior do SDK não seja reutilizada.Configuração no Android
Por padrão, o plugin depende do SDK completo para Android, incluindo NFC. Para compilar sem NFC, adicione isto aoandroid/gradle.properties:
me.didit:didit-sdk para me.didit:didit-sdk-core, removendo o módulo de leitura por NFC e as suas dependências JMRTD/SCUBA/BouncyCastle.
Quando o NFC está ativado (padrão), adicione esta regra de empacotamento ao android/app/build.gradle.kts para resolver um arquivo 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), e nenhuma configuração manual do Maven é necessária no seu app.
Permissões
iOS
Adicione as seguintes chaves aoInfo.plist do seu app:
Configuração de NFC
Para habilitar a leitura NFC de passaportes e documentos de identidade com chip:-
Adicione a capability de 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 My Number Card do Japão por meio do JPKI: sem ele, o iOS não informa o cartão ao SDK. A leitura do My Number Card ainda não está habilitada em produção, e o identificador não altera nada para outros documentos, então você já pode adicioná-lo.
- Adicione um arquivo de entitlements com a leitura de tags NFC habilitada:
com.apple.developer.nfc.readersession.formats.
Essa 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, pois nenhum deles lê chips.
Android
As seguintes permissões são declaradas noAndroidManifest.xml do SDK e mescladas automaticamente:
Os recursos de hardware de câmera e NFC são declarados como opcionais (
android:required="false"), para que o seu app possa ser instalado em dispositivos sem esses recursos. Quando diditSdkAndroidNfcEnabled=false, o SDK não adiciona a permissão nem o recurso de NFC do Android.
Permissões em tempo de execução
O SDK trata automaticamente as solicitações de permissão em tempo de execução do Android. Quando o usuário chega a uma etapa que exige acesso à câmera:- O SDK solicita a permissão de câmera, caso ela ainda não tenha sido concedida
- Se o usuário negar a permissão, uma mensagem de erro é exibida com um botão Try Again
- Se o usuário conceder a permissão, o fluxo de verificação continua
startVerification(): o SDK cuida disso internamente.
Início rápido
Métodos de integração
O SDK oferece dois métodos de integração:Método 1: token de sessão (recomendado para produção)
Crie uma sessão no seu backend usando a API Create Verification Session e, em seguida, passe o token para o SDK:- A associação das sessões aos seus usuários (
vendor_data) - A definição de metadados personalizados
- A configuração de callbacks por sessão
Método 2: ID do fluxo (integração mais simples)
Em integrações mais simples, o SDK pode criar sessões diretamente usando o ID do seu fluxo de verificação (workflow), sem necessidade de backend:Os parâmetros avançados de sessão (
contact_details, expected_details, metadata) são suportados somente pelo método de token de sessão, em que o seu backend chama a API Create Session com suporte a todos os parâmetros. Passe o session_token retornado 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âmera
As opções de câmera correspondem às opções de câmera do Web SDK. Cada lente éCameraLens.front ou CameraLens.back.
Se o dispositivo não tiver a lente solicitada, o SDK usa a primeira câmera disponível.
O alternador de câmera também fica oculto em dispositivos que têm apenas uma câmera.
Defina uma opção de alternador como false para fixar o usuário na lente padrão daquela etapa.
Temas e cores: cores, fundos e as configurações da tela de introdução são definidos nas suas configurações de White Label no Didit Console, e não na configuração do SDK. Isso garante uma identidade visual consistente em todas as plataformas.
Suporte a idiomas
O SDK oferece suporte a 54 idiomas. Se nenhum idioma for especificado, o SDK usa a configuração regional do dispositivo, com inglês como alternativa.Parâmetros avançados de sessão
Parâmetros comocontact_details, expected_details e metadata são aceitos somente pelo método de token de sessão. Seu backend chama POST /v3/session/ com suporte completo a parâmetros e, em seguida, passa o session_token retornado para o SDK.
O método Dart
startVerificationWithWorkflow aceita apenas workflowId, vendorData e config. Versões anteriores à 3.4.0 expunham os parâmetros contactDetails, expectedDetails e metadata, mas eles foram removidos porque o endpoint Unilink não os aceita.Tratamento de resultados
TantostartVerification quanto startVerificationWithWorkflow retornam um Future<VerificationResult>. O resultado é uma classe selada: use pattern matching para identificar o desfecho.
Casos de resultado
Propriedades de SessionData
Tipos de erro
O enumVerificationErrorType expõe os seguintes casos:
Perda de conexão
Se o dispositivo perder a conexão durante a verificação, o SDK exibe uma tela de “Sem conexão com a internet” em vez de deixar uma etapa carregando. Ele continua verificando em segundo plano e fecha a tela sozinho assim que a Didit volta a ficar acessível, e o usuário continua a partir da etapa em que estava. A tela oferece Tentar novamente e, a menos que o botão de fechar esteja desativado, Sair da verificação. Sair encerra a verificação com um resultadoVerificationFailed cujo tipo de erro é networkError, para que seu app saiba que o usuário saiu devido à perda de conexão.
Exemplo completo de tratamento de resultados
Exemplo de ponta a ponta (sessão no backend → Flutter SDK → webhook)
A integração pronta para produção: seu backend cria a sessão, seu app Flutter recebe osession_token e o SDK executa o fluxo. A decisão final é entregue ao seu backend via webhook. Nunca confie apenas no resultado do lado do cliente.