#david-franco_best-practices
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/1225486164585353289
đ 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.
- david-franco_best-practices, 4 hours ago, 5 messages
Can you tell me a bit more about your overall process? Like how much later is the payment delayed? And are you delaying it until you know more info about the payment, or for another reason?
There are 2 possible workflows after a payment method is created through setup intents. The user can proceed with the checkout right away (average checkout page session is 2 minutes) or they come back later and try to complete that or another order with the previously store payment method
Ah so you are saving this card for them upfront, but this is before you even know if they are making a payment today? I think SetupIntent + PaymentIntent would make sense for that
PaymentIntents are generally for when you know the user is making a payment right now. SetupIntents are for when there isn't a payment right now.
The main thing to keep in mind is that each PaymentIntent and SetupIntent has the chance that the bank will request 3DS when they are being confirmed, so if you use a SetupIntent and then a PaymentIntent there is a chance for the user to be asked to complete 3DS twice for one transaction. We generally recommend using just a payment intent if you can help it, but for cases where there isn't a payment yet you can't do that.
Got it. Then regarding Payment Intents being processed fully on server side (using a preexistent payment method), is there any concern/issue?
The main one is to make sure you can notify your user that they need to complete 3DS if the payment intent comes back with a status of requires_action. To do that you can pass the intent's client secret to your frontend and call Stripe.js's handleNextAction method, which will display a 3DS modal for the user. https://docs.stripe.com/payments/finalize-payments-on-the-server?platform=web&type=payment#next-actions
Another thing to keep in mind is that if the user is not currently on your site, we have a parameter to flag that, but it sounds like your user may always be online when the payment is made so that may not be relevant to you https://docs.stripe.com/api/payment_intents/create#create_payment_intent-off_session
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Oh, though actually a thing to keep in mind is that you can also confirm payments with saved cards on the frontend. That can simplify things for you if you have a page that lists saved payment methods and also lets the user input new payment method info in to the payment element
Yes, we initially thought about confirming the payment intent in the FE, but there are issues with stock lock on the BE when we take that approach
So our plan is: generating the payment intent in the BE, sending it back to the FE, the FE optionally handles next-actions if the payment intent requires_confirmation, finally, calling the BE to confirm the payment intent and complete the order
Ah, you are tracking what is in stock? That definitely makes sense to finalize on the server then. That doc that I linked to actually shows a way to do that with payment intents when taking the card info for the first time. With that flow, you may be able to simplify this so that you don't take the payment info until Checkout happens and can save the payment method then.
That would allow you to remove the SetupIntent from your flow unless the user specifically just wants to save their payment method.
Awesome thank you so much for your help!