#milan_unexpected

1 messages · Page 1 of 1 (latest)

quasi vaporBOT
#

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

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

fallow verge
#

👋 Hi there. Do you have any request IDs you can share (req_xxx)?

quasi vaporBOT
iron needle
quasi vaporBOT
iron needle
#

Here's a PI. Would that work for you? pi_3SGIq9FXd5WaHKhp0er9WqOO

torpid trout
#

thanks, taking over for my colleague and taking a look now

iron needle
#

Thank you. I'll step away for a bit and be right back. Please excuse any delays in me responding.

#

I'm back

#

What do your customers normally report as the response time from Stripe?

torpid trout
#

sorry for the delay, still investigating this!

#

so in your request to create the above payment, you set both confirm: true and capture_method: 'automatic', which does add some additional latency due to the actions Stripe needs to take to communicate with the card network and confirm that the charge was captured before responding

iron needle
#

Interesting. If we take that approach, that means Stripe is still doing the auth up front and capturing presumably seconds later, is that right? And if so, can I still rely on an immediate approval/rejection from the API call or do I have to wait for the async to complete and the webhook to arrive before confirming success of the payment to the user?

#

And is your recommendation to set confirm to false as well?

quasi vaporBOT
torpid trout
#

confirm controls whether the payment is attempted (i.e. the 'auth' step but not the capture), so it's not necessary to remove that (it's just relevant as there are more operations for Stripe to perform than if you were just creating a PaymentIntent and not confirming)

you can still safely rely on the status of a PaymentIntent to confirm payment success when using async capture, but some objects/properties won't be populated until after the capture goes through (which can take around ~1 hour to be reflected in the API): https://docs.stripe.com/payments/payment-intents/asynchronous-capture#listen-webhooks

iron needle
#

Ok. I'll give that a go and see how it looks. I just tried an authorization in the sandbox to see if I can tell a difference (confirm = true and capture method = "manual"). That still took 1 second. I'll do more testing on a broader data set but do you have a guess as to the performance improvement we might see overall?

#

Thank you for your help. I'll step away again but I'll read your response later on.