Skip to main content
Migo Docs

Platform Architecture

From an integrator's perspective, Migo exposes a small number of public REST APIs over HTTPS. You authenticate, call an endpoint, and receive a standardized JSON response. Everything behind those endpoints is Migo's responsibility and is not part of the contract you integrate against.

Public surface​

                          ┌────────────────────────────┐
                          │  Your application (web,    │
                          │  mobile, or backend)       │
                          └────────────┬───────────────┘
                                       │ HTTPS + JWT
      ┌────────────────────────────────┼────────────────────────────────┐
      │                                │                                │
┌─────┴──────────────┐    ┌────────────┴────────┐    ┌─────────────────┴───┐
│ Wallet Gateway     │    │ Middleware API      │    │ CMS Backoffice API  │
│ api.ali.app/rest   │    │ mw.migopayments.com │    │ api.ali.app/cms/rest│
└────────────────────┘    └─────────────────────┘    └─────────────────────┘

There is also a migration Gateway for the Migo→ALI transition; integrators are onboarded to it explicitly by Migo. If you have not been given its base URL, you do not need it.

Each API speaks plain HTTPS + JSON. You never connect to anything else — there is no direct database access, no message bus, and no private endpoint you call.

Responsibilities​

APIWhat you use it forWhat it does NOT do
Wallet GatewayUsers, cards, wallets, leads, terminals, settlements — the building blocks of a card/wallet programRecurring billing (use the Middleware)
MiddlewareHosted Payment Links, the subscription engine, BIN verifications, fraud suspensionsCard issuance (use the Wallet Gateway)
CMS BackofficePartner and cardholder management, RBAC, bulk operationsDirect transaction creation

Pick the surface by the resource you need. A given business object (a card, a transaction, a settlement) is owned by exactly one surface; the API reference tells you which.

Request flow — example: transfer between cards​

  1. Your app calls POST /cards/transfer on the Wallet Gateway to move funds between two cards in the same ecosystem.
  2. Migo validates your JWT and your application/user permissions, validates both cards and balances, and performs the movement.
  3. The Gateway returns the standardized CustomResponse<T> envelope with the result (approved / denied).

You only ever see the request you send and the response you receive. Migo handles routing, balance validation, and processor coordination internally.

note

POST /cards/{cardId}/statements is not a charge — it asks Migo to generate a monthly card statement (a PDF, produced asynchronously) and takes { month, year }. Other money-movement endpoints include PUT /cards/{cardId}/funds (load/unload card balance) and the POS / terminal-payment flow.

Long-running operations​

Some operations don't finish within a single request:

  • Bulk uploads (e.g. cardholder batches, conciliation files) return 200 OK with a batch/job id in the body. You poll the corresponding progress endpoint (e.g. /app/partners/{partnerId}/cardholders/batch/{batchId}/progress) until it completes.
  • Statement generation returns 201 Created with a job reference; the PDF is produced asynchronously.

Treat any response that hands you a job/batch id as asynchronous and poll for the result rather than blocking.

Observability​

Each request is correlated to an internal trace. When you open a support ticket, provide the request timestamp and the full request/response details (with the Bearer token and any PAN/CVV redacted) so Migo can correlate it to the trace.