Mono Colombia
BankingArquitectura

Vista general de arquitectura

Cómo Banking conecta tu producto con los rails bancarios colombianos.

Banking es el puente de Mono entre tu producto y la red bancaria colombiana. Cuando llamas a un endpoint de Banking, la solicitud pasa por autenticación, chequeo de idempotencia y routing antes de ser despachada a uno de los rails de dispersión disponibles: ACH, Transfiya o Mono Turbo. Los recaudos (dinero entrando) siguen el rail PSE.

Esta página es el punto de partida correcto si quieres entender el camino que toma una solicitud por Banking, el rail al que llega y por qué una sola llamada de transferencia puede terminar usando un rail diferente al que solicitaste (Mono cae automáticamente).

Rails

RailTipoUso típico
Mono TurboDispersión en tiempo realTransferencias en tiempo real a bancos colombianos participantes
ACHDispersión estándarTransferencias de mismo día a cualquier banco colombiano
TransfiyaDispersión en tiempo realTransferencias dentro de un clúster específico de bancos
PSERecaudoTransferencia bancaria iniciada por el cliente (checkout e-commerce)

Ciclo de vida de la solicitud

  1. Autenticar — se valida la API key del header Authorization.
  2. Chequear idempotenciaX-Idempotency-Key se busca en el caché.
  3. Enrutar — la solicitud aterriza en el rail que solicitaste o su fallback.
  4. Despachar — Mono envía la operación al rail.
  5. Confirmar — los webhooks se disparan a medida que el rail confirma o rechaza.

Fallbacks

Mono Turbo puede caer a ACH cuando el destino no soporta settlement en tiempo real. El árbol de decisión del fallback se documentará aquí.

Referencias del ciclo de vida

Una vez que una solicitud entra a la plataforma, se mueve por una máquina de estados determinista, y cada transición emite un webhook. Las páginas de abajo documentan cada estado, sus transiciones y el evento correspondiente — léelas junto con la arquitectura de arriba para entender a qué debe estar escuchando tu integración.

Siguientes pasos

En esta página