#lkb2k_api
fallow prairieBOT
đ 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/1215340883789221948
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
last shard
The other suggesstion in the docs is rate limiting. Is the issue that we are processing orders too rapidly?
rare trellisBOT
mighty flax
Looking in to this. Can you link me to the doc with the rate limiting suggestion? Will see what I can find on this
last shard
sorry those extra PIs were a different client, looking for more examples
pi_3Orj9RDFLdjPQhSc07ZXGQHd, pi_3Orj9WDFLdjPQhSc11WPpF1B
mighty flax
Gotcha, the suggestions in that doc are more geared towards preventing bad actors from using your site from card testing. Both rate limiting and captchas make it slower and harder to card test on your site with, which can drastically reduce one's ability to card test compared to be able to quickly make as many requests as they want. I am not sure if there is an API solution to what you can do for this customer's payments. I will consult my colleagues and get back to you.
last shard
This example in particular: pi_3Orj9RDFLdjPQhSc07ZXGQHd
We created this ucstomer back in 2019, and the current payment method was set up in 2022 cus_FmWUScucg198W4
It's hard to see why that would get flagged for card testing, since it's a card we tokenized and have been successfully charging for 2 years
mighty flax
It looks like there isn't anything API-wise that you can do here but if you talk to support they may be able to escalate this to a team that can unblock you here.
https://support.stripe.com/?contact=true
One thing I did notice is that you aren't specifying that these payments are off session and have a feeling that this may have something to do with it. Flagging the payment as off session will indicate to us that the users aren't around so this will look more like a subscription payment. Without it, I think our system may think that you are trying to say that however many dozen users are actively putting in their cards at once. https://docs.stripe.com/api/payment_intents/create#create_payment_intent-off_session
last shard
Hm.. I think we don't do that because it also requires us to make the transaction confirm=true. Even though it's off session, we auth and then capture because sometimes we have issues like inventory contention for limited quantity products, so we don't want to consume the inventory until we've confirmed the funds, then we lock the inventory and capture.
Should we be doing that differently? Is there some other way to confirm the balance other than separate auth/capture?
mighty flax
Confirming off session should still move the payment intents to requires_capture and require you to manually make the second call to actually capture the funds