Payment intents

Some alternative rails need merchant-side selection before the customer can pay — the merchant must fetch processor-specific metadata, such as a fixture to use at payment time or a pick-list to render in the checkout. Use payment intents to fetch this metadata for the chosen processor.

POST https://mw.migopayments.com/api/v1/integrations/transactions/{transactionId}/payment-intents

See the live spec entry: POST /api/v1/integrations/transactions/{transactionId}/payment-intents.

When to call: invoke this endpoint before /payments for processors that need a fixture or pick-list. In Guatemala you can skip it for processors that only require static data (zigi, bamPaymentButton, akisiQR, bancoIndustrial, quickPayQR, pronet).

Source of truth. The processor ids you may call here are constrained by the per-transaction paymentMethods array returned by POST .../transactions — that array, not any list on this page, is the runtime source of truth for what your account can use.

Request

Field	Type	Required
processor	string	yes

curl -X POST https://mw.migopayments.com/api/v1/integrations/transactions/trx_8f3c2b1d9e7a/payment-intents \
  -H 'Authorization: Bearer <token>' \
  -H 'Content-Type: application/json' \
  -d '{ "processor": "fri" }'

Auth recap. Every call sends Authorization: Bearer <token>. See Authentication for details.

Response examples

fri — required-fields descriptor (Guatemala sandbox)

fri is the Guatemala sandbox method that uses a pre-call. The intent returns the fields the customer may supply at /payments time — at least one of phoneNumber or user is required.

{
  "success": true,
  "message": "success",
  "data": {
    "requiredFields": {
      "phoneNumber": {
        "description": "Número de teléfono registrado en FRI",
        "required": false
      },
      "user": {
        "description": "Nombre de usuario registrado en FRI",
        "required": false
      },
      "note": "Al menos uno de los dos campos es requerido (phoneNumber o user)"
    }
  }
}

Bank-list and phone patterns (Colombia-market examples — not available in Guatemala)

Other markets use the same endpoint to drive a pick-list or a pre-filled phone number. The examples below are Colombia-market rails and are not available in Guatemala — they illustrate the bank-list and phone patterns only.

A bank-selector response (e.g. globalPay-PSE in Colombia) returns a list the frontend renders as a dropdown:

{
  "success": true,
  "message": "success",
  "data": {
    "banks": [
      { "id": "1007", "name": "Example Bank A" },
      { "id": "1051", "name": "Example Bank B" }
    ],
    "accountTypes": ["checking", "savings"],
    "fisTypes": ["NATURAL", "JURIDICAL"],
    "userTypes": ["NIT", "CC", "CE"]
  }
}

The keys banks, accountTypes, fisTypes, and userTypes are guaranteed; their values are config-driven (banks comes from an external lookup, the rest from the processor configuration). Confirm the exact enum values via a sandbox call. The frontend uses data.banks to render the dropdown, then submits the selected bank id back to /payments under the key the rail's payload requires.

A phone-fixture response (e.g. nequi in Colombia) returns a pre-filled value:

{
  "success": true,
  "message": "success",
  "data": {
    "phoneNumber": "30058059"
  }
}

Allowed processors

The allowed list is illustrative and depends on your market and account. For Guatemala the relevant pre-call/sandbox method is fri; bank-list and phone-fixture rails such as globalPay-PSE and nequi belong to other markets. A processor not enabled for your account, and not part of the per-transaction paymentMethods array, returns 400 Processor not allowed.

Errors

HTTP	Cause
400	Missing transactionId or processor not enabled for this client
500	Upstream processor lookup failed