#scif_unexpected

1 messages · Page 1 of 1 (latest)

rancid beaconBOT
#

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

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

atomic wedge
#

Do you mean the response in backend when you fetch Stripe session?

bronze rampart
#

I didn't get you. I'm asking about inconsistency of the response I've got from Stripe API

atomic wedge
#

I am looking at checkout.session.completed and can see the Invoice Id

#

Platform fetches Stripe session using id from the query string. But session object does have "invoice" as null but payment_intent object has correct invoice id stated
This part, where do you "fetches Stripe session using id"?

bronze rampart
#

Yep, the webhook content shown at Stripe UI shows invoice

#

From Stripe API

atomic wedge
#

Is that a Get request from backend?

bronze rampart
#

Correct

atomic wedge
#

Can you share the request id, req_xxx

bronze rampart
#

Whether GET requests have req_xxx id? How I would know it?

atomic wedge
#

You can check on your request log

#

in Dashboard

#

Every request will have a request Id

bronze rampart
#

Was under impression the get requests are not logged. Thanks, I assume this one: req_zdkLUyfN9cVWTP

atomic wedge
#

Sorry, will be back here shortly

bronze rampart
#

Any ETA at least roughly?

atomic wedge
#

Sorry, here

#

Um I think the request could be too fast and we might haven't populated the properties correctly. Could you share the full response you received?

bronze rampart
#

Sure I can. Anything I should wipe from the dump?

#

Um I think the request could be too fast and we might haven't populated the properties correctly.
Does it mean there could be such inconsistencies like I stated and this is actually expected?

atomic wedge
#

It could depends on the time. Sometimes it's fast enough to get all information populated, sometimes it doesn. I would recommend waiting for checkout.session.completed event instead

bronze rampart
#

I want to have both webhook and pull strategies available and used in the app. The session object has status: complete,

#

Why the invoice appear on PI but doesn't on session?

rancid beaconBOT
bronze rampart
#

So if this inconsistency is fine, that makes API not robust at all

modern oar
#

you're retrieving the Checkout Session too early. This is expected behaviour right now. Creating the Invoice occurs after the payment for Checkout Session is completed. So like what orakaro mentioned, the recommended way to go about this really is to wait for the checkout.session.completed event instead.

bronze rampart
#

So in this case status of the session must not be exposed as completed. Don't you think so?

modern oar
#

I think that’s debatable and largely comes down to product design. From one perspective, since the payment has been completed, it makes sense to reflect that the Checkout Session is completed. The invoice is generated as an additional feature.

bronze rampart
#

No, it's not. I requested creation of the invoice, then I've got customer redirected to me with the id of session considered compoleted, the property says it's completed, but property is absent. Like my request was completed fulfilled but there is no data — this is inconsistent/damaged data but not a proper design

#

How I could know whether invoice is not generated because of legit reason??

#

I have no such tools to distinct.

modern oar
#

if you would like to share your feedback, I'd suggest writing to https://support.stripe.com/?contact=true to explain your use cases/feature requests as that helps the product team capture demand for prioritisation. However, right now, this is how the API and product currently behaves, and there isn't really a better workaround other than waiting for the checkout.session.completed event to obtain the Invoice ID