Solar financing, built into the CRM
Integrations with four banks and credit providers that run each deal’s financing — simulation, credit pre-analysis, proposal and status — from inside the CRM. Two are live, two in certification. Built solo.
- Role
- Sole developer — integrations and partner meetings
- Period
- Sep 2025 – Present
- Context
- Groner · solo
- Stack
- C# .NET Lambda SQS API Gateway SQL Server Vue.js
This work is proprietary to Groner. It is described at architecture level, without source code or client data.
At a glance
- 4 partners integrated — 2 live, 2 in certification
- Status webhooks delivered at least once, per customer
- Dozens of meetings with partners’ teams
Context
Many solar systems in Brazil are paid for with financing from banks and fintechs that specialize in solar credit. For an installer, getting the financing moving right after the sale is part of closing the deal.
The problem
Financing ran on each partner’s portal, outside the CRM. Customers had no control over which closed deals had already started the financing process — or where each one stood.
My role
I built the integrations on my own, from each partner’s documentation to production, and represented Groner in dozens of meetings with Solfácil, Sol Agora, Banco BV and Revocred, from Conectepag. Solfácil and Sol Agora are live; Banco BV and Revocred are fully built and in certification, pending the partners’ validations.
Architecture
- Outbound, synchronous. From a deal, the CRM calls the partner’s API to simulate, run a credit pre-analysis and submit the proposal. The API reads what it needs, releases the database connection, calls the partner and only then writes the result — a slow bank never holds a connection.
- Inbound, asynchronous. Partners report status changes through webhooks. An intake Lambda acknowledges each one and queues it in SQS; a forwarder asks a central registry which customer it belongs to and delivers it to that customer’s API — every customer has its own database.
- On the deal. A deal can have several financing records, each with its partner journey, status history and the raw events behind it.
Key decisions
- One client per partner, common statuses. The partners differ too much for one shared interface — OAuth 2, password sign-in, mutual TLS; different operations and status codes. Each integration follows its partner’s contract closely, and a mapping turns every status into a common set.
- At-least-once delivery. Client errors are dropped, server errors are retried, and after five failures a message goes to a dead-letter queue. Repeated events are ignored, and raw payloads are kept for auditing.
- Credentials per customer. Each installer connects its own partner accounts; secrets are encrypted or kept in AWS Secrets Manager.
The hardest part
Not the code — the partners. Banks and fintechs are bureaucratic, and making an integration smooth often meant asking them to change something on their side, which took meetings, tickets and patience. Their constraints shape the design, too: one partner accepts a single callback URL per environment, with no query parameters — so each callback carries an identifier in its path, and the registry routes it to the right customer.
Results
- Financing with Solfácil and Sol Agora runs from inside the CRM: simulation, credit pre-analysis, proposal and status.
- Every financing started from the CRM is tied to its deal, with its status history — so teams know which closed deals already have financing under way.
- Banco BV and Revocred are built on the same pattern and in certification, waiting on the partners’ validations to go live.