Saltar al contenido principal
Migo Docs

Arquitectura de la plataforma

Desde la perspectiva del integrador, Migo expone un pequeño número de APIs REST públicas sobre HTTPS. Te autenticas, llamas un endpoint y recibes una respuesta JSON estandarizada. Todo lo que hay detrás de esos endpoints es responsabilidad de Migo y no forma parte del contrato contra el que integras.

Superficie pública​

                          ┌────────────────────────────┐
                          │  Tu aplicación (web,       │
                          │  móvil o backend)          │
                          └────────────┬───────────────┘
                                       │ HTTPS + JWT
      ┌────────────────────────────────┼────────────────────────────────┐
      │                                │                                │
┌─────┴──────────────┐    ┌────────────┴────────┐    ┌─────────────────┴───┐
│ Wallet Gateway     │    │ Middleware API      │    │ CMS Backoffice API  │
│ api.ali.app/rest   │    │ mw.migopayments.com │    │ api.ali.app/cms/rest│
└────────────────────┘    └─────────────────────┘    └─────────────────────┘

Existe además un Gateway de migración para la transición Migo→ALI; los integradores son habilitados en él explícitamente por Migo. Si no te han dado su base URL, no lo necesitas.

Cada API habla HTTPS + JSON plano. Nunca te conectas a ninguna otra cosa — no hay acceso directo a base de datos, ni bus de mensajes, ni endpoint privado que llames.

Responsabilidades​

APIPara qué la usasQué NO hace
Wallet GatewayUsuarios, tarjetas, wallets, leads, terminales, liquidaciones — los bloques básicos de un programa de tarjetas/walletCobros recurrentes (usa el Middleware)
MiddlewareHosted Payment Links, el motor de suscripciones, verificaciones de BIN, suspensiones por fraudeEmisión de tarjetas (usa el Wallet Gateway)
CMS BackofficeGestión de partners y tarjetahabientes, RBAC, operaciones masivasCreación directa de transacciones

Elige la superficie según el recurso que necesitas. Un objeto de negocio dado (una tarjeta, una transacción, una liquidación) pertenece exactamente a una superficie; la referencia de API te indica cuál.

Flujo de una solicitud — ejemplo: transferencia entre tarjetas​

  1. Tu app llama POST /cards/transfer en el Wallet Gateway para mover fondos entre dos tarjetas del mismo ecosistema.
  2. Migo valida tu JWT y tus permisos de aplicación/usuario, valida ambas tarjetas y saldos, y realiza el movimiento.
  3. El Gateway devuelve el envelope estandarizado CustomResponse<T> con el resultado (aprobado / rechazado).

Solo ves la solicitud que envías y la respuesta que recibes. Migo maneja internamente el enrutamiento, la validación de saldos y la coordinación con el procesador.

nota

POST /cards/{cardId}/statements no es un cobro — le pide a Migo generar un estado de cuenta mensual de la tarjeta (un PDF, producido de forma asíncrona) y recibe { month, year }. Otros endpoints de movimiento de dinero incluyen PUT /cards/{cardId}/funds (cargar/descargar saldo de tarjeta) y el flujo de pago POS / terminal.

Operaciones de larga duración​

Algunas operaciones no terminan dentro de una sola solicitud:

  • Las cargas masivas (p. ej. batches de tarjetahabientes, archivos de conciliación) devuelven 200 OK con un id de batch/job en el body. Consultas el endpoint de progreso correspondiente (p. ej. /app/partners/{partnerId}/cardholders/batch/{batchId}/progress) hasta que se completa.
  • La generación de estados de cuenta devuelve 201 Created con una referencia de job; el PDF se produce de forma asíncrona.

Trata cualquier respuesta que te entregue un id de job/batch como asíncrona y consulta el resultado en lugar de bloquearte.

Observabilidad​

Cada solicitud se correlaciona con una traza interna. Al abrir un ticket de soporte, proporciona el timestamp de la solicitud y los detalles completos de solicitud/respuesta (con el Bearer token y cualquier PAN/CVV ocultos) para que Migo pueda correlacionarla con la traza.

Relacionado​