Payment Link Quick Start

End-to-end walkthrough: the merchant backend creates a transaction, the customer pays in Migo's hosted webview, and the merchant receives the result via webhook.

┌─ merchant backend ──┐
│ 1. POST             │  /transactions  ──────►
│    (auth: token)    │
│                     │ ◄──── 2. uid + URL
└─────────────────────┘
        │ 3. send URL to customer
        ▼
┌─ customer ──────────────────────────────────┐
│ 4. opens the hosted webview at the URL       │
│    and pays there: enters card data,         │
│    chooses installments, completes 3DS       │
└──────────────────────────────────────────────┘
        │
        ▼
┌─ merchant backend ──┐
│ 5. receives result  │ ◄──── webhook (terminal status)
└─────────────────────┘

1. Create the transaction (merchant backend)

The recommended path for a backend integration is POST /transactions with your merchant token in the Authorization header. Send the raw value Migo issued for your application — the raw token (no Bearer prefix) is the recommended form, though the authorizer tolerates and strips a leading Bearer if present. See Authentication.

curl -X POST https://sb-mw.migopayments.com/transactions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: <your-sandbox-token>' \
  -d '{
    "amount": 125.50,
    "userId": "+50212345678",
    "channel": "wa",
    "client": "your-client-slug",
    "currency": "GTQ",
    "externalId": "ORD-2026-0429-001",
    "ads": []
  }'

Response:

{
  "uid": "trx_8f3c2b1d9e7a",
  "reference": "CLIENT020007SB",
  "URL": "https://sandbox.migopayments.com/?orderId=trx_8f3c2b1d9e7a"
}

Field name URL is uppercase

The hosted webview link is delivered in URL (capital U-R-L), not url. Parsers that destructure with const { url } = body will silently get undefined. See Create a Payment Link → response shape.

Send the value of URL to the customer (WhatsApp, SMS, email — any channel works).

Live spec entries: POST /transactions (primary, bearer auth) · POST /transactions-hook (alternative, body-credential auth, CORS-enabled — see Create a Payment Link and the Sandbox cheat sheet for when to pick which).

2. The customer opens the hosted webview

Migo serves the hosted webview at the issued URL. When the customer opens it, the webview resolves the client configuration and the enabled processors and renders the payment UI automatically — there is nothing for you to call here.

See Hosted webview for details.

3. The customer completes the payment in the webview

Everything in this step happens inside Migo's hosted webview — the integrator does nothing here.

Inside the webview the customer:

• enters their card details in the payment form,
• chooses the number of installments,
• and confirms the payment.

If the processor requires 3D Secure, the webview presents the challenge to the customer and collects the response. Migo then tokenizes the card and charges the transaction internally; no integrator API call is involved.

See Hosted webview for how the checkout (including any 3D Secure challenge) behaves.

4. Receive the result (merchant backend)

Migo notifies the merchant once the transaction reaches a terminal status (approved, denied, refunded, reversed). The Payment Link product uses the Merchant Generic Callback — an outbound POST from Migo to a URL you registered with support, carrying { uid, reference, status, amount, currency, ... }.

Mechanism	Direction	When	Documentation
Merchant Generic Callback	Migo → your backend	Transaction reaches terminal status	Merchant Generic Callback
Processor → Migo callback	Processor → Migo (internal)	Processor confirms outcome	Inbound processor hooks

The Generic Callback does not sign the body with HMAC — authenticity is delegated to the merchant via a static API key/header you register with Migo. See Merchant Generic Callback → Authenticating the request.

What next?

• Create a Payment Link — full reference (request body, error codes, primary vs alternative endpoint)
• React quickstart — copy-paste form that calls /transactions and renders the link
• Sandbox cheat sheet — base URLs, test cards, sample payloads ready to copy
• Merchant Generic Callback — receive the terminal status on your backend
• Hosted webview architecture — what happens inside the URL the customer opens
• Browse the live spec at /api-reference/migo-api.