Skip to main content

apps.finances.webhooks

activate_free_plan_on_subscription_deletion​

@webhooks.handler('subscription_schedule.canceled')
def activate_free_plan_on_subscription_deletion(event: djstripe_models.Event)

It is not possible to reactivate a canceled subscription with a different plan so we

create a new subscription schedule on a free plan

Arguments:

  • event:

capture_release_schedule​

@webhooks.handler('subscription_schedule.released')
def capture_release_schedule(event: djstripe_models.Event)

Since we mostly operate on subscription schedules, in case the subscription is released by whatever reason

we want to assign it to a schedule again

Arguments:

  • event:

update_subscription_default_payment_method​

@webhooks.handler('payment_method.attached')
def update_subscription_default_payment_method(event: djstripe_models.Event)

Remove this webhook if you don't want the newest payment method

to be a default one for the subscription. The best alternative approach would most likely be to create a custom API endpoint that sets a default payment method on demand called right after the web app succeeds setup intent confirmation.

Arguments:

  • event:

send_email_on_subscription_payment_failure​

@webhooks.handler('invoice.payment_failed', 'invoice.payment_action_required')
def send_email_on_subscription_payment_failure(event: djstripe_models.Event)

This is an example of a handler that sends an email to a customer after a recurring payment fails

Arguments:

  • event:

charge_refund_updated​

@webhooks.handler('charge.refund.updated')
def charge_refund_updated(event: djstripe_models.Event)

There is a case when a charge succeeds but refunding a captured charge fails asynchronously with a failure_reason

of expired_or_canceled_card. Because refund failures are asynchronous, the refund will appear to be successful at first and will only have the failed status on subsequent fetches.

Arguments:

  • event: