Saltar al contenido principal
Migo Docs

Inicio rápido de Payment Link

Recorrido de extremo a extremo: el backend del comercio crea una transacción, el cliente paga en el webview hospedado por Migo, y el comercio recibe el resultado vía webhook.

┌─ backend del comercio ─┐
│ 1. POST │ /transactions ──────►
│ (auth: token) │
│ │ ◄──── 2. uid + URL
└────────────────────────┘
│ 3. envía la URL al cliente

┌─ cliente ─────────────────────────────────────┐
│ 4. abre el webview hospedado en la URL │
│ y paga ahí: ingresa los datos de tarjeta, │
│ elige cuotas, completa 3DS │
└────────────────────────────────────────────────┘


┌─ backend del comercio ─┐
│ 5. recibe el resultado │ ◄──── webhook (estado terminal)
└────────────────────────┘

1. Crea la transacción (backend del comercio)

El camino recomendado para una integración de backend es POST /transactions con tu merchant token en el header Authorization. Envía el valor crudo que Migo emitió para tu aplicación — el token crudo (sin prefijo Bearer) es la forma recomendada, aunque el authorizer tolera y elimina un Bearer inicial si está presente. Consulta Autenticación.

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": []
}'

Respuesta:

{
"uid": "trx_8f3c2b1d9e7a",
"reference": "CLIENT020007SB",
"URL": "https://sandbox.migopayments.com/?orderId=trx_8f3c2b1d9e7a"
}
El nombre del campo URL está en mayúsculas

El link al webview hospedado se entrega en URL (mayúsculas U-R-L), no en url. Los parsers que desestructuran con const { url } = body obtendrán undefined silenciosamente. Consulta Crear un Payment Link → forma de la respuesta.

Envía el valor de URL al cliente (WhatsApp, SMS, email — cualquier canal funciona).

Entradas en la especificación en vivo: POST /transactions (principal, auth por bearer) · POST /transactions-hook (alternativa, auth por credenciales en el cuerpo, CORS habilitado — consulta Crear un Payment Link y el Cheat sheet de Sandbox para saber cuándo elegir cuál).

2. El cliente abre el webview hospedado

Migo sirve el webview hospedado en la URL emitida. Cuando el cliente lo abre, el webview resuelve la configuración del cliente y los procesadores habilitados, y renderiza la UI de pago automáticamente — aquí no hay nada que tengas que llamar.

Consulta Webview hospedado para más detalles.

3. El cliente completa el pago en el webview

Todo en este paso sucede dentro del webview hospedado de Migo — el integrador no hace nada aquí.

Dentro del webview el cliente:

  • ingresa los datos de su tarjeta en el formulario de pago,
  • elige el número de cuotas,
  • y confirma el pago.

Si el procesador requiere 3D Secure, el webview le presenta el challenge al cliente y recopila la respuesta. Migo luego tokeniza la tarjeta y cobra la transacción internamente; no se involucra ninguna llamada a la API del integrador.

Consulta Webview hospedado para conocer cómo se comporta el checkout (incluido cualquier challenge 3D Secure).

4. Recibe el resultado (backend del comercio)

Migo notifica al comercio una vez que la transacción alcanza un estado terminal (approved, denied, refunded, reversed). El producto de Payment Link usa el Merchant Generic Callback — un POST saliente desde Migo a una URL que registraste con soporte, que lleva { uid, reference, status, amount, currency, ... }.

MecanismoDirecciónCuándoDocumentación
Merchant Generic CallbackMigo → tu backendLa transacción alcanza un estado terminalMerchant Generic Callback
Callback del procesador → MigoProcesador → Migo (interno)El procesador confirma el resultadoHooks entrantes del procesador

El Generic Callback no firma el cuerpo con HMAC — la autenticidad se delega al comercio mediante una API key/header estático que registras con Migo. Consulta Merchant Generic Callback → Autenticando la solicitud.

¿Qué sigue?