Eventos legacy (referencia)
Eventos legacy (referencia)
Este es el formato clásico por tipo de los webhooks (payment_intent.*, bank_transfer_intent.*, etc.). Sigue funcionando sin cambios para integraciones existentes, pero para integraciones nuevas usá el formato unificado intent.*. Si ya integraste con el formato clásico, mirá la guía Migrar a Webhooks Unificados.
En el formato clásico, cada método de pago emite su propio evento con una estructura distinta. Tu handler tiene que ramificar por el nombre del evento (event_type) y parsear una forma diferente por tipo.
Eventos de pago por tipo
payment_intent.succeeded
Se emite con un cobro exitoso con tarjeta (crédito o débito). Los fondos ya están en tu balance de Recurrente.
Para pagos presenciales (POS, mobile POS y stablecoins), este webhook se envía después de que el cajero completa el paso de captura de datos del cliente (NIT, teléfono, email), para que el payload incluya la información completa del cliente. Esto suele agregar unos segundos de delay después del pago.
Ejemplo de respuesta:
payment_intent.failed
Cobro fallido con tarjeta.
Ejemplo de respuesta:
bank_transfer_intent.pending
Se emite cuando se inicia un cobro con transferencia bancaria. En cuanto se reciba el dinero en la cuenta, se emitirá bank_transfer_intent.succeeded. De lo contrario, se emitirá bank_transfer_intent.failed.
bank_transfer_intent.succeeded
Se emite con un cobro exitoso con transferencia bancaria. Los fondos ya están en tu balance de Recurrente.
bank_transfer_intent.failed
Se emite con un cobro fallido con transferencia bancaria. Esto sucede cuando no se reciben los fondos en la cuenta de banco, o se recibe el monto incorrecto.
balance_intent.succeeded
Se emite con un cobro exitoso pagado con el balance de Recurrente del cliente. Los fondos ya están en tu balance. Este evento llega a la cuenta del comercio (la que cobró).
balance_intent.paid
Se emite a la cuenta del pagador (la cuenta cuyo balance fue debitado) cuando paga exitosamente un checkout usando su balance de Recurrente. Solo lo recibes si configuraste un endpoint de webhook en la cuenta pagadora.
Nota: un mismo cobro con balance dispara dos webhooks independientes: balance_intent.succeeded al comercio y balance_intent.paid al pagador. El payload sigue la misma estructura que bank_transfer_intent.succeeded (incluye checkout, payment, customer, amount_in_cents, currency, product, tax_invoice_url).
Eventos de suscripción
subscription.create
Si el producto es recurrente, se emite además del payment.succeeded este evento con la información de la suscripción.
Ejemplo de respuesta:
subscription.past_due
Se emite cuando el cobro automático de una suscripción falla por primera vez.
Nota: En una suscripción, cuando un pago falla, Recurrente intenta cobrarlo de nuevo 3 y 5 días después. Si ambos re-intentos son fallidos, en ese momento se cancela la suscripción.
subscription.paused
Se emite cuando se pausa la suscripción. Una suscripción pausada no se volverá a cobrar hasta que sea reactivada.
subscription.cancel
Se emite cuando el cobro automático de una suscripción falla por tercera vez.
Nota: En una suscripción, cuando un pago falla, Recurrente intenta cobrarlo de nuevo 3 y 5 días después. Si ambos re-intentos son fallidos, en ese momento se cancela la suscripción.
Otros eventos
setup_intent.succeeded
Se emite cuando se inicia exitosamente una suscripción con un período de prueba. También se emite cuando se tokeniza una tarjeta sin cobrarla.
setup_intent.cancelled
Se emite cuando no se logra tokenizar una tarjeta sin cobrarla. Esto sucede cuando el primer pago de una suscripción con período de prueba, falla.

