#kibbas.
1 messages · Page 1 of 1 (latest)
OK I understand. But in this case, there were two subscriptions that were created. The first setup_intent was taken into account to create the subscription but immediately after a second setup_intent was successful and created a second subscription. I can't understand what's going on?
Is this perhaps linked to a delay? The first setup_intent was created at 10:48 p.m. and was successfully implemented at 11:36 p.m.
have you looked at what your code does? it's really hard for me to say anything here
https://dashboard.stripe.com/logs/req_7JpLxosIHnJqXJ
https://dashboard.stripe.com/logs/req_3YAjHqQLHzhmbE
those are the logs for the API call you made to create a SetupIntent and then create a Subscription later, which are the requests that triggered the two events you asked about, if that helps
I think your question is why did you also call the API 2 seconds after creating that Subscription to create another, identical one (https://dashboard.stripe.com/logs/req_sbxbC2V4JQqweK) , and I don't think I can give any answer beyond: that is what your code did
maybe for example that API call is triggered by a button in your frontend web page, and you haven't done something like set disabled on the button after click and while the subscription is loading, so the use can double-click and it creates another subscription
Yes but I checked that. Even by double clicking this does not create two subscriptions because the subscription is created on the backend side by listening to a "setup_intent.succeeded" webhook. So here we have a setup_intent which was created after the creation of a subscription and this setup_intent was "succeeded" (I don't know how or why because no action on our side was made on our side when we look at the logs of Stripe) which resulted in the creation of a second subscription.
Normally everything works. If you look at all the logs, there is always a subscription created. But in this specific case, I can't understand where this "setup_intent" comes from?
because as I said, a Subscription can create a SetupIntent too, if there is a trial period
if your logic is simply to naively create a Subscription when recieving an event about a SetupIntent then that could be causing the bug! I would try to refine that, for example by adding metadata to the SetupIntents your own code creates and only reacting to those
Ok I can see that that's it but the problem would have been the same everywhere. I mean that almost every new subscription we create has a trial period and there has been no new "setup_intent" initiated.
For example I did a test this morning:
https://dashboard.stripe.com/test/logs?method[0]=post&method[1]=delete&direction[0]=connect_in&direction[1]=self&starting_after=1695368270-req_HSxuD0jppXaqE1
I don't know if you can log all the logs?
well your example is from over a month ago, so maybe it was somthing specific or a problem we had back then, I can't say
not sure what you mean or what delay
I mean that the first "setup_intent" was created by us on 08/12 at 10:48 p.m.:
https://dashboard.stripe.com/events/evt_1NeOjwJZHTBiChJzt7yUsqB6
And it was ok at 11:36 p.m.:
https://dashboard.stripe.com/events/evt_1NePUOJZHTBiChJzPDhxtTZX
I have no way to tell you what happened during that time, maybe the customer had to go find their credit card or charge their phone, or anything else
Afterwards there is another example from another client where everything went well:
https://dashboard.stripe.com/events/evt_1NePgJJZHTBiChJznaJFMLIb
https://dashboard.stripe.com/events/evt_1NePgJJZHTBiChJzkf7300Nf
Here the subscription was only once with a trial period. There was no other setup_intent created by the subscription
Yes, what the client did during this time is not a problem. But that's the only thing that differs from the others.