Legacy events (reference)
Legacy events (reference)
This is the classic per-type webhook format (payment_intent.*, bank_transfer_intent.*, etc.). It keeps working unchanged for existing integrations, but for new integrations use the unified intent.* format. If you already integrated with the classic format, see the Migrate to Unified Webhooks guide.
In the classic format, each payment method emits its own event with a different structure. Your handler has to branch on the event name (event_type) and parse a different shape per type.
Per-type payment events
payment_intent.succeeded
Emitted with a successful card charge (credit or debit). The funds are already in your Recurrente balance.
For in-person payments (POS, mobile POS, and stablecoins), this webhook is sent after the cashier completes the customer data collection step (NIT, phone, email), so that the payload includes the full customer information. This typically adds a few seconds of delay after the payment itself.
Example response:
payment_intent.failed
Failed card charge.
Example response:
bank_transfer_intent.pending
Emitted when a bank transfer charge is initiated. As soon as the money is received in the account, bank_transfer_intent.succeeded will be emitted. Otherwise, bank_transfer_intent.failed will be emitted.
bank_transfer_intent.succeeded
Emitted with a successful bank transfer charge. The funds are already in your Recurrente balance.
bank_transfer_intent.failed
Emitted with a failed bank transfer charge. This happens when the funds are not received in the bank account, or the wrong amount is received.
balance_intent.succeeded
Emitted with a successful charge paid using the customer’s Recurrente balance. The funds are already in your Recurrente balance. This event is delivered to the merchant account (the account that received the payment).
balance_intent.paid
Emitted to the payer account (the account whose balance was debited) when it successfully pays a checkout using its Recurrente balance. You only receive it if the payer account has a webhook endpoint configured.
Note: a single balance-paid charge triggers two independent webhook deliveries: balance_intent.succeeded to the merchant and balance_intent.paid to the payer. The payload follows the same shape as bank_transfer_intent.succeeded (includes checkout, payment, customer, amount_in_cents, currency, product, tax_invoice_url).
Subscription events
subscription.create
If the product is recurring, this event is emitted in addition to payment.succeeded with the subscription information.
Example response:
subscription.past_due
Emitted when a subscription’s automatic charge fails for the first time.
Note: In a subscription, when a payment fails, Recurrente attempts to charge it again 3 and 5 days later. If both retry attempts fail, the subscription is canceled at that time.
subscription.pause
Emitted when a subscription is paused. A paused subscription will not be charged again until it is reactivated.
subscription.cancel
Emitted when a subscription’s automatic charge fails for the third time.
Note: In a subscription, when a payment fails, Recurrente attempts to charge it again 3 and 5 days later. If both retry attempts fail, the subscription is canceled at that time.
Other events
setup_intent.succeeded
Emitted when a subscription with a trial period is successfully initiated. Also emitted when a card is tokenized without charging it.
setup_intent.cancelled
Emitted when a card cannot be tokenized without charging it. This happens when the first payment of a subscription with a trial period fails.

