#eddts-confirm-payments
azure pendant
Hi 👋 if the customer is reusing a payment method that is already saved and available for use, then the server has enough information to initialize the confirmation. The risk is that the issuer could require 3DS be completed for the flow, and if that happens then Stripe.js might be necessary to handle that portion of the flow.
turbid forge
Ok, so what is the recommended pattern for that situation? I thought that if the PaymentElement was mounted using a client_secret created using a saved payment method it may render something to indicate this, but it seems to just render the standard card capturing elements which then can't be submitted as they are incomplete.
In my previous discussion about this I was advised that after the server has created the payment intent using the saved payment method it should then be "confirmed by the client" but I'm not sure how to go about this short of having more endpoints on our server, or reverting to using the other confirmation methods from stripe.js, which would render our migration slightly redundant
azure pendant
Apologies for the delay while I confirmed some information. What you can do is to create and confirm the payment intent from your server. If the payment intent goes into a requires_action state, then you can use the handleCardAction function in Stripe.js to complete the authentication flow:
https://stripe.com/docs/payments/accept-a-payment-synchronously?platform=web#web-handle-next-actions
https://stripe.com/docs/js/payment_intents/handle_card_action
turbid forge
Ok great, thanks for the information. Unfortunately the server side is being handled by someone in a different time zone to me so I can't verify this with them just yet, but that all makes sense so hopefully that should allow us to resolve this 👍