Catálogo de eventos

Cada evento se llama <operación>_<estado> y viaja en el campo event_type del payload. Los grupos de abajo coinciden con el formulario de endpoint de Desarrolladores › Webhooks, y cada grupo tiene un formato de payload fijo. Qué grupos te aplican depende de cómo integraste Tonder; el formato no se elige por endpoint. El modelo conceptual está en el Modelo de webhooks.

Formatos

Pagos — API Direct (Short)

Pagos y reembolsos de API Direct. Hosted Checkout 2.0 procesa los pagos a través de API Direct, así que un pago hecho en la página alojada también envía estos eventos.

Un pago pasa solo por los estados que usa su método y su flujo, así que suscríbete a los que tu integración atiende. En SPEI Success, el payload añade datos del remitente: sender_name, sender_clabe, sender_bank, entre otros. Los pagos con QR y por transferencia bancaria de Argentina usan estos mismos eventos; sus datos del pagador están en Argentina.

Un evento payment_Success:

{
  "id": "bf370a48-ffcf-4fbe-bab9-ecb791b0b684",
  "event_type": "payment_Success",
  "operation_type": "payment",
  "status": "Success",
  "amount": "500.00",
  "currency": "MXN",
  "country": "MX",
  "client_reference": "ORD-001",
  "transaction_id": "1464",
  "payment_method_type": "card",
  "decline_code": null,
  "decline_reason": null,
  "created": "2026-10-20T18:52:10Z",
  "metadata": { "external_id": "ORD-001" },
  "action": "MODIFY"
}

• id es el identificador de la transacción que te devolvió la API al crear el pago (/process/); úsalo para relacionar el webhook con tu pedido.
• client_reference y metadata son los datos que enviaste al crear la transacción.
• El payload también puede traer campos que identifican a la institución que procesó la transacción. No construyas lógica sobre ellos.

Sesiones de checkout — Hosted y SDK (Long)

Eventos de integraciones anteriores —SDK 1.0, el flujo anterior de Hosted Checkout y la API de retiros v1/v2. El prefijo legacy_ los identifica, y los payloads están en Webhooks legacy.

Retiros (Long)

withdrawal_Canceled se escribe con una sola L, a diferencia de payment_Cancelled y refund_Cancelled. Compara los nombres de evento exactamente. Sin Webhooks 2.0, los retiros emiten cinco eventos y ninguno por cancelación.

Un retiro envía el evento pendiente y después el terminal; withdrawal_Returned llega además, cuando el banco receptor devuelve los fondos después del Success. El payload viene en uno de dos formatos, definido por la configuración de tu comercio: un payload plano con la misma forma que el formato Short de pagos (status: Pending, transfer_method_type en lugar de payment_method_type), o un payload extendido que anida el registro completo del retiro bajo withdrawal{} con el estado en los nombres internos (PAID_FULL). Los dos, con ejemplos, en Retiros.

Otros

El catálogo por API

GET /v1/event-types devuelve el catálogo con la descripción de cada evento, además de la política de reintentos —ver API de webhooks.

Siguientes pasos