SDKs mobile e web
SDKs nativos para iOS, Android, React Native e Flutter colocam o fluxo dentro do seu app e são o único caminho que suporta NFC. SDKs web incorporam o fluxo no seu frontend.
Existem SDKs nativos para iOS, Android, React Native e Flutter; os SDKs web incorporam o fluxo no seu frontend. Use um SDK nativo quando precisar de NFC ou do melhor comportamento de câmera - uma WebView não oferece nenhum dos dois. Os resultados continuam chegando por webhook, não pelo SDK.
#Por que um SDK em vez de um redirecionamento
Um redirecionamento hospedado é o caminho com menos trabalho e funciona bem para a maioria dos fluxos. Um SDK vale a pena quando:
- Você precisa de NFC. O chip de um passaporte ou documento de identidade não pode ser lido a partir de uma página de navegador. Um SDK nativo é o único caminho. Veja verificação de chip NFC.
- Você não quer que o usuário saia do seu app. Um redirecionamento para fora e de volta é um ponto real de abandono no mobile.
- Você quer o melhor comportamento de câmera. O acesso nativo à câmera é mais confiável do que o de um navegador, principalmente em dispositivos mais antigos.
#O que está disponível
| Plataforma | Observações |
|---|---|
| iOS | Distribuído como um XCFramework |
| Android | Distribuído via Maven |
| React Native | Encapsula os módulos nativos; suporta a New Architecture |
| Flutter | Encapsula os módulos nativos |
| JavaScript / web | Incorpora o fluxo hospedado no seu frontend web |
| Iframe in-context | Renderiza o fluxo dentro da sua página em vez de redirecionar |
- Escolha sua plataforma e a página fornece o trecho de código dessa stack.
- Os SDKs nativos e web, cada um com seu próprio guia rápido, estão vinculados aqui.
Os requisitos de versão e os mínimos de plataforma mudam a cada lançamento, então verifique a documentação atual do SDK em vez de confiar em um retrato desta página - e se você está usando uma versão específica de framework (uma versão particular do Expo SDK, por exemplo), confirme a compatibilidade com o seu contato na Didit antes de se comprometer com isso em uma sprint.
#Uma WebView não é um SDK nativo
Envolver o fluxo web hospedado em uma WebView parece dar a você uma experiência dentro do app. Na verdade, dá apenas a aparência de uma:
- Sem NFC. O chip continua não podendo ser lido.
- Permissões de câmera são mais difíceis. O acesso à câmera de uma WebView depende da configuração do app hospedeiro, e errar nisso produz exatamente os relatos de "a câmera nunca abriu" cobertos em corrigindo problemas de liveness e reconhecimento facial.
- O idioma é o do app, não o do usuário. Uma WebView informa o idioma do app hospedeiro, então passe
languageexplicitamente ao criar a sessão. Veja definindo o idioma da verificação.
Se você vai ter o trabalho de fazer um fluxo dentro do app, use o SDK nativo.
#Os resultados ainda vêm de webhooks
Isso costuma pegar as pessoas de surpresa: o SDK informa ao seu app que o usuário concluiu o fluxo. Ele não é a fonte definitiva da decisão de verificação.
A decisão é produzida no lado do servidor depois que as verificações são executadas, e chega até você por webhook. Nunca conceda acesso com base apenas no callback de conclusão do SDK - um sinal do lado do cliente é trivialmente falsificável, e as verificações podem nem ter terminado quando ele dispara.
Tratar "o SDK disse que terminou" como "o usuário está verificado" é o erro mais grave possível em uma integração mobile. Confirme no seu servidor, a partir do webhook ou do endpoint de decisão, antes de liberar qualquer coisa.
#Um app do consumidor, ou o seu próprio?
Não existe um app separado da Didit para o consumidor final para o qual uma sessão hospedada transfira os usuários em uma etapa como o NFC. Se você quer tudo - NFC e não NFC - dentro de uma única experiência de app, esse app é o seu, com o SDK incorporado nele.
#Distribuição e conflitos de dependência
A integração do SDK nativo ocasionalmente entra em conflito com outras dependências em um app hospedeiro - uma biblioteca transitiva compartilhada, ou um subspec que fixa uma versão que outra coisa também fixa. Se isso acontecer, é um problema concreto e reproduzível que vale a pena reportar junto com o seu manifesto de dependências, em vez de contornar fixando algo antigo: a correção geralmente pertence ao SDK.
#Testando em um dispositivo
O sandbox funciona da mesma forma por meio de um SDK que em qualquer outro lugar - aponte o app para a chave de uma aplicação sandbox e toda verificação é simulada e não cobrada. Essa é a forma certa de ensaiar um fluxo mobile, porque os comportamentos do SDK que você mais precisa testar (solicitações de permissão, ciclo de vida da câmera, envio para segundo plano no meio da captura) são comportamentos do dispositivo que não custam nada para exercitar repetidamente. Veja testes no sandbox.