GiGStartr-timeout | Stripe Developers | Page 1

pseudo isle Mar 31, 2022, 8:56 PM

#

hello again! sure ask away

cunning sentinel Mar 31, 2022, 8:57 PM

#

Getting my brain unknotted...

#

The "error" I see when sending too fast is a lock timeout - but I realize I've been hackerating with multiple charges from a single user because that was faster. But re-examining the actual error, I assume the lockout was because it was the same customer and payment method...

#

So can the createPaymentIntent API endpoint handle concurrent calls of separate customer/paymentMethods, up to the rate limit?

#

(I have a concurrency and rate limited "promise-pool", so I can map this out and get some concurrency, I hope)

pseudo isle Mar 31, 2022, 9:09 PM

#

So can the createPaymentIntent API endpoint handle concurrent calls of separate customer/paymentMethods, up to the rate limit?
possibly but all depends on how long the lock is held on for from preceeding requests

cunning sentinel Mar 31, 2022, 9:12 PM

#

Well, the question I guess is what is the scope of the lock? If I'm making calls (either sequentially, or from separate events) to cus_1 cus_2 cus_3 cus_4 ...etc is it the customer/paymentMethod that's locked, or the entire API endpoint?

pseudo isle Mar 31, 2022, 9:19 PM

#

the objects in your Stripe account (and any downstream relevant objects) are locked.

The entire endpoint is not.

#

so for a request made to cus_1, -> cus_1 and any relevant objects will be locked

cus_2 is a diff customer is is unaffected by cus_1 request

cunning sentinel Mar 31, 2022, 9:20 PM

#

THAT is the answer I was hoping to hear. I can deal with that.

#

I can now up my concurrency and maintain rate limits, adding in the "special" condition of monitoring for repeated costumers in a list (people can purchase multiple seats in different transactions for the events). This will help immensely (well, it'll cost me short term memory use, but trade-offs, trade-offs)

#GiGStartr-timeout