#vmehtawhq_api

1 messages · Page 1 of 1 (latest)

fallow vineBOT
#

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

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

crimson gull
#

I wanted to know about API rate limiting.
1.Is it per account based or api based or method based?
It is per API key iirc

terse lance
#

Yes this is the one but it says 100 per second and it seems low as per the traffic we are using

crimson gull
#

Can you describe your usecase? Most big merchant/Stripe accounts don't hit these limits often

terse lance
#

What rules apply for GetPaymentIntent API?

crimson gull
#

Are you sure you're running into rate limits vs concurrent request limits?

#

What rules apply for GetPaymentIntent API?
Not sure what you mean by that, can you elaborate?

terse lance
#

I am not running into rate limits, we are building something around checking status of payment intent every second or every 3 seconds for 5 minutes or less than that if payment succeeds in time.

#

For around 3k customers.

#

So, rate limiting was the thing I wanted to consider.

#

How quickly will I hit rate limits for get payment intent api or to re phrase what's the rate limit on the same?

crimson gull
#

Is there a reason you're polling the API explicitly rather than using a webhook endpoint to receive an event when the payment is successful?

terse lance
#

Yeah, Stripe docs for server driven terminal payment says to poll for payment status because there might be connection issues with readers or delays in webhook or reader object might be in bad state even when payment is already complete

crimson gull
#

A better approach might be,

You create a webhook endpoint that listens to payment succeeded events -> Stripe sends the event to your endpoint -> Your code handles the event and changes payment status in your Database -> You poll your backend to see if the status was updated

#

ah you're using terminal, gotcha.

terse lance
#

Yeah for other purposes we do have webhooks but for server driven we need this approach

#

What do you think now on rate limits for get payment intent?

crimson gull
#

I believe you're referring to this section: https://docs.stripe.com/terminal/payments/collect-card-payment?terminal-sdk-platform=server-driven#stripe-api

You can poll the API for the status. However, I'd say don't call the function automatically. I'd recommend adding a button which the POS operator can use to trigger retrieval of the PaymentIntent.

That way, you would most likely avoid running into any rate limiting errors. Additionally, you can use write your logic to handle the errors gracefully if it encounters any and use some sort of retry mechanism: https://docs.stripe.com/rate-limits#handling-limiting-gracefully

#

The canonical apparoch is still listening to webhooks

terse lance
#

👀 I understand what you saying. Just to confirm, it is 100 read operations per second in live mode?

crimson gull
#

Correct

terse lance
#

Is it per connected account or on platform account?

crimson gull
#

It depends on the type of charges you're creating.

terse lance
#

Type of charge?

crimson gull
#

Are you using Destination charges or Direct charges? Meaning are you creating these payments directly on the connected account OR are you creating these on platform and then transferrring it to connected accounts?

terse lance
#

We use OnBehalfOf parameter and TransferData.Destination which I would believe is destination charges

#

while creating payment intent

#

sample payment intent: pi_3PLVSTHFzwE4pTge0m6kmlyz

crimson gull
#

Let me double check something

#

Okay so with Destination charge + on_behalf_of parameter, the request would be counted under platform's 100 write operation per sec limit

terse lance
#

and read operations?

crimson gull
#

Same thing! Destination charge objects are created on the platform. So any attempt to retreive it will also use Platform account's bucket

terse lance
#

This feels a little weird because we may have hit this limit or close to hitting it then.

#

Is there a place I can check these stats?

#

I want to know how much our API's are close to burn the limit every second.

crimson gull
#

You can check your request log on the dashboard to see if there were any rate limited request.

#

I can check if you ran into any rate limit errors for this account:
acct_1EaPCrHFzwE4pTge

terse lance
#

I find none rate_limit error codes for in the requests logs

#

Is that our platform account id?

#

This definitely doesn't seem low

crimson gull
#

I'm not super familiar with that chart but I don't think it's painting the right picture. I looked up your account logs and it seems like out of ~2M requests in last 7 days only 2 timed out for lock related timeouts (not rate limited)

#

I'm seeing 0 requests limited by rate limit in last 7 days

terse lance
#

This is the unsurity of making/not making the call to use the api to fetch the status because we never know when we will hit the rate limit

crimson gull
#

I think you should be fine. I'm not seeing any API requests getting blocked by rate limits so far.

I do not think (based on your traffic pattern) that you'll hit the limit any time soon. But I'd highly recommend integrating a webhook endpoint as the canonical approach and hitting the API as a backup

terse lance
#

Okay. Tokeaway would be 100 read/write operations per second for the account and using the call only as a backup.

#

Thank you for your time @crimson gull