#mahad-3ds-save
still dock
Honestly this usually doesn't make sense. You have your customer right here, on session, doing 3DS now is a win for you both since it sets up the card for future payments
lofty saffron
yeah I know that, but our use case is such that users can add multiple cards, delete them, choose a default card AND use those cards to make payments. As such, having a user go through 3D secure twice (once when adding the card and then when making an on-session payment) seemed slightly (not very) detrimental to user experience (since theres a very likely possibility that a user adds a card and then needs to use it right away for some payment)
still dock
once when adding the card and then when making an on-session payment
they are unlikely to go through it twice. And also if you're taking a payment now, then you shouldn't use SetupIntent
lofty saffron
yes but
still dock
if you think they will use the card right away, I'd focus on that first
ultimately there isn't a way to skip 3DS unfortunately
lofty saffron
yeah yeah, thats what I am doing -- usually (ie: use payment intents client secret to confirm payment). But one of our use cases allows users to update their subscription's price. We wish to allow users to use whatever card they want to to make the payment for shifting to a new price, the only problem being that we currently are using pending_if_incomplete as the payment_behavior when updating the subscription (to avoid reverting the subscription if payment fails, etc) but this behavior in itself transitions the payment intent associated with the subscription update process to the confirmed state -- at which point I can
still dock
yeah I think default_incomplete would be a better fit
overall though the flow you're after is not possible 😦
lofty saffron
sorry i meant past_due state 😅
the default_incomplete transitions to past_due state if the payment hasn't been made
still dock
correct but it gives you a PI to confirm which is likely the better overall option
lofty saffron
the "why tho" was for: "overall though the flow you're after is not possible 😦"
I mean...if pending updates were such that an update transitions to the pending state and then can be confirmed over using stripe js on the client side (basically, taking out the if_incomplete part...always transitioning the update to the pending state if a payment is required for the update
lofty saffron
correct but it gives you a PI to confirm which is likely the better overall opti...
yeah...but also more of a hassle to revert the subscription's price back if no payment is made
pending updates remove that hassle, but the downside then is that payment is attempted right away using the card that stripe already has saved
still dock
yeah that's fair. You could unset the default PaymentMethod to avoid that, but that's not a great flow 😅
lofty saffron
yeah exactly