#apex_best-practices
forest warrenBOT
👋 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/1493560252518629407
📝 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.
- apex_best-practices, 6 days ago, 13 messages
median dew
I'm also open to changing our approach if there is a better way to support the target UI without losing user-entered PM info. Thanks for your help!
glossy olive
👋 So PaymentIntent and SetupIntents are different types of objects, so can't be mutated or changed from one to the other. But it sounds like your use case would be well suited to the deferred flow, where payment details are collected before creating the relevant intent object. Have a look at this guide: https://docs.stripe.com/payments/accept-a-payment-deferred It will walk you through how to do this step-by-step
median dew
On that guide, it seems like I still have to create the Elements instance with a defined mode of either payment or setup, right? It appears to me that once I've done that, I've committed to either a PaymentIntent or SetupIntent, even if I haven't actually created the intent object yet.
Am I misreading the docs?
forest warrenBOT
loud stratus
👋 taking over for my colleague. Let me catch up.
loud stratus
On that guide, it seems like I still have to create the Elements instance with a...
you can always use elements.update
but what are you actually trying to achieve? what's the endgame?
median dew
I'll look at update to change the mode, thanks! That may do the trick.
But to answer your question:
The targeted UX of our Payment page is to have a toggle for "Pay Now" and "Schedule Payment". Lower on the same page would be the Stripe Elements for PM data collection. After that would be the "Confirm" button.
In most cases, the user will have toggled pay now or pay later before interacting with Elements, but our design does not block them from entering their PM info, and then toggling over to Schedule Payment before hitting "Confirm".
The goal (and reason for my question) is to make sure that after the user enters PM info, they can do whatever else they want on the page (such as toggling from Pay Now to Schedule Payment) before pressing Confirm - and the endgame being that once they do press Confirm, we still have a path to charge their PM.
In my testing, I've been blocked there - instantiating with mode: 'payment' doesn't allow me to do a SetupIntent, and instantiating with mode: 'setup' doesn't allow me to do a PaymentIntent - it seemed I'd have to re-instantiate Elements, and force the user to re-enter PM info.
loud stratus
I'm not sure whether the PM info would stick after elements.update
let me test it out real quick
median dew
Thank you!
loud stratus
yes that should work