sarumilli

[civic tartan]

👋 happy to help

[hollow peak]

Hi Tarzan

[civic tartan]

Is there a reason why you're implementing this way?

[hollow peak]

We are integrating with SprintBoot in the backend. So whenever we are on paymentpage we are creating a paymentIntent using API call and passing client_secret to the frontend.
With this secret code we are showing the elements.
We are not going to do any confirm/Auth pay at this point. we will do on checkout last step when user clicks on placeorder

If I say paymentIntent.confirm through API it's is saying paymentMethod is missing.

[civic tartan]

if you want to authorize first the Payment Method then capturing the funds at a later stage, you shouldn't be creating a Payment Method this way

[hollow peak]

So I am trying to add a paymentMethod when we are on paymentpage and using this paymentmethod to confirm the paymentIntent

[hollow peak]

No, We are doing Auth and Capture at the last page.

On PaymentPage we only collect the payment details

[civic tartan]

you would use the normal stripe.confirmPayment on the front end but when creating the PaymentIntent on the backend you would add capture: manual which will give you the ability to capture at a later stage

[civic tartan]

then it's not a PaymentPage

you could use SetupIntents in that case

and collect the PaymentMethod and attach them to the customer object

and setup_future_usage for either on_session or off_session but this means if 3DS is mandatory the user would have to auth 2 times

[hollow peak]

This is not we are looking . Lets say In Amazon, we will have paymentPage but the Auth will done on the last page(after clicking the placeOrder button).