Does subscription renewal failed webhook mean the subscription is cancelled?

The Monetization webhooks differentiate between app_subscription_renewal_attempt_failed and app_subscription_renewal_failed. Does the app_subscription_renewal_failed webhook mean that the subscription is cancelled altogether? Or will there be other attempts to charge the customer for renewal?

Hi @samicaracand,

Here’s what I can confirm:

The app_subscription_renewal_attempt_failed webhook means that the first renewal attempt failed. The app_subscription_renewal_failed means that the last renewal attempt failed. Any payment attempts in between the two would not trigger a webhook.

Still waiting for some clarification from the team as the webhooks have been updated recently. I will update this thread and the docs when I have more info.

Thanks for bringing this up!


1 Like

Thanks, Rachel!
The crux of the matter is whether there will be any further attempts to charge for renewal after the app_subscription_renewal_failed event. If no further attempts, then we need to downgrade the account on our app.

1 Like

Hello @samicaracand,

I can confirm that after the app_subscription_renewal_failed event event, there are no further attempts.


1 Like

I’m not sure about this.
I see a new attempt after 30 days.
If the renewal does not succeed after 45 days, the subscription is automatically cancelled and a app_subscription_cancelled webhook is sent.

Hello @rob I will check that again with the team. They mentioned there is no other attempt, but I will share what you said with them and let you know what they say.



Hello again @rob,

I heard back from the team.

After the app_subscription_renewal_failed webhook, we retry the payment 10 times (every 4 days).

On the 1st failed attempt we send the app_subscription_renewal_attempt_failed event.

On the 2-9 we don’t send any events.

On the 10th (and final) failed attempt we send the app_subscription_renewal_failed attempt.

Thanks, @Matias.Monday
This begs more clarification :slight_smile:

My understanding of your explanation:

  • First failure to renew: app_subscription_renewal_failed
  • Second failure to renew: app_subscription_renewal_attempt_failed (you referred to this as the ‘1st failed attempt’, although it seems to be the second one.)
  • Failures #3 to 10 (what you refer to as 2-9): no events
  • Failure #11 (“10th” in your message): app_subscription_renewal_failed

To be honest it’s a bit confusing. From an app developer perspective, the most important event I need to capture is when to deactivate the customer’s subscription altogether. I can’t easily use app_subscription_renewal_failed because this seems to occur twice, unless we keep counting and we assume that you won’t change that in the future, for example, by sending this event only if the last attempt fails. This is not an ideal situation.

Perhaps the final failed attempt should trigger an unambiguous event, say app_subscription_cancelled. This leaves no room for guessing that we should deactivate the user’s subscription.

I suspect we probably have a number of accounts that failed renewing a long time ago but that we are still serving as paying customers because of this confusion.

1 Like

I agree with you @samicaracand.
The situation is far from ideal.

This is why, at least for the integrations, I always check for a possible mismatch between the plan we have stored in our database and the subscription object sent in the payload.

@Matias.Monday In addition there are still two gray zones.

After the last attempt (40 days), there are 5 additional days in which the attempts are not performed and the subscription is still valid.
Only after 45 days, we get the plan cancellation notification and the subscription is reverted to the default (free/trial) plan.

If the user uninstall the app, no more notifications are sent. You could remain with one single attempt failed and no other notifications.
Only after 45 days, you can be sure the subscription is cancelled (with no notifications from monday).

A flow diagram in documentation of all the scenarios would be an excellent step to clear up any confusion.

@Matias.Monday Any feedback from you?

Hi @dvdsmpsn, @rob, @samicaracand (and anyone else reading this) -

Apologies for the delayed response. We’ve been trying to coordinate with a few different teams to clarify everything, and it has taken longer than normal with the holidays.

We’re working on adding things to the documentation to make it clearer, but in the meantime, we’ve created this timeline that hopefully will help clear things up!



Thanks @rachelatmonday, this is really helpful.

Do you know what might cause a renewal failure and what messaging sends to customers for this?

Is it just that a customer’s credit card is expired or are there other reasons as well? Does let customers know via email to alert them of this issue?



1 Like

Hello there @PluginGenie,

There are multiple possible reasons for this.

  • Not enough funds on CC
  • Bank rejected the operation
  • The CC expired
  • The CC is disabled (e.g. stolen)
  • Our payment provider marked transaction as fraud

I created a request based on your feedback to start sending an email to the users when this happens :grin:

Let me know if you have any other questions!


1 Like

Hi Rachel.
That timeline is not really correct.
Here’s an example of recent webhook events I’ve received from a customer.

There are no app_subscription_renewal_attempt_failure (note failure) or app_subscription_renewal_failed (note missing attempt) events.
Only app_subscription_renewal_attempt_failed events (basically a mix from the events above).
A first app_subscription_renewal_attempt_failed sent at renewal, a second one sent after 30 days and a third one sent after 5 days.

@Matias.Monday Thanks for the great explanation and for creating a request to send an email to users when that happens!

@Matias.Monday @rachelatmonday I think I am more confused than I was when I started the thread…
Subscriptions are what drives monetization and we need to discuss it from a business flow perspective then translate it into when the webhooks should (and shouldn’t) fire (and hopefully some more descriptive webhook event names.)

Perhaps a Zoom discussion with app developers and your team to discuss this?

1 Like

Hello everyone,

We are discussing next steps to make all of this more clear to everyone. I will update you as soon as we have news!

@rob can you please share the account ID of the account of that screenshot and your app ID?

Please mention me when you do! You can send it via form if you prefer to.


Account ID: 3734160
App ID: 8031


Thank you @rob !

I will come back to you all when I have an update!

1 Like