#d0mr_unexpected

1 messages ¡ Page 1 of 1 (latest)

sterile nestBOT
#

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

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

brave flumeBOT
vernal meteor
small topaz
#

Could you please share that PaymentIntent Id ?

vernal meteor
#

sure

#

pi_3Ofk7XCFtRqWQULy0ayx8ZgW

small topaz
#

thanks, checking...

#

You are referring to this requestId req_BkLt2wQ5v7jBXV right ?

#

after calling it, the payment_intent status is succeeded

vernal meteor
#

im not sure on request ids, can i search this in the dashboard?

small topaz
#

Ah I see, the request after that one, returning requires_capture

vernal meteor
#

data is limited in the events against the PI because its >30days old

small topaz
#

Yes I can see them, let me check...

vernal meteor
#

looking at developer logs, yes req_BkLt2wQ5v7jBXV returns succeeded

#

but yes subsequent req_d26uE7a3ttQAYN returns requires_capture

#

and i think the status stayed as this

#

as the cron job we have that cancels uncaptured payments picked it up and we filter out successful payments

#

this has caused us quite a lot of pain...

small topaz
#

I see that you are making a lot of API requests subsequently, 1 sec between each one..

vernal meteor
#

well we have synchronous code for payment processing but then webhook driven code for attaching metadata

small topaz
#

Why not making a single request for multiple actions

vernal meteor
#

the subsequent request only attached metadata

#

but i dont understand

#

i dont think the eventual consistency is the root of the problem

#

the cron job picked it up 2 days later and processed it as requires_capture

small topaz
#

For these requests req_BkLt2wQ5v7jBXV, req_d26uE7a3ttQAYN and req_VulOqbTXOsRuTD can be made in a single request

#

No these 3 requests were made subsequently...

#

I undesrtand this is not expected

#

But I think that the multiple requests is behind this...

vernal meteor
#

how so?

#

please look at req_JDX2IfOvU74CkO

small topaz
#

I strongly invite you to refactor your code and optimize it and reduce the API calls (it may affect your rate limit when you scale)

vernal meteor
#

req_JDX2IfOvU74CkO cancelled the payment intent, this was 5 days after the group of requests you are talking about

small topaz
vernal meteor
#

yes, because the status was still requires_capture

small topaz
#

Yes the issue is with the group of the request

#

Again, this is not expected

#

but the pattern of your API call isn't good

vernal meteor
#

sorry, i dont think im following why this would effect the status

small topaz
#

you are making multiple calls on the same Paymentintent at a 1 sec laps

vernal meteor
#

the subsequent updates being made only updated metadata

small topaz
#

Yes I know this is not expected. Do you have other example with the same behavior ?

vernal meteor
#

yes we do

#

quite a few

small topaz
#

All have the same calls patterns ?

vernal meteor
#

i havent analysed them all

#

i will review a few and send them over if you want?

small topaz
#

You make multiple updates simultaneously ?

small topaz
#

But again, I strongly invite your to refactor your calling pattern

#

and regroup your calls

#

in order to not face other issue too (like rate limits)

vernal meteor
#

unfortunately this might be difficult, we havent encountered rate limits yet but of course we will always look to optimise where possible

small topaz
#

Then if you still facing the same issue, don't hesitate to come back with a newer example

vernal meteor
#

i dont think this is related though

small topaz
vernal meteor
#

multiple services are communicating with the stripe API to add this information

small topaz
#

For example you are making the same request twice req_VulOqbTXOsRuTD and req_d26uE7a3ttQAYN

#

You need to refactor your code in order to avoid these as much as possible.

vernal meteor
#

but yea, i will look into what we can group

#

but are we agreed that this isnt the root of the problem?

small topaz
#

One quick option is to regroup the 3 requests I shared with you

#

You can regroup the capture and the metadata into a single request

small topaz
vernal meteor
#

its quite worrying that updating metadata could effect payment intent status permanently

#

unfortunately we dont have the capacity to optimise this and just see if it keeps occurring without being certain its the cause

#

as i said, two days later, the status was still requires_capture in req_JDX2IfOvU74CkO

#

its quite worrying that updating metadata could effect payment intent status permanently
so if the bad pattern is the root of the problem, then this would be true, right?

small topaz
#

Yes it seems like the status was overridden by the next two metadata updates. Again this is not expected I totally agree with you. But this seems like a race condition failure, and you are calling Stripe API using a bad pattern

#

I strongly recommend you to udpate your integration using good patterns.

#

In the meantime, feel free to collect as much payment intents as you can

#

This issue will require an in-depth investigation from our team in order to figure out the root cause. Can we ask that you write in to us via https://support.stripe.com/contact, providing as much detail and context as possible (you can also reference this thread).
Also, you can check the 'developer' box when writing in it will come straight to our team.

vernal meteor
#

of course, thank you for your time and help!