Payment methods

The unified catalog the client picks from when creating an order: active integrations (cash, Sypago, Pago Móvil, …) merged with active payment forms into one ordered list. Paths are relative to the /api/v1 prefix; all routes require Authorization: Bearer {token}.

Form entries are backed by Payment forms. Use the returned paymentMethod (plus paymentFormId when it's a form) as the paymentMethod/paymentFormId body fields of POST /orders.

See Common errors.

Endpoints

GET /payment-methods/available

Returns active integrations ∪ active payment forms, sorted by a shared sort_order. Each entry carries everything the client needs to build the order request.

Response 200

{
  "methods": [
    {
      "type": "INTEGRATION",
      "key": "CASH_USD",
      "paymentMethod": "CASH_USD",
      "paymentFormId": null,
      "label": "Efectivo (USD)",
      "icon": "cash",
      "currency": "USD",
      "sort_order": 1
    },
    {
      "type": "FORM",
      "key": "form:3",
      "paymentMethod": "PAYMENT_FORM",
      "paymentFormId": 3,
      "label": "Transferencia BDV",
      "icon": "bank",
      "currency": "VES",
      "sort_order": 5
    }
  ]
}

Field notes:

• type — INTEGRATION (code-backed) or FORM (admin-managed manual form).
• paymentMethod — the value to send as paymentMethod on POST /orders. Form entries always report PAYMENT_FORM.
• paymentFormId — the id to send as paymentFormId for FORM entries; null for integrations.
• key — a stable client-side key (form:{id} for forms).