#arnav_webhooks
1 messages ¡ Page 1 of 1 (latest)
đ 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/1483620752975597650
đ 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.
- arnav_best-practices, 4 days ago, 22 messages
To give more context for each of the payment methods i have configured it as BECS and it is using 'instand success' response
Hi! What do you mean by "'instand success' response"?
Let me find the docs for this one, give me a moment please
at this link
under 'test your integration'
So for the BSB the setting would be 000000 and account num as 000123456
Go it! Yes Stripe does have a queuing system and we will not hit your endpoint with webhooks simultaneously.
Oh right thats good to know, is there any docs or things you can point me to
& I want to know the limits of the queuing system, i.e. 5 concurrent requests or something like that so that I can make our backend services capable of handling max load.
Oh right thats good to know, is there any docs or things you can point me to
We don't have a document for Stripe queuing the events with those specific but this is our webhooks document: https://docs.stripe.com/webhooks#handle-events-asynchronously
Oh right ok, being that stripe has the in built queing system as well as exponential backoff I think we should be ok in terms of scalability. We are designing the system to handle at most 5000 recurring payment intents being triggered at once, as well as other checkout sessions and things on a more random schedule, but nothing of too much 'volume'.
I have done testing on our endpoint and it seems it can handle about 15 concurrent sessions at once
But it can scale to more depending on how long it takes to execute the function within the endpoint
Thanks for your help! One last question, does stripe handle the queing system differently in 'live' mode to 'test mode' or is it the same
Test mode has fewer retries and will not be across 3 days. Likely over a few hours.