Skip to main content
Este guia explica o fluxo de onboarding para uma integração em que uma organização atua como distribuidora das organizações dos seus clientes. O processo permite que a organização distribuidora envie os dados necessários para abertura da conta do cliente, acompanhe a análise de Compliance por meio de webhooks e, após a aprovação, realize operações em nome da organização do cliente.
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.
O fluxo pode ser resumido assim:
A organização distribuidora continua utilizando suas próprias credenciais. Para executar uma operação na organização de um cliente, basta informar o identificador da organização de destino no header Trio-Target-Org-Id. Consulte também Acting on another organization.

2. Criando o onboarding

O onboarding é criado através do endpoint:
No Sandbox:
A autenticação utiliza Basic Authentication, com o 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.
O representante deve possuir:
  • nome;
  • CPF;
  • telefone;
  • e-mail.
O consentimento deve possuir:
  • CPF do responsável pelo consentimento;
  • endereço IP;
  • data e hora da autorização.

3. Exemplo de criação

Os valores monetários são enviados em centavos. Por exemplo:
representa R$ 5.000,00.

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.
Exemplo:
Boa prática: salve o org_id, entity_id e o external_id no seu sistema. O org_id será 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:
O cliente deve utilizar esse link para concluir a etapa de reconhecimento facial.

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 categoria entity 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.
A partir desse evento, sua aplicação pode considerar a organização do cliente apta para as operações previstas no produto.

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 o org_id do cliente no header:
Exemplo:
Nesse cenário:
O acesso é validado pela Trio a cada requisição. Se a organização distribuidora não possuir acesso à organização informada, a API retorna 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 o POST /onboarding, armazene no seu sistema pelo menos:
  • external_id;
  • org_id;
  • entity_id;
  • company_id;
  • tax_number;
  • status atual.
Isso facilita a reconciliação entre o seu sistema e a Trio.

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:
ou:

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:
o cliente pode seguir para as operações previstas na integração.

Trate a rejeição

Quando receber:
armazene o 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:
Use essa chamada para listar as contas virtuais criadas para a organização do cliente e coletar o identificador da conta necessário para realizar transações em nome dele. Este guia também está disponível em inglês: /guides/onboarding-guide.