#ian-wilson_code

1 messages ยท Page 1 of 1 (latest)

dire patioBOT
#

๐Ÿ‘‹ 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/1349050905538072596

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

hushed shoal
fallow trench
#

If I were to create a checkout session and collect shipping and billing information but then the customer decides to shop more and come back to checkout that information would be lost, as I understand it, because I have not saved the CheckoutSession's id.

#

I'm not sure if that approach is taken here to simplify the example or if it is intentionally meant to be not done that way.

hushed shoal
fallow trench
#

That is also a point of confusion because as I understand it I can update it via the stripe.js API on the frontend but not with the Python API.

#

Maybe I misunderstand what these objects are, but this CheckoutSession is the same as the Python API right but just accessible via the client-side?

#

So server-side, create a CheckoutSession, pass it to the client-side to initCheckout() and get the session there again and I can updateShipping() and updateBilling() there before calling confirm().

#

So if the cart did change I could potentially access the prior checkout session and clone out those elements and start over again mostly where they left off. I just have been having a hard time figuring out what is the "blessed" strategy to use this flow.

hushed shoal
#

You could do that I suppose, yes - or you could maybe consider collecting that during a separate step and storing it in the interim.

fallow trench
#

Well it would be convenient to store the CheckoutSession's id because then I don't have to recreate the CheckoutSession on my side. Anything extra I need can be stuffed in the metadata. But no example ever stores the id which makes me think I'm doing something wrong.

#

By re-create I mean I don't have to store the shipping/email/billing addresses/shipping options independently.

hushed shoal
#

I don't think you can pre-fill the addresses when creating a CheckoutSession though? ๐Ÿค”

fallow trench
#

I'd have to do it via the client-side api but getting it out of the prior checkout session is also not easy and must be done ... via the client-side api. Using the CheckoutSession's metadata until the customer actually clicks Pay would almost be easier. Seems to kind of defeat the purpose though. I guess I'll keep thinking about it.

hushed shoal
#

I wouldn't put addresses, etc in metadata as that's personally identifiable information.

Do you have some kind of 'cart' that you keep track of on your end?

dire patioBOT
fallow trench
#

I currently have a Cart, stored by id ina server-side session and when you start a checkout I create a Checkout, I was re-populating it from the last checkout for that cart based on time but I was hoping to stop doing that.

hushed shoal
#

Ok fair. My experience on the internet is that, unless I've got a stored 'profile' on that site, I expect to be asked for my address(es) more than once.

Do you create Customers too?

rose mason
#

fyi i'm taking over for timebox on this thread

hushed shoal
#

โœŒ

fallow trench
#

Okay thanks for your help @hushed shoal I was optionally creating customers but I've dropped that.

rose mason
#

catching up on this thread now but there's quite a bit going on in the discord so it might be a little bit...

#

sounds like the core question is still just "is it a bad idea to save and re-use the session id" right?

fallow trench
#

That is essentially the question but after discussing the difficulties of getting data out of or into the CheckoutSession maybe it makes more sense to just use CheckoutSession at the last possible moment via the PaymentElement.

rose mason
#

yeah, for the most part the only things we really expect to be updated on the checkout session are things the customer can change themselves in the UI

fallow trench
rose mason
#

i would say saving the session and reusing it is useful for things like cart recovery, but i don't think i would recommend it as a general purpose store of data to be updated and re-accessed frequently

fallow trench
#

Yeah I figured that would be a mis-use. Alright well I'm going to try this approach and see if it works. Thanks for your help.

rose mason
#

yep, good luck! and feel free to come back if you need anything else. i'm going to close this thread but you're welcome to open a new one if you need more support.