SDKs mobile e web

Há SDKs nativos para iOS, Android, React Native e Flutter, e SDKs web. Use um nativo para NFC ou melhor câmera; os resultados continuam chegando por webhook.

#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

iOS oferece Swift Package Manager e CocoaPods; adicione permissões de câmera e NFC ao Info.plist quando necessário. Android usa Maven. React Native suporta Expo por uma compilação de desenvolvimento com módulos nativos, não pelo Expo Go.

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 language explicitamente 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.

#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

Mude para Sandbox no seletor abaixo do nome da aplicação, crie uma chave de API de teste e use-a. As verificações são simuladas, sem cobrança, e você escolhe o resultado.

testes no sandbox