Saltar al contenido principal
El plugin Bank Transfer es un servicio autónomo que gestiona toda la comunicación con la red SPB de Brasil (a través de JD Consultores). Administra el ciclo de vida completo de la transferencia — desde el cálculo de tarifas hasta la confirmación de liquidación — para que tu equipo no necesite interactuar con JD directamente.

Lo que el plugin gestiona por ti


  • Envía TEDs salientes a cualquier banco brasileño (TED OUT)
  • Recibe y acredita TEDs entrantes automáticamente (TED IN)
  • Procesa transferencias internas instantáneas entre cuentas (P2P)
  • Calcula y aplica tarifas automáticamente antes de que el cliente confirme
  • Detecta y previene transferencias duplicadas dentro de una ventana configurable
  • Valida días hábiles BACEN contra el calendario bacen_holidays (seed estático para 2026–2028; el refresher en vivo de ANBIMA está pendiente)
  • Firma mensajes con el certificado digital de tu institución, según lo exige el BACEN
  • Reintenta operaciones fallidas automáticamente
  • Notifica a tu sistema a través de webhooks en tiempo real ante cada cambio de estado

Cómo funciona TED OUT


TED OUT utiliza un flujo de dos pasos para que el cliente pueda revisar la tarifa antes de confirmar.

Paso 1 — Iniciar

1
Tu sistema llama al plugin con los detalles de la transferencia (monto, destinatario, cuenta del remitente).
2
El plugin valida la cuenta del remitente, verifica el horario de funcionamiento y ejecuta la detección de duplicados.
3
El plugin calcula la tarifa y devuelve un initiationId con los montos calculados.
4
Tu sistema muestra la tarifa al cliente para su confirmación.
La iniciación es válida por 24 horas. Si el cliente no confirma dentro de ese período, expira automáticamente.

Paso 2 — Procesar

1
Tu sistema llama al plugin con el initiationId para confirmar.
2
El plugin verifica los límites diarios y mensuales y comprueba el saldo disponible.
3
El plugin reserva los fondos en Midaz (hold) y envía el mensaje firmado a JD Consultores.
4
JD enruta la transferencia al banco de destino a través de la red SPB.
5
El plugin recibe la confirmación de liquidación de JD y finaliza los registros.
6
Tu sistema recibe un webhook con el estado final.

Cómo funciona TED IN


  1. Un banco externo envía un TED a tu institución a través de JD Consultores.
  2. El plugin consulta a JD cada 60 segundos (valor por defecto) para detectar nuevas transferencias entrantes.
  3. El plugin valida al destinatario contra el CRM para encontrar la cuenta correcta.
  4. El plugin acredita la cuenta en Midaz y crea un registro de transferencia completado.
  5. Tu sistema recibe un webhook confirmando el crédito.
La recepción de TED IN está deshabilitada por defecto. Habilítala por organización a través de la Admin API una vez que tus credenciales JD y el worker de polling estén configurados.

Cómo funciona P2P


Las transferencias P2P mueven fondos entre dos cuentas dentro de la misma organización, sin pasar por la red SPB. La liquidación es instantánea.
  1. Tu sistema llama al plugin con la cuenta del remitente, la cuenta del destinatario y el monto.
  2. El plugin calcula la tarifa (si está configurada) y la presenta para confirmación.
  3. Tras la confirmación, el plugin ejecuta la transferencia en Midaz.
  4. Ambas cuentas se actualizan inmediatamente. Tu sistema recibe un webhook.

Modelos de despliegue


El plugin TED admite dos modelos de despliegue, definidos a través de la variable de entorno DEPLOYMENT_MODE.

SaaS (gestionado por Lerian)

En los despliegues SaaS, Lerian gestiona la integración con JD Consultores, incluyendo la gestión de credenciales y el mantenimiento de certificados. Tu equipo solo necesita configurar los ajustes a nivel de negocio, como límites de transacción, tarifas y webhooks, a través de la Admin API. No se requiere gestión de infraestructura ni de conexiones. Al ejecutarse en modo saas, el plugin opera como un servicio multi-tenant. La identidad del tenant, las credenciales JD, los secretos de webhook y ciertos ajustes de configuración se resuelven dinámicamente a través del servicio de la plataforma de multi-tenancy. En este modo, las variables MULTI_TENANT_* y AWS_REGION son obligatorias y utilizadas activamente por el plugin.

BYOC (trae tus propias credenciales)

En los despliegues BYOC, tu institución es responsable de proporcionar las credenciales de JD Consultores y la clave privada RSA utilizada para firmar los mensajes. Estos valores son configurados por tu equipo de DevOps a través de variables de entorno, lo que te otorga control total sobre la conexión JD y permite que el plugin se ejecute completamente dentro de tu propia infraestructura. Este es el modo de despliegue predeterminado (byoc). Toda la configuración —incluyendo credenciales JD, secretos de webhook y ajustes relacionados con tarifas— se carga desde variables de entorno durante el arranque de la aplicación.

Resolución de organización

En los despliegues single-tenant, la organización de Midaz se identifica a través del header requerido X-Organization-Id en las rutas de API con alcance de organización. Para los procesos en segundo plano que no reciben headers de solicitud, como el poller de TED IN y los workers de reconciliación, el plugin recurre a la variable de entorno ORGANIZATION_ID.
Las variables relacionadas con multi-tenancy (MULTI_TENANT_*) y AWS_REGION se ignoran cuando el plugin se ejecuta en modo byoc.
Consulta Configuración de Bank Transfer para la lista completa de variables de entorno admitidas.

Integración con Midaz


Todos los movimientos financieros pasan a través del ledger de Midaz. El plugin crea transacciones en Midaz para cada transferencia:
  • TED OUT — los fondos se retienen cuando la transferencia es confirmada (paso de proceso, vía pending: true), luego se debitan al recibir la confirmación de liquidación.
  • TED IN — los fondos se acreditan después de que la transferencia sea validada y confirmada por JD.
  • P2P — una única transacción de Midaz debita al remitente y acredita al destinatario de forma atómica.
Esto significa que cada transferencia queda completamente reflejada en tu ledger de Midaz con un registro de transacción correspondiente. Consulta Datos y reportes de Bank Transfer para los campos disponibles para la reconciliación.

Para desarrolladores


Arquitectura

El plugin utiliza arquitectura Hexagonal (Puertos y Adaptadores) combinada con CQRS. La lógica de negocio está aislada de la infraestructura, lo que facilita agregar nuevos adaptadores (por ejemplo, un proveedor SPB diferente) sin cambiar el comportamiento del núcleo.
Ted Architectural Pattern

Detección de duplicados

El plugin genera una huella (fingerprint) de detección de duplicados a partir de senderAccountId, los datos del destinatario (ISPB, agencia, cuenta, documento del titular), el monto y el propósito, y la almacena en Redis con un TTL configurable (por defecto: 300 segundos vía DUPLICATE_GUARD_TTL_SEC). La organización no forma parte de la huella; el aislamiento de tenant proviene del prefijo de clave de Redis. Las solicitudes duplicadas dentro de la ventana son rechazadas con 409 Conflict y el código de error BTF-0012.

Aislamiento de datos multi-tenant

El aislamiento de tenant proviene de la resolución de base de datos de la plataforma de multi-tenancy. El tenantId se extrae del claim JWT o del contexto autenticado y nunca se proporciona a través de X-Organization-Id. La caché de Redis usa prefijos de clave por tenant (tenant:{tenantId}:{key}), y las tablas de negocio usan los campos de organización Midaz solo para la autorización de alcance de negocio dentro del tenant resuelto.

Observabilidad

El plugin expone métricas de Prometheus, logs JSON estructurados y trazas OpenTelemetry. Las sondas de liveness y readiness sin autenticación están disponibles para la orquestación de Kubernetes. Estos son principalmente relevantes para despliegues BYOC.
Las sondas de liveness y readiness no requieren autenticación por diseño (para compatibilidad con sondas K8s). En despliegues BYOC, restringe el acceso a estas sondas a nivel de red (por ejemplo, mediante reglas de ingress o grupos de seguridad) para evitar exponer el estado de dependencias internas a internet público.