#yi-cheng_best-practices
untold sequoiaBOT
👋 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/1282560898921398344
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tidal stream
Hi there, no I don't think you can confirm a checkout session payment from sever side.
Why don't you use subscription mode checkout?
torn crater
Hello!
Sry I left out some details. Step 2 is more of like creating new payment intents in the future periodically, not related to the first checkout session
tidal stream
That sounds like subscription to me. So what stops you from creating a subscription mode checkout session?
torn crater
Why don't you use subscription mode checkout?
I've investigated using subscriptions and wanted to skip the whole price/product model as it would simplify the integration. Also I have my own subscription logic so I'd just need the payment intent to performing the charging
tidal stream
I don't recommend that. Billing is complicated and I'd stronglly suggest you to let Stripe handle it.
torn crater
Just wanna clarify, so the docs here: https://docs.stripe.com/payments/save-and-reuse?platform=web&ui=elements#charge-saved-payment-method
Is it not meant for recurring payments?
tidal stream
You can use this integration to set up recurring payments. But subscription mode checkout session is way more easier.
For example, Stripe billings automatically retry failed payments, support prorations and metered based billing.
torn crater
I'd love to utilize Subscription/Billing, but as it stands with limited time and constraint I needed to utilize payment intents directly 😦
Going back to step 4 (from the original question), I'm concerned if 3ds (i'm using card payment method type only) will trigger twice here - first time if customer updates their default payment method via customer portal, and then second time when I update the existing payment intent with the new payment method with setup_future_usage=off_session and reconfirm. Could double 3ds occur in this scenario?
If that could happen, would it be better to just utilize Stripe Checkout/Elements instead whenever payment intent transitions into requires_payment_method (aside from the case where 3ds is required), or is there a better way?
tidal stream
Yes that's possible. So your integration should always handle 3DS by taking your customer to your website, where you can call stripe.confirmCardPayment() to start the 3DS flow.
It's entirely up to you. You can confirm the paymentIntent with a collected payment method, and only take your customer to your website when the payementIntent becomes 'requires_action'
Or you can alwasy confirm the paymentIntent in frontend, and Stripe.js will automatically trigger 3DS when you call stripe.confirmPayment
torn crater
Alright, gotcha, thanks for your help! 😄