#jtishler
vernal oriole
somber flame
Hi there. One moment
So our Payment Element doesn't display previously saved cards. One thing you could do is have your own UI section that displays previously saved payment methods for the customer. Then, they could select the payment method they want to use for the subscription and you could create a subscription object on the backend, passing that payment method: https://stripe.com/docs/api/subscriptions/create#create_subscription-default_payment_method
But it's up to you
Whatever works best for your flow
opal light
what if the existing payment method requires 3DS?
would we need to deal with that again or no?
opal light
can you explain how you would recommend handling that?
we were looking at the option of passing payment method info manually to the confirm functions
not sure if thats on the right trakc
*track
somber flame
Yeah you can do it that way for sure
But if there's 3ds, you have to display the 3ds flow: https://stripe.com/docs/payments/3d-secure#when-to-use-3d-secure
opal light
is there a way to use the general confirmPayment and set the payment method manually
we saw how to do it for the specific ones like confirmCardPayment etc
but the documentation for the general one was a little less clear
somber flame
Ah if you want it more generic (all payment method types not just card) it would have to be done through the backend: https://stripe.com/docs/api/payment_intents/confirm#confirm_payment_intent-payment_method
confirmPayment doesn't allow you to pass the payment method id
opal light
what is the manual data referred to here then? "Use stripe.confirmPayment to confirm a PaymentIntent using data collected by the Payment Element, or with manually provided data via confirmParams. "
we really want to confirm on the client to more easily handle 3DS and such
somber flame
Where do you see that?
somber flame
opal light
sorry for the delay, had to hop into a meeting
not sure why we're seeing different things here
weary wing
@opal light hello, can you catch me up on what the question is? codename had to step away
opal light
hi yes thanks!
the question is about giving users the option to pay with an existing payment method
we are migrating to use the payment element in our subscription purchase flow to support 3DS
and we are trying to figure out how the flow should handle using a saved payment method
codename explained that the payment element doesnt handle this
and we were discussing the different stripe.js library functions that can help us confirm a payment intent clientside using an existing payment method id (or other info)
specifically we were diving into the difference between the generic confirmPayment function and the ones that are specific to payment method type
but also if this is the wrong track on how to approach the initial problem, happy to hear other thoughts!
weary wing
👀
gotcha so what you want is
you want confirmCardPayment() https://stripe.com/docs/js/payment_intents/payment_method which is basically confirmXPayment() where X is a PaymentMethod type like card or alipay etc
but in your case, looks like card so you just call confirmCardPayment and pass in an existing PaymentMethod ID using https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-data-payment_method
so ...
stripe
.confirmCardPayment('pi_123_secret_345', {
payment_method: pm_123existing
})
.then(function(result) {
// Handle result.error or result.paymentIntent
});
we are going to have different payment methods in the future
so we were wondering if theres a way to not have to decide which specific payment method function to use
weary wing
it wasn't built that way unfortunately, the functions were designed so that each new PaymentMethod type explicitly goes through a different method on Stripe.js
weary wing
no problem!