#bharatkilaru
1 messages · Page 1 of 1 (latest)
Hello 👋
Not sure I completely follow the use-case here.
Can you clarify with an example?
Sure. Our UI/UX is that there are payment plans on one side of the page and Payment Element on the other.
The user is clicking between plans on this page. As they do that, we need to create a subscription and grab the setup/payment intent of the plans to render the payment element. If they are payment intents, we create incomplete subscriptions and if they are trials, we create subscriptions with trialing status that still have a pending setup intent. Only if the user then submits on the payment element do we call confirmSetup or confirmPayment on the client.
Assuming that sounds correct, it's working just fine for payment intents (since the incompletes are clearly left incomplete). My question is with the setup intents (trialing subscriptions), any reason it's bad to have those accumulate (e.g. will they somehow get charged later when the trial is over?)
(If that flow sounds off though, feel free to correct! Thanks for the help!)
Ah okay. I think there's a way to make your flow work but I believe there's an easier flow
We recently introduced a new flow that allows you to render PaymentElement independently of the PaymentIntent/SetupIntents
https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription
So you don't need to create subscriptions just to grab the SetupIntent and render the PaymentElement
let me know if that helps^