Testando uma integração de verificação de ponta a ponta em um ambiente de sandbox.

Teste deliberadamente todos os resultados tratados pelo seu código, incluindo falhas, com os IDs de teste do sandbox. No sandbox da Toden, os últimos dígitos de um ID de teste publicado escolhem o cenário: verificado, não encontrado, selfie incompatível, documento expirado, erro do fornecedor e outros. Não há chamadas externas nem cobranças, pelo que pode repetir toda a matriz.

Em seguida, teste seu receptor de webhook de forma independente, com eventos simulados e assinados, reenvios e uma resposta com falha. A maioria dos bugs de integração encontrados após o lançamento está nos caminhos de falha e no receptor, não no caminho correto que todos testaram manualmente.

Como o ambiente de teste se comporta

A caixa de areia é selecionada pelo prefixo da chave:pk_test_para os SDKs do cliente,sk_test_para o seu backend. De acordo com o guia do sandbox (abre num novo separador) , três regras se aplicam:

• Somente IDs de teste publicados são aceitos. Um número de identificação real será rejeitado no momento do envio.422 only_test_ids_allowedAssim, os números de identificação reais ficam fora dos seus dados de teste.

• Os resultados são falsos. Os dados biográficos, as fotos governamentais, a leitura de documentos e os resultados do banco de dados são padronizados. Nenhum banco de dados governamental ou outro serviço externo é consultado.

• Nada será cobrado , inclusive em caso de créditos insuficientes.

Os IDs de teste também ignoram a lista de permissões de tipo de ID da sua organização, permitindo que uma nova organização comece a testar imediatamente.

Os ambientes de sandbox e produção são separados: chaves, verificações, endpoints de webhook e configurações não são compartilhados entre eles. Tudo o que você configurar no sandbox deverá ser configurado novamente no ambiente de produção.

Como um ID de teste seleciona o resultado

Um ID de teste é preenchido com zeros à esquerda seguido do número do cenário, portanto, permanece válido para o seu tipo de ID. Para um nigeriano BVN :

00000000001  → verified
00000000002  → not_found
00000000004  → selfie_mismatch
00000000012  → provider_error

Cada tipo de ID possui seu próprio formato para a mesma ideia:A00000001para um passaporte nigeriano,GHA-000000001-0Para um Cartão de Gana,00000001Para um documento de identidade nacional queniano. Altere os dígitos finais para mudar o cenário. A tabela completa com os 24 cenários e o formato de cada tipo de documento de identidade está no guia.

Um verificado BVN Faça o teste a partir do seu backend, seguindo o exemplo documentado:

curl -X POST https://api.toden.co/api/kyc/verify \
  -H "Authorization: Bearer pk_test_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "country": "NG",
    "idType": "bvn",
    "idNumber": "00000000001",
    "userData": { "firstName": "Chidi", "lastName": "Okafor", "dateOfBirth": "1990-04-12" },
    "metadata": { "requestId": "test-001" }
  }'

Para IDs de documentos, o sandbox nunca lê a imagem. Deixe o SDK O fluxo de documentos usa por padrão o cenário verificado ou você pode escolher um cenário passando o ID de teste do documento.idNumber, por exemploA00000007para um passaporte vencido.

Os resultados que valem a pena testar, agrupados pela função do seu código.

Vinte e quatro cenários são mais do que a maioria das integrações precisa para serem testadas individualmente. Agrupe-os pela ramificação do seu código que cada um alcança:

Alguns cenários seguem as configurações do seu fluxo de trabalho, o que é útil porque testa sua configuração em vez de uma resposta fixa. Os cenários 5 e 6 falham por padrão, mas verifique comdataMatch: falsequando seu fluxo de trabalho registra esses dados de identidade em vez de falhar neles. Os cenários 22 e 23 seguem sua restrição de idade: o cenário 22 retorna uma data de nascimento ligeiramente fora dos seus limites, o cenário 23 não retorna nenhuma data e ambos são verificados em um fluxo de trabalho sem restrição de idade. O cenário 24 segue suas configurações para comparar a selfie com a foto impressa em um documento e é verificado quando seu fluxo de trabalho não usa essa foto para o documento de identidade.

Forçar resultados e prazos

Duas sobreposições entrammetadatae são ignorados na produção:

• sandboxOutcomeforça qualquer cenário, independentemente do ID do teste, por exemplo."sandboxOutcome": "selfie_mismatch"Útil quando o SDK O fluxo de documentos não coleta um número de identificação.

• sandboxDelayMsControla a duração da verificação, de 0 a 60.000 milissegundos, com um valor padrão de aproximadamente 1.200.

Use o atraso de forma deliberada. Defina-o como 0 para testes automatizados rápidos. Defina-o para dezenas de segundos para testar a parte que as pessoas esquecem: o que seu aplicativo exibe enquanto espera, se o usuário pode sair da tela e voltar, e se um webhook lento trava a tela.

"metadata": {
  "requestId": "test-slow-002",
  "sandboxOutcome": "document_expired",
  "sandboxDelayMs": 30000
}

Já que você está lá, envie o mesmo.requestIdduas vezes. Você deve receber a verificação existente de volta, não uma segunda, que é o comportamento do qual sua lógica de repetição depende.

Teste a decisão, não apenas as verificações.

Se o seu fluxo de trabalho tiver regras de decisão, as verificações representam apenas metade da solução. Execute cada cenário no fluxo de trabalho de teste publicado e confirme o resultado esperado pela sua política: aselfie_mismatchque deveria ir para revisão chega comoin_review, nãodeclinedLembre-se disso.verification.completedreflete apenas as verificações; o veredicto do fluxo de trabalho segue comoverification.status_updatedE seu backend deve agir de acordo com isso.

A verificação de empresas possui seus próprios ambientes de teste. Qualquer número de registro é aceito e corresponde a um ambiente de verificação.RC0000001é verificado eRC0000002não foi encontrado, e a empresa de testes (sandbox) conta com uma equipe de pessoas-chave para realizar a devida diligência.

Teste o receptor de webhook separadamente.

Crie um endpoint webhook de teste e use o simulador na página correspondente, que envia uma amostra realista e devidamente assinada de qualquer evento pelo caminho de entrega real, sem executar uma verificação. O guia de testes de webhook (abre num novo separador) recomenda uma sequência; as etapas que detectam a maioria dos bugs são:

1. Confirme se o receptor verifica a assinatura V2 sobre o corpo bruto e retorna.2xxrapidamente.

2. Reenvie uma entrega a partir do painel de controle e confirme se o efeito colateral ocorre apenas uma vez, pois a desduplicação é baseada no ID do evento.

3. Retornar um não-2xxresponder temporariamente e confirmar que uma nova tentativa está agendada.

4. Gire o segredo e confirme se ambas as assinaturas foram aceitas durante o período de tolerância.

5. Entregue dois eventos fora de ordem e confirme se o seu manipulador ainda termina no estado correto.

Antes de mudar para teclas ativas

Os arquivos de mídia carregados com um ID de teste são mantidos por três dias e, em seguida, substituídos por um arquivo de espaço reservado. Portanto, não crie testes que dependam das imagens originais posteriormente. Quando a matriz for aprovada, o guia de ambientes (abre num novo separador) listará os requisitos de produção:

1. Seu perfil comercial foi aprovado para produção. Até lá, as solicitações de verificação e upload para produção serão rejeitadas.business_not_approved.

2. Você criou chaves ativas: uma publicável para o cliente e outra secreta para os resultados no backend.

3. Você registrou os endpoints de webhook de produção e verificou suas assinaturas.

4. Seu saldo de crédito foi financiado e um limite mínimo de saldo foi definido.

5. Você trocou as chaves de teste pelas chaves de produção.

Adicione um item de sua escolha: aponte para SDK no seu ID de fluxo de trabalho de produção, já que os fluxos de trabalho são definidos para um único ambiente.

Execute uma verificação real em produção antes de liberar o fluxo para os clientes. O ambiente de teste (sandbox) comprova que seu código lida com todas as situações possíveis; a primeira execução em produção comprova que a configuração copiada é a desejada.