#mangle8582
1 messages · Page 1 of 1 (latest)
Hello! We'll be with you shortly. 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.
- mangle8582, 22 hours ago, 38 messages
- mangle8582, 3 days ago, 94 messages
- mangle8582, 6 days ago, 2 messages
In our previous thread you said you wanted to prevent duplicate checkout sessions
That's why we went with an idempotency key
You used an idempotency key, so that's why session says expired
user already checked out
Yea, if you have 5 tabs opened in browser with 5 generated session checkout pages. I wanted to avoid creating more subscriptions if you buy from each tab
But now if i already bought a subscription and then i've canceled it
And want to buy it again
It won't work
Maybe the user will have no money on account and will not have the subscription anymore and he wants to buy back the subscription.
When i did the custom implementation i was checking on backend if already had a subscription and was sending 400.
But stripe doens't check if the same subscription exists to throw error on that checkout session page?
Then use a different idempotency key after subscription cancellation
hmm.. yea, i can generate a new uuid on customer.subscription.deleted for that user
It would be nice to have a setting like this. And not related to checkout page if you reenter on the link, but checking if you already have one subscription when doing the payment in the ckecout page and throw error.
Yea but if you already have 5 tabs this doens't work. It works if you have the subscription already and go on the generated session link and it redirects you to Customer Portal to manage your existing subscriptions
Right
Idempotency key is the way to manage this if it's a requirement
A bit unrealistic that there would be a customer with 5 checkout tabs open tho haha
Should i manage a idempotency key generation on payment failed as well? or other webhooks?
What do you mean
yea true :)) wanted to get rid of this use case
Can you be more specific. What's the issue?
Sure
Now on customer.subscription.deleted i can generate another idempotency key.
But was thinking on other use cases.
I believe there are not right? If payment is failed you remain in the checkout page?
If you are on checkout page and electricity goes down, you can log back and generate another session with the same idempotency key.
The link is expired only after you already paid.
Yeah if payemnt fails customer will still be on checkout page
Yeah will be expired only if customer has paid
No problem
@harsh ice I'm around now, let me know if you have qs or I can archive this thread
what do you mean by qs?