Financiamento solar dentro do CRM
Integrações com quatro bancos e financeiras que levam o financiamento de cada negócio — simulação, pré-análise de crédito, proposta e status — para dentro do CRM. Duas no ar, duas em homologação. Feitas sozinho.
- Papel
- Desenvolvedor único — integrações e reuniões com parceiros
- Período
- Set 2025 – Atual
- Contexto
- Groner · sozinho
- Stack
- C# .NET Lambda SQS API Gateway SQL Server Vue.js
Este trabalho é propriedade da Groner. Ele é descrito em nível de arquitetura, sem código-fonte nem dados de clientes.
Resumo
- 4 parceiros integrados — 2 no ar, 2 em homologação
- Webhooks de status entregues ao menos uma vez, por cliente
- Dezenas de reuniões com os times dos parceiros
Contexto
Muitos sistemas solares no Brasil são pagos com financiamento de bancos e financeiras especializados em crédito solar. Para o integrador, colocar o financiamento em andamento logo depois da venda faz parte de fechar o negócio.
O problema
O financiamento corria no portal de cada parceiro, fora do CRM. Os clientes não tinham controle de quais negócios fechados já tinham iniciado o processo de financiamento — nem de em que pé cada um estava.
Meu papel
Construí as integrações sozinho, da documentação de cada parceiro até a produção, e representei a Groner em dezenas de reuniões com Solfácil, Sol Agora, Banco BV e Revocred, da Conectepag. Solfácil e Sol Agora estão em produção; o Banco BV e a Revocred estão prontos e em homologação, dependendo de validações dos parceiros.
Arquitetura
- Saída, síncrona. A partir de um negócio, o CRM chama a API do parceiro para simular, fazer a pré-análise de crédito e enviar a proposta. A API lê o que precisa, libera a conexão com o banco de dados, chama o parceiro e só então grava o resultado — um banco lento nunca segura uma conexão.
- Entrada, assíncrona. Os parceiros avisam mudanças de status por webhooks. Uma Lambda de entrada confirma o recebimento e coloca cada um numa fila SQS; uma Lambda de encaminhamento pergunta a um registro central a qual cliente ele pertence e entrega na API desse cliente — cada cliente tem o seu próprio banco de dados.
- No negócio. Um negócio pode ter vários financiamentos, cada um com a jornada no parceiro, o histórico de status e os eventos brutos por trás dele.
Decisões-chave
- Um cliente por parceiro, status em comum. Os parceiros são diferentes demais para uma interface única — OAuth 2, login com senha, TLS mútuo; operações e códigos de status diferentes. Cada integração segue de perto o contrato do seu parceiro, e um mapeamento converte todos os status para um conjunto comum.
- Entrega ao menos uma vez. Erros do cliente são descartados, erros do servidor são reprocessados e, depois de cinco falhas, a mensagem vai para uma fila de mensagens mortas. Eventos repetidos são ignorados, e os payloads brutos ficam guardados para auditoria.
- Credenciais por cliente. Cada integrador conecta as próprias contas nos parceiros; os segredos ficam criptografados ou no AWS Secrets Manager.
A parte mais difícil
Não foi o código — foram os parceiros. Bancos e financeiras são burocráticos, e deixar uma integração fluida muitas vezes significava pedir que eles mudassem algo do lado deles, o que custava reuniões, chamados e paciência. As restrições deles também moldam o desenho: um parceiro aceita uma única URL de callback por ambiente, sem parâmetros de consulta — por isso cada callback leva um identificador no caminho, e o registro central o roteia para o cliente certo.
Resultados
- O financiamento com Solfácil e Sol Agora roda de dentro do CRM: simulação, pré-análise de crédito, proposta e status.
- Todo financiamento iniciado pelo CRM fica ligado ao seu negócio, com o histórico de status — então o time sabe quais negócios fechados já têm financiamento em andamento.
- O Banco BV e a Revocred seguem o mesmo padrão e estão em homologação, aguardando as validações dos parceiros para entrar no ar.