- Gerenciado — a Lerian opera a sua infraestrutura e conecta as peças no momento do deploy. Você abre o Console, habilita os produtos e os usa — sem variáveis de ambiente, sem chamadas de integração. (Você não vai precisar do restante desta página.)
- Self-hosted / BYOC — você opera a infraestrutura, então faz as conexões: configura as URLs e o ambiente de cada produto e o implanta. O restante desta página percorre esse caminho. Uma vez conectado, você pode operar pelo Console ou chamar as APIs diretamente — isso é uma escolha de UX, não uma configuração extra.
Comece pelo ledger
Tudo é registrado no Midaz, o Ledger — é a base sobre a qual o restante se constrói. Suba-o primeiro. O CRM já faz parte do Midaz. Os holders e aliases sobre os quais você aprendeu são nativos, então não há nada separado para conectar — você só o habilita. (Isso é diferente das peças abaixo, que são serviços separados.) → Configurar o Midaz · CRM no Midaz
Conecte as peças ao ledger
As outras peças são serviços standalone, e elas não se conectam todas da mesma forma. Aqui está quem chama quem em runtime — essa diferença é a parte prática:
Quem chama quem em runtime
- Os plugins de pagamento gravam no ledger por você. A sua aplicação chama um plugin de pagamento (TED, Pix); o plugin movimenta o dinheiro e registra as operações no Midaz — inclusive a partir dos próprios workers em background — então a sua app não toca o ledger nesses casos. A conexão dele com o Midaz é definida no deploy, invisível para a sua aplicação. → Configuração do TED
- O Fees Engine calcula; a sua app grava. A sua aplicação chama o Fees Engine para calcular as taxas de uma transação; ele lê o Midaz para resolver as contas e devolve o resultado. A sua app então submete a transação — com as taxas — ao Midaz, ou seja, o Fees Engine nunca grava no ledger. (Para qualquer movimento que você registra sem plugin, a sua aplicação grava direto na API do Midaz.) → Conectar o Fees Engine ao Midaz
- O Reporter já vem conectado aos seus dados. Ele lê os dados por trás dos seus produtos Lerian (somente leitura, em uma direção) para montar extratos e relatórios — nunca escreve de volta. Essa conexão é configurada para você no onboarding, então funciona desde o primeiro dia; você só monta os templates de relatório que precisar, e pode adicionar suas próprias fontes de dados depois. → Reporter
- O Tracer é isolado — a sua aplicação orquestra. O Tracer não se conecta ao ledger de forma alguma. O seu código chama a validação do Tracer primeiro, e só envia a transação adiante — para um plugin ou para o Midaz — se a decisão for ALLOW. Tracer e Midaz nunca conversam diretamente. → Guia de integração do Tracer
O Tracer verifica as políticas e limites que você configurou — não os saldos das contas. O ledger continua sendo a fonte única de verdade do que uma conta realmente possui.
Um login para todas as peças
Para que as peças funcionem como um único produto (e não como logins separados), elas compartilham a autenticação por meio do Access Manager: ele emite os tokens que cada serviço confia. Cada peça se autentica com credenciais gerenciadas ali — mantenha os detalhes em um só lugar e aponte as peças para ele. → Access Manager
Implante a stack
Não existe um único pacote de “instalar tudo” — você implanta cada peça (um Helm chart por produto) e as sobe em ordem: Midaz → Access Manager → produtos e plugins → Console O Console vem por último porque precisa dos outros já em execução. → Helm charts
Opere pelo Console
Uma vez que tudo esteja em execução, o Console é o seu painel único: habilite as peças e gerencie-as com um único login. Habilitar um módulo no Console o liga na interface e compartilha o login — a conexão peça-a-ledger é a etapa de implantação acima, não algo que o Console faz por você. → Lerian Console
Em um setup gerenciado
Se a Lerian opera a sua infraestrutura, todas as conexões acima já estão feitas para você. Do seu lado é simples: habilite os módulos no Console e comece a usá-los — sem variáveis de ambiente, sem implantação. A jornada de integração desta página é o que a Lerian cuida por baixo dos panos.
Indo além (opcional)
Um core banking completo é a composição acima. Quando você precisar de mais, o mesmo modelo se estende — por exemplo o Matcher (reconciliação) ou o Flowker (automação de workflows). Eles não fazem parte do core banking, mas se encaixam na mesma stack conforme suas necessidades crescem.