#Fulco
1 messages · Page 1 of 1 (latest)
Referring to an earlier message by my colleague:
Server-side:
- create paymentintent
Client-side:
- give it to Stripe Elements UI
- stripe.confirmPayment({ element, ... })
Server-side, but not an API request:
- wait for webhook: payment_intent.succeeded
That would mean that for such an implementation, only 'create PaymentIntent' will be the focus point in scaling and rate-limit handling. Is that correct?
I believe you would expect to have around 100 writes/second for the server-side call and around 50 writes/second for the client side call.
Client-side being limited per IP, correct?
In that case, should we be implementing queuing and back-off scripts for any client-side originating API calls? Or are, for instance, retries handled under the hood by Stripe Elements?
I don't think it is limited to IP. I believe it's at a per-account basis. It wouldn't hurt to have back-off scripts for both client side and server side if you suspect you might go over these limits
Could you verify this with colleagues? @native crystal gave the impression earlier that client-side requests were limited based on IP address
Do you have an Account ID I can use to look up your account?
So I was able to confirm that IP address doesn't play a role in the rate limiting. So you can't make 100 requests on server A to some API endpoint, and at the same time make 100 requests on server B to the same API endpoint. Apologies if that goes against what you heard earlier.
I understand that this is how it works for all server-originating API requests, but how about any API requests originating from clients? (browser originating?)
So let's say:
100 requests on server A to some API endpoints, and at the same time (up to) 50 requests from a client with IP address X, and another (up to) 50 requests from a client with IP address Y?
etc etc
Or does everything count towards the single limit of 100
It's more or less 100 requests per API endpoint, across the whole account. It makes no difference which server you make the request from.
But how about the clients? So my end-users, who's browsers are making requests to initialise Stripe Elements and to confirm their paymentIntents?
It doesn't matter if it's client or server
Understood
Then I would like to confirm again the minimum amount of API requests that we can possibly make to process a single transaction (assuming no rejections):
Server-side:
- create PaymentIntent (1 request)
Client-side:
2. pass paymentIntent to Stripe Elements UI (this will make 1 API request under the hood please confirm if 1 or more)
3. confirm PaymentIntent (this will make 1 API request please confirm if 1 or more)
Your colleague @native crystal suggested earlier that under-the-hood more than 1 request may be made, hence my request to verified this information.
I don't think you are actually making an API request in #2. #1 has 1 server side api request and #3 has 1 client side request
Not sure if that answers your question though
Via mail contact with Stripe Support we received feedback that we were doing redundant requests to ElementsSessionRetrieve. We're assuming this happens as part of initialising Stripe Elements, hence my assumptions under point 2.
There is no mention of ElementsSessionRetrieve in the docs, nor is it in our code, so we're a bit in the dark there/
Are you working with an account manager or similar? What do you mean when you say "with Stripe Support we received feedback that we were doing redundant requests to ElementsSessionRetrieve"?
I don't believe we have a dedicated account manager designated to us. I'm in touch with Stripe Support via email (replying to support-repy@stripe.com).
We're negotiating a temporary increase in API limits for a specific large-scale event we have coming up.
Got it. Can you DM me the email address that you're using for that email thread? I'm curious if they're seeing something I'm not
In parallel, we're trying to understand as well as possible how we can minimise the amount of API calls to the absolute minimum, while also understanding which calls count towards the limits.
What's your Account ID? For some reason email isn't pulling anything up in our CRM
Nevermind I found it
Ok good
I'm going to pull that email into my teams queue and respond there instead, as I'll need to do quite a bit of digging to validate.
checking if I understood corrrectly: you'll be responding to the email?
Correct