#eoghanobrien
clear sigil
Hello! Can you share an example Checkout Session ID with me that's having issues?
fluid glen
Would looking at the activity on this payment help: pi_3MwU3gE3c9sWyeru0c74Cm5K
clear sigil
Yup that works!
Can you clarify what you mean by "the Checkouts are not coming back as complete"? Are you checking for a specific webhook event? Are you retrieving the CHeckout Session?
fluid glen
We're retrieving the session
Then we check if the status is complete as verification that the checkout will complete
clear sigil
At what point are you retrieving the session?
fluid glen
when the customer is redirected back to our site
we don't check payment_status just status - is that a problem?
I guess we could just not check for a status and assume payment has completed
We'd have to send out a failed payment email manually upon checking the webhook I would assume
clear sigil
Give me a second - I'm just looking for a specific request on my end to confirm something
fluid glen
Thank you! Btw, these are most often related to WeChat
We have had some card related issues too actually
clear sigil
Ah I was just about to ask 🙂
fluid glen
What are you thinking it might be?
clear sigil
So this should definitely not be happening - is this something that just recently started happening for you?
fluid glen
Yes, started April 6
clear sigil
Let me repro and flag to some folks internally
fluid glen
Okay, thank you! Let me know if you need anything from me
clear sigil
Do you happen to have an example of this happening with a card payment? (no worries if not)
fluid glen
I think I do
well, the effect is the same but I don't know if it's exactly the same: pi_3MwpEkE3c9sWyeru093rW8oE
Maybe this one too: pi_3Mwpy6E3c9sWyeru0fjtXe1R
clear sigil
Is this something you've been able to reproduce reliably or in test mode?
fluid glen
At the moment, we're only clued into this happening through logs - we throw an error when the status is not complete at this point since we only expect synchronous payments through this code branch
clear sigil
For pi_3MwpEkE3c9sWyeru093rW8oE I'm not actually seeing any request to retrieve the associated PaymentIntent in that case
fluid glen
Ah okay, that was a long shot
@clear sigil Just curious, is this something you think we'll need a coding change for or is this resolvable on the Stripe side?
clear sigil
It depends on what we find - (still looking)
fluid glen
thank you, i'll stay around here
neat ridgeBOT
clear sigil
When you retrieved the Checkout Session what status did it have? Was it open? Also if you know what payment_status was when you retrieved it as well that would be helpful
fluid glen
I don't have it, sorry
I can log some of that for future requests though, anything else that would be helpful?
clear sigil
No worries - I'm able to reproduce it on my end now so I've got an answer there
fluid glen
okay, that's great progress, thank you for your time on this
Is this something I can change on my end, I can get started on a change quickly if there's something I can do to remediate especially if it's going to help with future cases like this
clear sigil
If you wanted to workaround this immediately you could check payment_status, but really this is a bug on our end and shouldn't have happened
fluid glen
Okay, what would that look like:
if payment_status = paid?
Also, just out of curiosity, can you tell me a little bit about the bug? And when we could expect to see the release of the fix?
clear sigil
Yup you'd just check payment_status == paid
The bug is a bit complicated (it's something specific to async payment method types like wechat pay that we were fixing and missed an edge case) - we expect it to be fixed soon, but if you want to keep track of exactly when it's fixed you should write in to support (https://support.stripe.com/contact) so that we have a way of contacting you and letting you know once it's done
fluid glen
Okay, awesome find, nice work. Do you have a ticket number I could provide to them?
clear sigil
You can mention that you spoke to karbi on discord so that I can grab it later and attach all the necessary info 👍
let me know when you're done and i'll find it on my end
fluid glen
okay, awesome doing that now
fluid glen
Hi @clear sigil Kassandra on the support team has created the ticket or whatever on your side, you should be able to find something now. Sorry for the delay.
One last question @clear sigil if you wouldn't mind. In situations like this, is status=complete a better data point for actual completion than payment_status=paid ?
clear sigil
👍 I'll get someone to update the ticket when the bug is fixed!
For you last question - status is meant to indicate whether the customer has actually finished going through the Checkout Session UI. In comparison, payment_status is specifically looking at the status of the underlying payment.
For a lot of payment method types (like card) there shouldn't be any difference between these two statuses - a card Checkout Session that was succcessful would always have status: complete and payment_status: paid. But this difference is more important for delayed notification payment types (like a lot of the bank-based types) where the Checkout Session UI has been completed, but payment won't actually be done for a few extra days (see https://stripe.com/docs/payments/checkout/fulfill-orders#delayed-notification)
fluid glen
we only have card and wallet types enabled I think so we shouldn't be seeing this which is why it's a bug but if we were to allow for 3d secure checks in this branch of code, we would need to change our synchronous branch to deal with that right?
clear sigil
No, 3DSecure for card payments would still be considered a synchronous payment method (your customer would complete authentication during the session and THEN it be complete/payment would be successful)
fluid glen
amazing, that's great. Thank you so much for your help today, I really appreciate everything you've done to get this fixed.