#bill92_webhooks
flat islandBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1308277094337351801
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- bill92_webhooks, 42 minutes ago, 5 messages
- bill92_webhooks, 3 days ago, 25 messages
- bill_subscription-trial, 4 days ago, 20 messages
- bill92_webhooks, 6 days ago, 15 messages
cinder forge
I have this logic setup on my customer.subscription.updated webhook
if (
stripeEvent.data.object.cancel_at_period_end &&
stripeEvent.data.object.cancel_at &&
stripeEvent.data.object.canceled_at &&
stripeEvent.data.object.cancellation_details?.reason === 'cancellation_requested'
) {
// send email with postmark letting know that their subscription will cancel at the end of the period
}
if (
!stripeEvent.data.object.cancel_at_period_end &&
!stripeEvent.data.object.cancel_at &&
!stripeEvent.data.object.canceled_at &&
!stripeEvent.data.object.cancellation_details?.reason
) {
// send email with postmark letting the user know that the subscription won't be canceled
}
If the subscription is set to cancel at the end of the trial cancel_at_period_end =true, when adding a payment method the subscription reactivates and the email will be sent, which is not the logic I'm expecting
is there a way to narrow such action?
cobalt saffron
can you share the subscription id?
cinder forge
subscription id [test mode]: sub_1QMi7VH31YJndMKO3PgnCCsl
cobalt saffron
it's likely because of this setting when you create the subscription
end_behavior: {
missing_payment_method: "cancel",
},
},```hmmm, gimme a while to think about this
cinder forge
The customer.subscription.updated event is triggered on multiple updates, naturally I want to effectively send an email when the cancel_at_period_end changes from true to false and vice versa, without sending emails on irrelevant updates (for example, switch from a monthly plan to a yearly plan)
maybe use the previous_attributes?
cobalt saffron
yes, you should refer to the previous_attributes
cinder forge
🤔
cobalt saffron
hmmmm, the subscription that you shared doesn't have cancel_at_period_end=true from what I'm seeing
cinder forge
yeah, I'm toggling it by canceling and resuming the subscription on the customer portal
cobalt saffron
i'm not sure i understand
If the subscription is set to cancel at the end of the trial cancel_at_period_end =true, when adding a payment method the subscription reactivates and the email will be sent, which is not the logic I'm expecting
is this referring to your own logic? that when you add a payment method, your own system sends an email?
cinder forge
The customer.subscription.updated webhook will be triggered if I add a payment method through the customer portal to a subscription that currently has no payment method and is set to cancel at the end of the period, correct?
cobalt saffron
probably yes, i haven't tested it out
cobalt saffron
I think if you're worried about sending emails when you shouldn't, one thing to keep in mind is that webhooks may not be sent in order. So really, what you can do is again, to save the cancel_at_period_end in your DB, then everytime you receive a webhook, retrieve the subscription object to get the latest details, update your DB and perform any action if required
cinder forge
order doesn't matter for this
this worked
if (
!previousAttributes?.cancel_at_period_end &&
stripeEvent.data.object.cancel_at_period_end &&
!previousAttributes?.cancel_at &&
stripeEvent.data.object.cancel_at
) {
// send cancelation email
}
if (
previousAttributes?.cancel_at_period_end &&
!stripeEvent.data.object.cancel_at_period_end
) {
// send reactivation email
}
Since the customer.subscription.updated webhook event is fired on multiple changes and I quote the stripe documentation "Sent when a subscription starts or changes. For example, renewing a subscription, adding a coupon, applying a discount, adding an invoice item, and changing plans all trigger this event."
I only wanted to send the email when the cancel_at_period_end changes
I hope that makes more sense
cobalt saffron
do you tell the customer specifically what the cancel_at_period_end changed to?
because if you do, then if you receive the webhooks out of sequence, it would affect what the customer receives
For example customer toggles false -> true (webhook A), true -> false (webhook B)
However, you receive webhook B first, then webhook A, then the customer won't be notified correctly
cinder forge
yes
for cancelation cancel_at_period_end: true
"Hey, your subscription has been canceled, you can use it until 18 December 2024"
for reactivation cancel_at_period_end: false
"Hey, your subscription has been reactivated"
I hear you, but I don't think the user will cancel/reactivate that much, it doesn't make sense, you know..?
cobalt saffron
okay, it's fair, and you can always update your logic if you do see it happening
cinder forge
yeah, at the end of the day , these are just informative emails
using previous_attributes helped me to target this scenario perfectly... (i hope)
thanks for the help
cobalt saffron
you're welcome! 🍻
cobalt saffron
sorry, repost what specifically?