#ujwal_webhooks

1 messages ¡ Page 1 of 1 (latest)

noble auroraBOT
#

👋 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/1263140522441183294

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

snow lake
#

Just the first time, subsequent payments will fire other events like payment_intent.succeeded

#

If this is a subscription invoice.paid is a good one to listen to for subsequent payments

cedar spindle
#

I am worried because if it fires again my automation will break. Here is what I am doing

I have created an automation based on the "checkout session completed" event. This automation restricts payments or free trials based on card fingerprint, ensuring users can only enroll in the free trial once. I have assigned subscription IDs to the relevant account in our platform. This is all triggered by the "checkout session completed" event because I also want to capture first name field form the payment link page.

My question is: if we offer a 7-day free trial, will the "checkout session completed" event be triggered again when the card is charged after the trial ends? Or is it only triggered the first time the customer goes to the payment link and enrolls in the free trial? I am using Stripe payment links for accepting payments.

snow lake
#

checkout.session.completed will only be fired when the user submits their payment details to checkout

#

It will never be fired for subsequent payments

#

Actually to be more precise, it will never be fired for subsequent payments on that same subscription. Of course if the user completes a checkout session again the event will fire for that new session/subscription

cedar spindle
#

Yes so it will have new subscription ID attached to it right.

snow lake
#

Correct

cedar spindle
#

Thank you so much. Here is another one.

If a customer's payment method fails after the seven-day free trial, I have set up an automation triggered by the "customer subscription deleted" event. This automation restricts their access to our platform. Is this the correct approach to ensure that users with failed payments cannot access our platform?

snow lake
#

That depends a bit on your account settings and how strict you want to be on that access. Do you know what you have your account's billing settings set to for failed subscription payments?

#

If you have it set to cancel the subscription after your retries fail, then that would be a great way to manage access

cedar spindle
#

What will happen if there payment fails.
Will the customer.subscription.deleted even be fired.

#

Or do we have to set this itself in that settings you mentioned.

snow lake
#

That depends on the settings that I linked to. customer.subscription.deleted is fired when the subscription is cancelled, which can happen automatically when the first payment fails or after a couple of retries based on your settings

#

There is also invoice.payment_failed which will trigger on invoice payment failures regardless of what happens to the subscription. But most users like to use the status of the actual subscription to provision access, so it is more common to use customer.subscription.deleted if you have your settings set to cancel subscriptions at the end of the payment attempts

cedar spindle
#

When the user cancelles it. From the customer portal
Will customer.subscription.deleted be fired at the end of the current period. Right?

#

I mean let say my subscription ends on 25th
I am the customer
And I cancell my subscription from the customer portal today.

So subscription deleted event will be fired on 25th. Right?

snow lake
cedar spindle
#

Okay.
Got that.

One more here.

I want to change the subscription status from free trial to paid on my platform. I am monitoring the customer subscription deletion to restrict their access. Now, I am also monitoring the charge succeeded event to update their status from free trial to paid. When I receive the first charge succeeded event for the same subscription ID, I will change their status. I have automations set up to grant them access to features not available in the free trial once they complete it. Am I taking the right approach by listening to the charge succeeded event?

snow lake
#

That event is fine to listen to but invoice.paid might be a better event to listen to. It will contain more information that is relevant to the subscription

#

Both will fire on each payment from a subscription though so that should be fine

#

Oh or you can listen to customer.subscription.updated and check the subscription's status. Once it is active that means that the subscription is out of trialing and has its latest invoice paid

cedar spindle
#

Okay that sounds great.
Just checking the 'active' thing? .
Will it ensure it is fired when the payment is done at the end of the free trial period.

Can you give more details.
Which field in that packet specifically

Will that ensure they are paid subscribers now?

snow lake
#

Apologies for the delay, basically you can check status on the subscription object and previous_attributes.status on the event. status will be active in that scenario and the previous attribute status will be trialing