- Gestionado — Lerian opera tu infraestructura y conecta las piezas en el momento del despliegue. Abres el Console, habilitas los productos y los usas — sin variables de entorno, sin llamadas de integración. (No necesitarás el resto de esta página.)
- Autohospedado / BYOC — tú operas la infraestructura, así que tú haces la conexión: configuras las URLs y el entorno de cada producto, y lo despliegas. El resto de esta página recorre eso. Una vez conectado, puedes operar desde el Console o llamar las APIs directamente — eso es una elección de UX, no conexión adicional.
Empieza con el ledger
Todo se registra en Midaz, el Ledger — es la base sobre la que se construye todo lo demás. Levántalo primero. CRM ya forma parte de Midaz. Los holders y aliases que aprendiste vienen integrados, así que no hay nada separado que conectar — solo lo habilitas. (Esto es diferente de las piezas de abajo, que son servicios separados.) → Configurar Midaz · CRM en Midaz
Conecta las piezas al ledger
Las demás piezas son servicios standalone, y no todas se conectan de la misma forma. Esto es quién llama a quién en runtime — esa diferencia es la parte práctica:
- Los plugins se sitúan entre tu aplicación y el ledger. Tu aplicación llama al plugin, y el plugin registra las operaciones resultantes en Midaz — tu app no toca el ledger directamente en esos casos. Un plugin de pago (TED, Pix) mueve el dinero que entra y sale; el plugin de Fees se encarga de la tarificación, no de rieles de pago, registrando cada comisión como operaciones contables en Midaz. La conexión de cada plugin con Midaz se define en el deploy, invisible para tu aplicación. Para movimientos que solo registras, sin ningún plugin involucrado, tu aplicación escribe directo en la API de Midaz. → Configurar TED · Plugin de Fees
- Reporter ya viene conectado a tus datos. Lee los datos detrás de tus productos Lerian (solo lectura, una dirección) para construir extractos e informes — nunca escribe de vuelta. Esa conexión se configura por ti durante el onboarding, así que funciona desde el primer día; tú solo construyes las plantillas de informe que necesites, y puedes agregar tus propias fuentes de datos después. → Reporter
- Tracer está aislado — tu aplicación orquesta. Tracer no se conecta al ledger en absoluto. Tu código llama primero a la validación de Tracer, y solo envía la transacción adelante — a un plugin o a Midaz — si la decisión es ALLOW. Tracer y Midaz nunca se comunican directamente. → Guía de integración de Tracer
Tracer verifica las políticas y límites que configuraste — no los saldos de las cuentas. El ledger sigue siendo la fuente de verdad de lo que una cuenta realmente tiene.
Un solo inicio de sesión entre las piezas
Para que las piezas funcionen como un solo producto (y no como inicios de sesión separados), comparten autenticación a través de Access Manager: este emite los tokens que cada servicio confía. Cada pieza se autentica con credenciales gestionadas ahí — mantén los detalles en un solo lugar y apunta las piezas hacia él. → Access Manager
Despliega el stack
No hay un único paquete de “instalar todo” — despliegas cada pieza (un Helm chart por producto) y las levantas en orden: Midaz → Access Manager → productos y plugins → Console El Console va al final porque necesita que los demás ya estén en ejecución. → Helm charts
Opéralo desde el Console
Una vez que todo está en ejecución, el Console es tu único panel de control: habilita las piezas y gestiónalas con un solo inicio de sesión. Habilitar un módulo en el Console lo activa en la interfaz y comparte el inicio de sesión — la conexión de cada pieza al ledger es el paso de despliegue de arriba, no algo que el Console haga por ti. → Lerian Console
En una configuración gestionada
Si Lerian opera tu infraestructura, toda la conexión de arriba ya está hecha por ti. Desde tu lado es simple: habilita los módulos en el Console y empieza a usarlos — sin variables de entorno, sin despliegue. El recorrido de integración de esta página es lo que Lerian maneja por debajo.
Ir más allá (opcional)
Un core banking completo es la composición de arriba. Cuando necesites más, el mismo modelo se extiende — por ejemplo Matcher (conciliación) o Flowker (automatización de flujos de trabajo). No forman parte del core banking, pero se integran al mismo stack cuando tus necesidades crecen.