#chung-yi_best-practices
honest stratusBOT
👋 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/1331707260522467430
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
obsidian saddle
Hello
Overall I'd recommend using the deffered intent flow
It is more flexible and ensures you aren't left with a bunch of incomplete PaymentIntents
The reason to use the intent-first flow would be if you want to support Blik or ACSS as payment method types -- those aren't supported on the deferred intent flow as called out in the docs.
Also Express Checkout Element uses the deferred intent flow itself, so makes more sense to use that for Payment Element as well if you are going to use both of those Elements.
tribal remnant
Thank you @obsidian saddle ! Does that mean Express Checkout Element can't work with intent-first approach?
Also Express Checkout Element uses the deferred intent flow itself
obsidian saddle
It can
You would just already have an intent created and you could ensure it has the proper payment method types to be used with Express Checkout Element.
tribal remnant
Yeah I guess I'm not sure why Express Checkout Element recommends collecting payment details first. Is it just simpler? Or there is real limitation?
obsidian saddle
It is really just due to history -- the intent-first approach came first. Then we built deferred-intent, which is really the better way.
So Express Checkout Element was built with deferred intent
tribal remnant
Got it. So besides the Blik/ACSS support, there is no real limitation with the intent-first approach. It's just that deferred-intent is the more modern implemtation on the Stripe side?
tribal remnant
Yeah the incomplete intents were what we observe too.
Thank you! That's very good to know!
Can I ask you one more comparison?
obsidian saddle
Sure
tribal remnant
Another dimension in the Element flow is confirming payment on the client vs. finalizing payment on the server. I understand if we need custom business logic before confirming payments, we'd need to finalize payment on the server. Are there other factors to consider when choosing either approach?
obsidian saddle
Nope not really -- mostly up to you. Really you can still confirm on the client even if you have additional logic (see https://docs.stripe.com/payments/build-a-two-step-confirmation). The nice thing about confirming on the client is that 3DS/next actions are just handled if required. Whereas if you confirm on the server then you need to pass back to the client if next actions are required.
But mostly either way is totally fine and it is up to you.
tribal remnant
oh yeah good point! confirming on the client still need to ask server for the client secret and the gives the server opportunities to run additional logic.
and yeah we had to return custom response for handling 3DS now confirming payments on the server. It could just be simplified moving to the client I guess.
obsidian saddle
Yeah all of that stuff is mostly up to you
tribal remnant
Okay this is very helpful and I think I got the information I need. Thank you for clarifying all these! 🙏