#frankcastle_best-practices
dire lightBOT
đ 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/1362123650962030774
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
wicked pilot
Hi, I do not believe we'd retry payments after the payment fails. In rare instances, if there are 500 errors for instance we might decide to roll the call forward and we discuss how you can handle advance errors here: https://docs.stripe.com/error-low-level
You can add more defense with https://docs.stripe.com/api/idempotent_requests. The idea is that you pass a unique identifier when making a request to Stripe's API that ensures you can only run this transaction once. If you re-run the query with the exact same idempotency key you will get the original response from the first call which ensures you never have 2 charges created for the same "transaction" on your website.
snow berry
ok. Thank you.
wicked pilot
Sure
snow berry
It would seem like we should also error_on_requires_action: true
in order to prevent further attempts when 3DS is required.
https://docs.stripe.com/api/payment_intents/create#create_payment_intent-error_on_requires_action
wicked pilot
Hmm, that is a bit different and you'd use those if you're not authenticating with 3DS: https://docs.stripe.com/payments/save-card-without-authentication
If you're following, https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements you would not need to