#nadir_68619
desert quarry
fathom shell
Hello! It should not be taking anywhere near that long. Do you have a Subscription ID I can take a look at where you saw that delay?
desert tartan
Okay, let me find and add it here
sub_109pq5B6I2WP4bpyqzCZmb6o
you can see, checkout completed at 3:01 and subscription created at 3:03. Sometimes this number go to event 5 minutes
fathom shell
According to that screenshot the Subscription was created at the same time the Checkout Session completed. The third Event down is when the Subscription was created.
I'm having trouble opening that Subscription, can you give me another ID related to it? One of the Event IDs, the Customer ID, an Invoice ID, something like that?
desert tartan
sub_1O9pq5B6I2WP4bpyqzCZmb6o
copied from dashboard now. maybe have done some type on previous. please check this one
fathom shell
Yeah, the Subscription was created ~instantly as expected when the Checkout Session completed. Look at the times of these two Events:
https://dashboard.stripe.com/events/evt_1O9pq9B6I2WP4bpyeAzSi8Xy
https://dashboard.stripe.com/events/evt_1O9pq7B6I2WP4bpy8cYonwTh
There was a separate request to update the Subscription made by your server a couple minutes later though: https://dashboard.stripe.com/logs/req_MSsqqirIup6P0S
desert tartan
evt_1O9psgB6I2WP4bpyaDRt1sCY
fathom shell
That triggered an update Event, which is the top one highlighted in your screenshot: https://dashboard.stripe.com/events/evt_1O9psgB6I2WP4bpyaDRt1sCY
desert tartan
event id for the one which latency happens
fathom shell
But there was no delay on Stripe's side; we only did what your server told us to do when you told us to do it.
desert tartan
Yes, top one is the one which latency happens
fathom shell
Not sure I understand.
You made this request at 14:03:50 UTC to update the Subscription: https://dashboard.stripe.com/logs/req_MSsqqirIup6P0S
The customer.subscription.updated Event fired at the same time, 14:03:50 UTC: https://dashboard.stripe.com/events/evt_1O9psgB6I2WP4bpyaDRt1sCY
There is no delay.
Does that make sense? Can you explain in more detail where you're seeing the latency?
desert tartan
Right now, webhook send subscription created event at 14:03 after all process finished. But as you said, subscription created at 14:01. For what it was witing from 14:01 to 14:03?
fathom shell
Let's back up a bit. Why does this delay matter?
It seems like your server is configured to listen for either customer.subscription.created or checkout.session.completed and is then updating the new Subscription. It takes time for the Event to be delivered to your server and for your server to process and act on it. Is that the delay you're asking about?
desert tartan
We send your to the dashboard after the subscription created. And we know this via webhook from stripe.
customer.subscription.created
yes
After whole process finishes, we got customer.subscription.created event and process
fathom shell
Right, but what's the actual problem?
What is happening now that you don't want to happen?
fathom shell
Your server is waiting for the webhook before allowing the UI to proceed? You should not be doing that.
You should instead put {CHECKOUT_SESSION_ID} in your success_url and then key off that to make the update faster.
Have a look here: https://stripe.com/docs/payments/checkout/custom-success-page
desert tartan
We are doing process over the user on the backend, therefore we are using webhook.
Therefore needs to eliminate the latency
fathom shell
You should not be waiting for a webhook before advancing the UI.
Did you look at the doc I linked to above? That explains how you can do this without waiting for the webhook.
You add {CHECKOUT_SESSION_ID} to your success_url.
Then when your customer lands on your success URL the {CHECKOUT_SESSION_ID} placeholder will be replaced with the Checkout Session ID.
Your server can retrieve the Checkout Session using that ID to confirm they paid. You can then instantly update the Subscription, and then render the success page or redirect where you want.
No webhooks involved.
To be clear, you should still use webhooks, because some people might pay and then drop off before they land on your success_url, so you need both approaches.
But whichever happens first should "win".
And in most cases that will be the success_url triggering the update.
Does that make sense?
desert tartan
Right now, latency is happening while updating the subscription. Why is it updated?
And how am I supposed to update it?
fathom shell
Latency is happening because you're waiting for webhooks. You should be using the approach described above to agument your existing webhooks-only approach.
desert tartan
Okay. Will discuss this with the team. Thanks for your reply and time