Importante: este guia explica o fluxo e os conceitos envolvidos. Para consultar todos os campos, tipos e respostas disponíveis, veja a referência da API de criação de onboarding.
1. Como funciona o modelo de organização
Nesse modelo, existem duas partes principais:- Organização distribuidora: organização que possui as credenciais de API e controla o fluxo dos seus clientes.
- Organização do cliente: organização criada durante o onboarding e que será utilizada para as movimentações do cliente.
Trio-Target-Org-Id.
Consulte também Acting on another organization.
2. Criando o onboarding
O onboarding é criado através do endpoint:client_id e client_secret da organização distribuidora.
Dados necessários
Para iniciar o onboarding, envie os dados da empresa, do representante e do consentimento.
Dentro de
business_infos, são informados dados como:
- faturamento anual;
- ticket médio.
- nome;
- CPF;
- telefone;
- e-mail.
- CPF do responsável pelo consentimento;
- endereço IP;
- data e hora da autorização.
3. Exemplo de criação
4. O que acontece depois da criação
A criação do onboarding é síncrona. Após o processamento da requisição, a API retorna os principais identificadores da estrutura criada, incluindo:entity_id;org_id;company_id;external_id;tax_number;status.
Boa prática: salve oorg_id,entity_ide oexternal_idno seu sistema. Oorg_idserá utilizado posteriormente para executar operações na organização do cliente.
5. Etapa de liveness
Depois da criação, o onboarding segue para o processo de validação. O representante precisa realizar o reconhecimento facial (liveness) necessário para a abertura da conta. Exemplo:6. Análise de Compliance
Depois que o liveness for concluído, as informações do cliente seguem para análise de Compliance. A organização distribuidora não precisa ficar consultando a API continuamente para saber se a análise terminou. O acompanhamento deve ser feito pelos webhooks de entidade. Os eventos da categoriaentity são enviados quando o status de Compliance de uma entidade criada pelo onboarding é alterado.
Consulte a referência de eventos de Entity.
7. Webhooks do onboarding
Os principais eventos relacionados ao onboarding são:entity.in_review
Indica que a entidade entrou em análise.
Quando aplicável, o evento também contém o liveness_link do representante.
entity.approved
Indica que a entidade foi aprovada pelo Compliance e está pronta para operar.
entity.rejected
Indica que a entidade foi rejeitada pelo Compliance.
Nesse caso, o evento contém o campo reason, que descreve o motivo da rejeição.
8. Usando a organização do cliente
Depois que o onboarding for aprovado, a organização distribuidora pode realizar chamadas em nome da organização do cliente. Para isso, utilize a mesma credencial da organização distribuidora e informe oorg_id do cliente no header:
403.
Importante: o acesso à organização é configurado no nível da organização e precisa estar habilitado para a integração.
9. Fluxo completo
O fluxo completo pode ser entendido da seguinte forma:10. Recomendações para a integração
Salve os identificadores
Após oPOST /onboarding, armazene no seu sistema pelo menos:
external_id;org_id;entity_id;company_id;tax_number;- status atual.
Use o external_id como referência do seu sistema
O external_id deve ser uma referência que permita identificar facilmente o cliente dentro da sua aplicação.
Exemplo:
Só habilite as operações após a aprovação
Mantenha o cliente em estado de onboarding enquanto o Compliance estiver analisando a entidade. Após receber:Trate a rejeição
Quando receber:reason retornado pelo webhook para permitir o tratamento adequado do cliente.
Referências
Obtendo a conta bancária após a aprovação
Após a aprovação da entidade (entity.approved), a conta bancária do cliente costuma ficar disponível em alguns minutos. Ela não é criada no mesmo instante do evento de aprovação, então não assuma que o identificador da conta já estará disponível imediatamente.
Para obtê-la, chame o endpoint de listagem de contas virtuais, informando o org_id do cliente no header:

