Skip to main content

Descripción General

Los eventos de webhook de transacciones le permiten recibir notificaciones en tiempo real cuando se crean o actualizan transacciones en su organización. Gu1 envía automáticamente solicitudes HTTP POST a su endpoint de webhook configurado, permitiéndole automatizar flujos de trabajo de monitoreo de transacciones, detección de fraude y cumplimiento normativo.

¿Por Qué Usar Webhooks de Transacciones?

Monitoreo en Tiempo Real

Reciba notificaciones instantáneas sobre transacciones nuevas o actualizadas

Detección de Fraude

Implemente verificaciones de seguridad adicionales en tiempo real

Automatización de Workflows

Active procesos automáticos basados en actividad transaccional

Auditoría y Cumplimiento

Mantenga registros de auditoría sincronizados en todos sus sistemas

Eventos Disponibles

Gu1 envía webhooks para los siguientes eventos de transacciones:
Los eventos transaction.created y transaction.updated están actualmente en desarrollo y se activarán próximamente. La documentación está disponible para preparar su integración.Disponible hoy: transaction.status_changed se emite cuando cambia el estado. Gu1 también puede enviar transaction.updated en el mismo cambio (payload más rico con montos, origen/destino, etc.). Suscríbase a uno o a ambos según necesite la instantánea completa o solo la transición.

Estructura del Payload de Evento

Todos los eventos de webhook de transacciones siguen esta estructura estándar:

Campos Comunes del Payload

string
El tipo de evento (por ejemplo, transaction.created)
string
Timestamp ISO 8601 cuando ocurrió el evento
string
Su ID de organización
string
El ID UUID de la transacción en Gu1
string
Su ID externo para la transacción
string
Tipo de transacción: payment, transfer, withdrawal, etc.
string
Estado actual de la transacción: CREATED, PROCESSING, SUSPENDED, SENT, SUCCESSFUL, DECLINED, REFUNDED, EXPIRED
number
Monto de la transacción en la moneda original
string
Código de moneda ISO 4217 (por ejemplo, USD, EUR, MXN)

Payloads Específicos de Eventos

transaction.created

Enviado cuando se registra una nueva transacción en el sistema.
Caso de uso: Active verificaciones de fraude adicionales, actualice saldos de cuenta en tiempo real, o inicie procesos de cumplimiento.

transaction.updated

Enviado cuando se actualiza una transacción existente (por ejemplo, cambio de estado).
Caso de uso: Notifique a clientes sobre el estado de su transacción, actualice dashboards en tiempo real, o active flujos de trabajo post-transacción.

transaction.status_changed

Se envía cuando cambia el estado de una transacción (por ejemplo tras una actualización manual en Monitoreo de transacciones o vía API). El payload es compacto: nuevo y anterior estado más datos identificadores en transaction. Tras el cambio puede reejecutarse el motor de reglas; cuando aplique, rulesExecutionSummary refleja el mismo tipo de resumen que la API de transacciones para esa evaluación.
string
Nuevo estado tras el cambio (p. ej. SUCCESSFUL, DECLINED, REFUNDED).
string
Estado anterior al cambio.
object
Identificadores: id (UUID en Gu1), externalId, type y status actual.
object
Opcional. Presente cuando hay metadatos de evaluación de reglas para esta transición (misma forma conceptual que en respuestas API).
Caso de uso: Automatizar solo sobre transiciones de estado, auditoría o integraciones que requieran un webhook liviano. Prefiera transaction.updated si necesita montos, origen/destino y demás campos en la misma notificación.

Ejemplos de Código

Node.js - Manejo de Eventos de Transacciones

Python - Manejo de Eventos de Transacciones

Mejores Prácticas

El webhook incluye externalId que es el ID que usted proporcionó al crear la transacción. Úselo para buscar la transacción en su base de datos.
Guarde el transactionId de Gu1 en su base de datos. Esto le permite consultar detalles de la transacción más tarde si es necesario.
Puede recibir el mismo webhook múltiples veces. Use el transactionId y el event para garantizar que procese cada evento solo una vez.
Siempre retorne un código de estado 200 lo más rápido posible para confirmar recepción. Procese el webhook asincrónicamente si es necesario.
Siempre verifique el header X-Webhook-Signature para garantizar que el webhook sea auténtico. Vea la guía de seguridad para detalles.

Solución de Problemas

Verificar estos elementos:
  • URL del webhook es públicamente accesible vía HTTPS
  • Webhook está configurado y habilitado en el dashboard
  • Suscrito a los tipos de eventos correctos
  • Endpoint retorna código de estado 200 dentro de 30 segundos
  • Verificar logs del servidor para solicitudes recibidas
  • Los eventos de transacciones están actualmente en desarrollo - confirme que estén activados para su organización
Causas comunes:
  • Usar secret incorrecto (verificar dashboard para secret actual)
  • Verificar firma en JSON parseado en vez de body raw
  • Secret no guardado correctamente después de crear webhook
  • Problemas de codificación (garantizar UTF-8)
Vea la guía de seguridad para implementación adecuada.
Este es un comportamiento normal. Los webhooks pueden enviarse múltiples veces debido a problemas de red, timeouts o reintentos.Siempre implemente idempotencia usando el transactionId y tipo de event del webhook.

Próximos Pasos

Eventos de Entidades

Manejar eventos de ciclo de vida de entidades

Eventos KYC

Procesar actualizaciones de verificación KYC

Seguridad de Webhooks

Asegurar sus endpoints de webhook

Configuración

Configurar ajustes de webhook