#avj_pricingtable-customersession

1 messages · Page 1 of 1 (latest)

desert thunderBOT
#

👋 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/1466494496739950615

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

deep needle
#

Hi 👋

Do you have an example Checkout Session ID where you observed the unexpected behavior?

heavy hemlock
#

not right now, I can create one but since I have to wait for the timeout it'll be a while

deep needle
#

You should be able to find these in your developer logs for the account. The expiration of the checkout session will fire a checkout.session.expired webhook event that you should be able to search for

#

that way you don't have to re-create one and wait

desert thunderBOT
heavy hemlock
#

I've got lots of those, not sure which one would have a completed checkout after that

wide cargo
#

@heavy hemlock this sounds like a bug to me, we should either refresh the CustomerSession or error at that point in my opinion but I can see why someone would have made a different design decision
I recommend flagging this to our support team directly so they can investigate further and look into a potential fix with the product team.
You can contact them at https://support.stripe.com/contact and feel free to mention you talked to us on Discord.
We'll also try to reproduce on our end but it's slow going since it requires waiting 30+ minutes

#

avj_pricingtable-customersession

heavy hemlock
#

I've got a session open, waiting for the expiration

wide cargo
#

yeah I still think reaching out to support is the right next path, we won't give you a fix here, only get ids and then recomend reaching out to the product team

heavy hemlock
#

yeah, it's documented so it seems on purpose, I just can't figure out how to recover from it when it happens

wide cargo
#

gotcha, what do you mean by "recover"?
Like the only thing I think you can do is add complex JS logic to count 30min and hide the div/UI at that point
IMO this is a design mistake and I feel like I talked about it with that team before (but I'll push again now that I found the real docs). But I'm going to hear that it's by design

heavy hemlock
#

so we've got two timeouts, if we just site at the pricing table for 30 minutes, then hitting subscribe errors out, and that's fine. If they hit subscribe then wait 30 minutes to complete the checkout, we get a customer with an attached payment method that isn't the customer we told it to attach to

#

we can cancel the subscription and recreate it on the correct customer, even give them credit for the amount they paid, but I haven't found a way to get the payment method attached to the correct customer

wide cargo
#

the doc says

If the customer session expires after Checkout Session creation, but before confirmation, payment confirmation fails.
to me that means that if you load PricingTable, go straight to Checkout, wait 30 minutes and then complete the payment it should error first.
Which to be clear is horrible design in my eyes, so I don't get why.
But you are saying it doesn't even error and loses the Customer after you are already on Checkout (and in theory by now it should know which Customer object to use)?

heavy hemlock
#

yeah, it completes the checkout successfully and just creates a new customer to attach the subscription and payment method to

#

I'm on the screen now waiting for the timeout, I should have some ids for you after that

wide cargo
#

But really this is for support so they can follow up straight with the product team, there's nothing really I will be able to do here unfortunately

wide cargo
#

@heavy hemlock since we still have the thread, did you get that Checkout Session id?

heavy hemlock
#

I just completed my checkout but I never saw an expired event so not sure I waited long enough

wide cargo
#

What kind of expired event were you expecting? A CheckoutSession expires after 24 hours by default.
The way you framed the bug it's that it works totally fine but it "dropped" the Customer associated with the original CustomerSession right?

heavy hemlock
#

yeah, not sure if I have to leave the page open all day. I'll try that and complete the checkout tomorrow, then submit it to support with the info

wide cargo
#

Sounds good, sorry for the extra hassle but I'll also flag internally since what we document doesn't match what you experience and I like neither of the solutions :p