Billing Events
Checkout
checkout.created
checkout.updated
checkout.expired
Fired when a checkout link has expired without being completed.
Customers
customer.created
Fired when a new customer has been created.
customer.updated
Fired when a customer has been updated.
customer.deleted
Fired when a customer has been deleted.
customer.state_changed
Fired when a customer’s state has changed. Includes active subscriptions and
granted benefits.
Subscriptions
In order to properly implement logic for handling subscriptions, you should look into the following events.subscription.created
Fired when a new subscription has been created.
subscription.active
subscription.uncanceled
subscription.cycled
Fired when a subscription enters a new billing period, before the renewal order exists and whether or not the payment succeeds.
subscription.canceled
subscription.past_due
Fired when a subscription payment has failed. The customer can recover by updating their payment method.
subscription.updated
Use this event if you want to handle cancellations, un-cancellations, etc. The
updated event is a catch-all event for
subscription.active,
subscription.canceled, subscription.uncanceled, subscription.cycled,
subscription.past_due, subscription.revoked, subscription.paused and
subscription.resumed.order.created
Carries a
billing_reason field, which can be purchase,
subscription_create, subscription_cycle and subscription_update. To act
on a renewal, listen to subscription.cycled instead: it fires whether or not
the renewal payment succeeds.subscription.revoked
subscription.paused
Fired when a scheduled pause takes effect at the end of the period. Billing stops and benefits are revoked until the subscription resumes.
subscription.resumed
Fired when a paused subscription resumes. A new billing period starts and the customer is charged immediately.
Cancellation Sequences
When a subscription is canceled, the events triggered depend on whether the cancellation is immediate or scheduled for the end of the billing period. End-of-Period Cancellation (default) When a subscription is canceled (by customer action from the portal or by the merchant from the dashboard/API), the following events are sent immediately:subscription.updatedsubscription.canceled
active status, but the cancel_at_period_end flag will be set to true.
When the end of the current billing period arrives, the subscription is definitively revoked: billing cycles stop and benefits are revoked. The following events are then sent:
subscription.updatedsubscription.revoked
canceled status.
Immediate Revocation
When a merchant cancels a subscription with immediate revocation, those events are sent at once:
subscription.updatedsubscription.canceledsubscription.revoked
canceled status immediately.
Renewal Sequences
When a subscription is renewed for a new cycle, the webhook events are triggered in a specific sequence to help you track the renewal process and handle billing logic appropriately. Initial Renewal Events When a subscription reaches its renewal date, the following events are sent immediately (if enabled on the webhook):subscription.cycledsubscription.updatedorder.created
subscription.cycled fires only on a new billing period, so you can act on a renewal without inspecting billing_reason on the order. It also fires when a trial converts to a paid subscription, since that starts a period too: read status to tell the two apart.
The subscription data will reflect the new billing period through the current_period_start and current_period_end properties, showing the updated cycle dates.
The order data represents the new invoice for the upcoming cycle, with a total representing what the customer will pay for this new period. If usage-based billing is involved, their consumption for the past period will be included in the total. The status of this order is pending at this stage.
Payment Processing Events
Shortly after the initial renewal events, the platform will trigger a payment for the new order. Once the payment is successfully processed, the following events are sent:
order.updatedorder.paid
paid.
Pause Sequences
Pausing is scheduled for the end of the current billing period, much like an end-of-period cancellation. When a subscription is paused (by customer action from the portal or by the merchant from the dashboard/API), only one event is sent immediately, because the subscription staysactive until the period ends:
subscription.updated
pause_at_period_end flag is set to true, and resumes_at holds the scheduled resume date if you set one.
When the end of the current billing period arrives, the pause takes effect: billing stops and benefits are revoked. The following events are then sent:
subscription.updatedsubscription.paused
paused status.
Resume
When a paused subscription resumes, either immediately when you resume it or automatically on its resumes_at date, a new billing period starts and the customer is charged right away. The following events are sent:
subscription.updatedsubscription.resumedorder.created
current_period_start and current_period_end, and the order represents the immediate charge for the new cycle.

