Seu provedor de KYC está fora do ar. Mantenha o processo de cadastro e verificação de clientes em andamento sem aprovar clientes às cegas.

Um cliente inseriu seus dados, fotografou seu documento de identidade e completou a selfie. A última verificação expirou. Ele tentou novamente. Seu aplicativo enviou outra solicitação. O suporte recebeu uma captura de tela informando que a verificação falhou.

Seu cliente não fez nada de errado, e seu sistema disse a ele que fez.

Planeje isso antes de uma interrupção. O objetivo é preservar a experiência do cliente, mantendo as evidências necessárias para a aprovação. Você não deve ter que escolher entre perder todos os candidatos e aprovar sem a documentação comprobatória exigida.

Diferencie uma falha do cliente de uma falha do serviço.

Um documento ilegível, uma incompatibilidade de identidade e um provedor indisponível exigem respostas diferentes. Um tempo limite excedido significa que você ainda não tem uma resposta confiável. Isso não significa que o ID seja inválido e não deve ser interpretado como um erro.

Atribua ao seu produto um estado pendente ou temporariamente indisponível. Registre o motivo técnico subjacente para seus operadores, ao mesmo tempo que fornece ao cliente uma explicação clara e o próximo passo.

Por exemplo: “Não foi possível concluir a verificação agora. Seu progresso foi salvo. Avisaremos quando terminar.” Só prometa salvar o progresso ou enviar uma notificação se a sua integração realmente oferecer essa funcionalidade.

Preserve o trabalho já concluído.

Mantenha o cliente envolvido na mesma jornada, com um registro confiável das etapas concluídas e das que ainda precisam ser resolvidas. Não peça uma nova selfie simplesmente porque um serviço de registro governamental não está disponível.

Ofereça aos clientes uma maneira segura de sair e retornar. Informe-os se precisam tomar alguma providência, se o acesso está restrito e onde receberão atualizações. Evite exibir um botão "Tentar novamente" que reinicie todo o processo.

Os padrões de engenharia são abordados em nossos guias sobre verificação assíncrona e solicitações idempotentes . Seu plano de continuidade deve definir quando esses mecanismos serão executados e quem monitorará o backlog.

Escolha uma alternativa que responda à mesma pergunta.

Um segundo provedor não é automaticamente um backup independente. Ambos os serviços podem depender da mesma fonte ou rede governamental. Pergunte o que permaneceria disponível durante a falha para a qual você está se preparando.

As evidências também podem mudar quando você altera as informações. Uma fotografia de um documento de identidade e uma correspondência com um registro governamental em tempo real estabelecem coisas diferentes. Documente a diferença e obtenha a aprovação do titular da apólice quando uma alternativa for aceitável.

As opções disponíveis podem ser aguardar, utilizar um canal equivalente aprovado, solicitar evidências alternativas apropriadas ou encaminhar o caso para um revisor. A revisão manual só é útil quando o revisor possui evidências e autoridade suficientes. Ela não pode transformar uma verificação obrigatória ausente em uma verificação concluída.

Não flexibilize os requisitos de triagem ou identificação porque um acúmulo de tarefas causa desconforto.

Controle as tentativas antes que elas criem outro incidente.

Defina uma política de repetição com um número limitado de tentativas, atrasos crescentes e um ponto em que o trabalho é pausado para revisão do operador. Respeite as diretrizes de repetição documentadas do serviço. Mantenha a solicitação associada à operação original do cliente. API apoia isso.

Observe as solicitações que expiraram após o provedor já ter concluído a verificação. Um sucesso tardio e uma nova tentativa podem gerar registros conflitantes, custos extras ou duas mensagens para o cliente.

Um teste de continuidade deve incluir resultados atrasados ​​e fora de ordem, e não apenas uma resposta simples de "serviço indisponível".

Defina o que você está medindo.

Pergunte aos fornecedores o que os seus números de disponibilidade abrangem. API Uma sonda de integridade, uma página de captura hospedada e um processo de verificação concluído são métricas diferentes. Uma solicitação bem-sucedida a um endpoint de integridade não comprova que todas as fontes de dados externas estejam disponíveis.

a página de fiabilidade da Toden explica o escopo do monitoramento, o período observado e o método de cálculo. Leia esses detalhes juntamente com seus próprios tempos de sucesso e conclusão de ponta a ponta.

Durante um incidente, monitore o cheque e os países afetados, as viagens pendentes, o caso mais antigo em espera, o volume de novas tentativas e os contatos do cliente. Defina um responsável pela escalação e um substituto que possa tomar as mesmas decisões.

Recupere a fila deliberadamente

Quando o serviço retornar, não libere todas as solicitações em fila de uma só vez. Retome o serviço em um ritmo controlado, reconcilie as respostas atrasadas e verifique se cada cliente recebeu o resultado final correto.

Analise uma amostra de clientes que tentaram novamente, desistiram ou receberam mensagens contraditórias. Avalie o impacto para o cliente, não apenas os minutos em que a página de status ficou vermelha.

Toden Os fluxos de trabalho fornecem verificações e regras de decisão configuráveis. Seu aplicativo ainda precisa do gerenciamento de filas, mensagens para o cliente e uma política de fallback aprovada para esses resultados. Não assuma um recurso de failover automático entre provedores sem confirmá-lo.

Antes do lançamento, realize um exercício de interrupção com a equipe de engenharia, suporte e o responsável pela gestão de riscos. Se você estiver avaliando Toden Fale conosco sobre a dependência específica e a jornada do cliente que você precisa proteger.