#Mecha Chocobo
arctic prism
coral sage
When you say "it is treated like a failure" what do you mean? What are you looking at that is telling you that something failed?
mortal finch
the promise returned by stripe.confirmCardPayment returns failed and the PaymentIntent removes the payment method that used to be attached to it
I don't recall the specific error, but the person working on this directly indicated that the error returned was the same as if they denied the auth request
coral sage
What are you using to accept card details? Checkout? Custom form? Payment Element? Card Element?
mortal finch
We have Stripe elements in a custom form. The card information is collected separately from the charge. We're creating the 3DS flow in the event they get an auth failure in the future
coral sage
Ah, okay. It's expected that the Payment Method is not attached after a failed confirmation. In that case, you should just redirect the customer back to the payment form and have them reattempt payment using the same Payment Intent (if there is one already). You can't attach a Payment Method that fails authentication, so there's no retry flow
mortal finch
Our concern is the case where a user opens the flow, realizes that someone else at the company may need to handle it or some other arbitrary reason they decide to close the modal instead of continuing, what is the expectation? Treating it as the user refusing the charge seems incorrect
coral sage
It's not really treated as a refusal. Nothing fails except the confirmation. The Payment Intent stays intact and can be updated/paid with a new Payment Method. The Customer can still have a Payment Method attached to them. So on and so forth.
Are you just trying to account for the customer coming back into the payment flow? or something else?
mortal finch
If I understand you correctly, yes. We are trying to ensure our system can handle a user not completing the flow in a single sitting, for whatever reason. Maybe they misclick and close the modal, maybe they decide they want to deal with it later, whatever.
coral sage
Ah, okay. So in that case you'd want to store information about them in a database (e.g. Customer ID, email, Payment Intent ID, Payment Intent status, etc.) so that when they come back you can quickly grab all those things and get them through the confirmation step again
Not sure if that fully answers your question, but feel free to clarify
mortal finch
I'll talk it over with my team. Thanks for the help!