Alterar o fluxo de verificação sem lançar uma nova versão do aplicativo.

Monte a verificação SDK Com um ID de fluxo de trabalho em vez de especificar o fluxo em código, a configuração do fluxo é obtida do servidor sempre que uma verificação é iniciada. Ao republicar o fluxo de trabalho no painel, a próxima verificação em todas as cópias instaladas do seu aplicativo executará a nova versão. Sem compilação, sem revisão na loja, sem atualização forçada.

É isso que torna viável ajustar o limite de correspondência facial em uma tarde de terça-feira ou adicionar uma etapa de comprovação de endereço para um mercado, sem um ciclo de lançamento para dispositivos móveis. Isso não elimina os lançamentos por completo, e conhecer o limite é o que mantém a abordagem segura.

Como o SDK obtém sua configuração

Uma configuração de montagem baseada em propriedades (prop-configure) carrega o fluxo no seu código: país, tipos de ID, quais etapas são executadas, marca, texto. Alterar qualquer um desses elementos significa alterar o código e, em dispositivos móveis, isso significa uma nova publicação na loja de aplicativos, seguida de semanas com usuários utilizando versões antigas.

Um ponto de montagem de fluxo de trabalho carrega um identificador. O SDK envia para o servidor quando ele é montado:

GET /api/kyc/workflows/:workflowId
Authorization: Bearer pk_…

A resposta contém a configuração publicada, os tipos de ID habilitados para sua organização e a identidade visual, além do SDK constrói o fluxo a partir disso. De acordo com a documentação de fluxos de trabalho (abre num novo separador) , o fluxo de trabalho deve pertencer ao API A organização e o ambiente da chave devem ser publicados; qualquer outra coisa retorna um resultado indistinguível.404 workflow_not_founde o SDK relata isso através deonErrorem vez de executar silenciosamente um fluxo diferente.

Em um aplicativo React Native, toda a integração consiste em:

import { MyazaKYC } from "@myazahq/kyc-sdk-react-native";

<MyazaKYC
  apiKey="pk_live_…"
  workflowId="wf_AbC123dEf456"
  userId="user_42"
  userData={{ firstName: "Jane", lastName: "Doe" }}
  metadata={{ requestId: "order_1001" }}
  onSubmit={(submission) => console.log(submission.verificationId)}
  onError={(err) => console.error(err.code, err.message)}
>
  Verify Identity
</MyazaKYC>

As configurações do fluxo de trabalho prevalecem sobre quaisquer propriedades sobrepostas. Se você passar umcountrye se o fluxo de trabalho definir um valor, esse valor será utilizado.

O que você pode alterar ao republicar

Tudo aquilo que descreve o fluxo em vez da pessoa:

• Países, tipos de identificação e regras de validação para cada identificação.

• Etapas de captura e complementos: códigos de contato, comprovante de endereço, o NFC Etapa de chip, questionários, captura de endereço, múltiplos IDs em uma única execução.

• O método de interação ao vivo (gestos, sequência de flashes na tela ou ambos).

• Identidade visual, texto de consentimento e texto de sucesso.

• Políticas como limites de idade e como os dados de identidade que não correspondem são tratados.

• O gráfico de decisão (abre num novo separador) : quais resultados são aprovados, quais são encaminhados para revisão e quais são rejeitados.

Um exemplo hipotético do tipo de mudança que isso torna rotineira: um credor vê uma série de selfies com inconsistências causadas por iluminação inadequada e quer que elas sejam analisadas em vez de rejeitadas. Ele adiciona uma regra no construtor, verifica-a no ambiente de teste e republica. Todas as versões do aplicativo em produção aplicam a nova regra a partir da próxima verificação.

O que ainda precisa ser lançado?

Cinco coisas residem no seu código ou no seu binário, e nenhuma quantidade de republicações as move.

Dados por usuário. userId,userDataemetadatasão valores de tempo de execução. Um fluxo de trabalho é um modelo compartilhado por todos que o executam, portanto, não pode contê-los.

Callbacks e o que seu aplicativo faz com os resultados. Como você lida com eles.onSubmit,onErrorE o webhook no seu backend é o seu código.

SDK versões. Um fluxo de trabalho só pode usar os recursos instalados. SDK Entende. Os mínimos documentados paraworkflowIdsão 2.2.0 para a web SDK A versão 2.1.0 é para React Native e a 2.2.0 para Flutter. Versões anteriores para web e React Native ignoram o ID e funcionam apenas com as props, que é a primeira coisa a verificar se um fluxo de trabalho incorporado parece não fazer nada.

Funcionalidades e permissões nativas. A leitura de um chip de passaporte requer React Native ou Flutter. SDK Um navegador não consegue fazer isso. A captura de endereços no iOS exige que as strings de uso de localização estejam presentes no seu aplicativo, caso contrário, a solicitação de permissão falhará. Se você planeja ativar uma etapa que requer uma permissão nativa, implemente a permissão primeiro.

O próprio ID do fluxo de trabalho. Os fluxos de trabalho são definidos para um ambiente específico, portanto, seus fluxos de trabalho de teste e de produção são diferentes. Mantenha o ID na configuração em vez de codificá-lo diretamente no código, para que a migração para um novo fluxo de trabalho seja apenas uma alteração de configuração, e não de código.

Por que alterar fluxos ao vivo permanece seguro

Alterar o que cada usuário vê em um painel parece arriscado. Quatro propriedades de como os fluxos de trabalho são versionados tornam isso gerenciável.

Os rascunhos são independentes do que está em produção. Editar um fluxo de trabalho publicado altera apenas o rascunho. As integrações continuam lendo o último snapshot publicado até que você publique novamente.

Cada publicação é versionada. Cada publicação incrementa a versão e adiciona uma entrada de histórico imutável que você pode inspecionar ou restaurar. Se uma alteração der errado, você estará restaurando uma versão conhecida, não reconstruindo uma.

O trabalho em andamento não é movido. Um link de sessão por solicitante carrega a configuração publicada, congelada no momento em que foi criada, de modo que uma republicação nunca altera um link já presente na caixa de entrada de alguém. Uma execução de decisão é fixada na versão com a qual foi iniciada, portanto, um grafo mais rigoroso não redefine uma solicitação que já esteja em andamento.

Cada resultado é atribuível. Cada verificação registra o ID do fluxo de trabalho e a versão executada, e ambos aparecem nos webhooks de verificação comoworkflowIdeworkflowVersionGuarde os dois. Daqui a seis meses, quando alguém perguntar por que um candidato foi aprovado sob regras mais flexíveis, a versão informará exatamente quais regras se aplicaram.

Uma limitação intencional: o escopo de um fluxo de trabalho, ou seja, o que ele verifica (por exemplo, um fluxo de autenticação apenas por endereço ou por reconhecimento facial), é editável até a primeira publicação e, em seguida, bloqueado, pois as verificações e os links já dependem do significado desse ID. Para alterar o escopo, crie uma cópia com escopo definido, que começará como um novo rascunho com um novo ID de fluxo de trabalho.

Implementando uma mudança

Uma alteração no fluxo de trabalho chega a todos os usuários na próxima verificação, o que é poderoso e também significa que não há implementação gradual por versão do aplicativo. Trate uma publicação como uma implantação:

1. Faça a alteração no fluxo de trabalho do ambiente de teste e exercite cada caminho afetado com os IDs de teste publicados.

2. Verifique se cada ramo do grafo de decisão termina em um status e se as permissões nativas de qualquer nova etapa já estão presentes no seu aplicativo.

3. Aplique a mesma alteração ao fluxo de trabalho de produção e publique.

4. Confira os primeiros resultados emworkflowVersion: taxas de aprovação, revisão e rejeição, e volume da fila de revisão.

5. Se algo estiver errado, restaure a versão anterior do histórico e publique-a.

6. Informe sua equipe de suporte sobre as mudanças; os usuários notarão a nova etapa antes mesmo de seus painéis de controle.

A regra prática

Se descrever o fluxo, inclua-o no fluxo de trabalho e altere-o publicando. Se descrever a pessoa, o dispositivo ou o que seu aplicativo faz com um resultado, ele pertence ao código e é alterado a cada versão. Crie a integração uma única vez em torno de umworkflowId, mantenha seu SDK razoavelmente atual, e a maior parte do que antes era um lançamento agora é uma publicação.