#chung-yi_best-practices
gleaming canyonBOT
👋 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/1351194151697252382
📝 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.
- chung-yi_best-practices, 5 days ago, 14 messages
robust pagoda
Hi, not a specific guideline no. Are there any specific issues you're looking to talk through?
Let me know if you run into specific issues
gleaming canyonBOT
shy galleon
When the user is taken to the redirect url, there is no guarantee that our backend has received the payment event and processed it, given it's async. So we are curious what would be a good way to render UI in that state.
winter cedar
This is ACH Debit?
shy galleon
For example, we can render a loading state keep polling, until the webhook event arrives and being processed.
The link is ACH debit, but we're using Payment Element and would like a consistent pattern across payment methods.
winter cedar
I wouldn't render a success page
Because you don't know if payment is successful at that point
If we're talking ACH Debit, specifically, it can take days for the payment to succeed
I would render a page that says payment processing or something to that effect
And if it's a payment method that succeeds fast (like card, for example) you can use polling
But up to you really on how to handle this
shy galleon
yeah the payment processing state for the delayed payment methods makes sense.
Maybe another thing I'd clarify:
After redirection from stripe.confirmPayment, can we assume the confirmation has succeeded? From the doc, it seems if failed the promise would error and redirection would not happen?
shy galleon
But payment isn't necessarily successful
You mean the delayed payment methods that would still be processing right?
winter cedar
Correct
shy galleon
Then if we can safely assume after redirection, the confirmation has succeeded, maybe we don't event need to poll, and can just display some kind of confirmation page, without waiting for the webhook event. Let me think through it and will come back for further questions. Thank you!
winter cedar
Are you using asynchonous capture; https://docs.stripe.com/payments/payment-intents/asynchronous-capture
Or synchonous capture
You might still want to poll if using asynchronous capture
But not completely necessary
Because if confirmation succeeded, capture should succeed
It's just your success url will be rendered prior to payment succeeding
So up to you I guess on what you want to display to customer at that point
shy galleon
We're doing stripe.confirmPayment on the client side via Payment Element tho. Is there similar distinction for sync vs async?
winter cedar
Doesn't matter where you confirm
capture behavior is set when creating the payment intent
shy galleon
ohh that's specified at payement intent creation time.
winter cedar
Yeah
Also depending on your api version, you may be using automatic_async by default
If you use https://docs.stripe.com/changelog/2024-04-10 or later then you're using it by default
shy galleon
Is that only for capture, or also for credit card hold?