#Fulco

1 messages · Page 1 of 1 (latest)

nocturne stagBOT
small nexus
#

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?

indigo veldt
#

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.

small nexus
#

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?

indigo veldt
#

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

small nexus
#

Could you verify this with colleagues? @native crystal gave the impression earlier that client-side requests were limited based on IP address

indigo veldt
#

Do you have an Account ID I can use to look up your account?

small nexus
#

Yes, one min

#

acct_1Ko0CGBLgDt8GrDE

indigo veldt
#

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.

small nexus
#

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

indigo veldt
#

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.

small nexus
#

But how about the clients? So my end-users, who's browsers are making requests to initialise Stripe Elements and to confirm their paymentIntents?

indigo veldt
#

It doesn't matter if it's client or server

small nexus
#

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:

  1. 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.

indigo veldt
#

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

small nexus
#

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/

indigo veldt
#

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"?

small nexus
#

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.

indigo veldt
#

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

small nexus
#

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.

indigo veldt
#

What's your Account ID? For some reason email isn't pulling anything up in our CRM

#

Nevermind I found it

small nexus
#

Ok good

indigo veldt
#

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.

small nexus
#

checking if I understood corrrectly: you'll be responding to the email?

indigo veldt
#

Correct