#zacked

1 messages ยท Page 1 of 1 (latest)

full spadeBOT
whole stag
#

Hello ๐Ÿ‘‹

When a user tries to pay on our web-app for the first time, before creating a checkout session we check to see if the customer for that user exists in Stripe, if not we create a customer via the Stripe API and then generate a Checkout Session for them. Is this the right approach?
Yup, that sounds about right.

The stripe docs suggest that we should initiate a new checkout session every time the customer tries to pay & that is fine but lets say the customer abandons checkout sessions 3 times before finally paying/completing the 4th checkout session

Should we keep a track of Checkout sessions in our database to cancel/invalidate previous checkout sessions for that customer before creating a new one OR should we just redirect them to an old open session?
It depends on your use-case, if you want to redirect them to an old one then its fine, you don't have to ๐Ÿ™‚

Is there even any need to close old sessions if we are setting them to be pretty short-lived (30 mins)
Don't really need to cancel if they auto-expire ๐Ÿ™‚

knotty obsidian
#

Okay, great. Thank you for your quick reply.

So it's perfectly fine if we want to store all checkout sessions in DB and it's also perfectly fine if we don't store them?

Because at the end of the day, we don't want to over engineer the app.

whole stag
#

Right, you don't necessarily need to store the checkout sessions as it is possible that by the time user decides to actually make the purchase, the previous session might have expired (let's say after 35 minutes of the initial creation)

knotty obsidian
#

Great, thanks for the help

whole stag
#

NP! ๐Ÿ™‚ Happy to help