david-3DS-detach | Stripe Developers | Page 1

vagrant escarp Jun 2, 2022, 5:12 PM

#

Hi there! Hmm interesting. I would also expect it to move back to requires_payment_method

#

I'll need to do some testing here and then file a ticket about that.

gleaming turtle Jun 2, 2022, 5:14 PM

#

that's great, thank you! i can provide exact reproduction steps if that would help

vagrant escarp Jun 2, 2022, 5:21 PM

#

I think the above is enough. Let me do some testing and I'll circle back.

vagrant escarp Jun 2, 2022, 5:41 PM

#

@gleaming turtle do you have an example PaymentIntent I can look at? When I do a quick test I am seeing the PaymentIntent move back to requires_confirmation when you update to a new payment method

gleaming turtle Jun 2, 2022, 6:45 PM

#

sure, pi_3L6IyIHTHZMmFuxl1wbLYJtF. are you able to look it up just using that ID?

#

you can see that payment_intent.source is card_1L6F1lHTHZMmFuxlCxbtoPKe but that card is no longer on the customer

vagrant escarp Jun 2, 2022, 6:47 PM

#

Yep that ID works

#

Ah okay so when you say "changes their card" what is happening is a customer update to change the invoice_settings.default_payment_method

gleaming turtle Jun 2, 2022, 6:58 PM

#

well, we do that and then detach the old card

vagrant escarp Jun 2, 2022, 6:58 PM

#

Right but the PaymentIntent itself is not affected.

#

Need to think about whether this should change PaymentIntent state 🤔

#

When you attempt to confirm the second time, do you pass the new card ID to confirmCardPayment?

gleaming turtle Jun 2, 2022, 7:03 PM

#

no, we don't. we're currently just calling it as stripe.confirmCardPayment(client_secret)

vagrant escarp Jun 2, 2022, 7:04 PM

#

Yeah okay that's fair. I still think that should work and we should attempt to confirm with the newly set default. Would you be able to test real quick what happens if you do stripe.confirmCardPayment(client_secret, { payment_method: 'new_card_id'})

#

Curious if this would be a functional workaround for now

#

I'm still going to file a ticket

#

I agree that we should infer that the confirm should use the current default if the old card was detached.

gleaming turtle Jun 2, 2022, 7:06 PM

#

or at least put it in requires_payment_method

#

i'll check what happens if we pass the new card id soon

vagrant escarp Jun 2, 2022, 7:12 PM

#

Of note... I'm not actually seeing that PaymentIntent that you shared as an example be re-confirmed at all. What error do you hit exactly when you attempt to re-confirm?

#

(I'm going to reproduce here as well since this is different than how I was testing before)

gleaming turtle Jun 2, 2022, 7:35 PM

#

oh i didn't re-confirm that one since that actually changes the status to requires_payment_method and i wanted to show how it stays in requires_action.

#

i'll create another one now

vagrant escarp Jun 2, 2022, 7:38 PM

#

Gotcha

gleaming turtle Jun 2, 2022, 7:41 PM

#

are you able to look up req_XlBD94hAtuhVKa? that's the response when calling confirm without providing the new card ID

#

i'll try the new card ID now

vagrant escarp Jun 2, 2022, 7:41 PM

#

Oh interesting

#

So we actually surface an error that seems to expect this state

gleaming turtle Jun 2, 2022, 7:48 PM

#

ok, explicitly passing the new default card ID to confirmCardPayment() works. so that will be a good workaround for us. (as a business rule, we only ever charge their default payment method anyway)

vagrant escarp Jun 2, 2022, 7:49 PM

#

Interesting

gleaming turtle Jun 2, 2022, 7:51 PM

#

well... actually it's not great because we support payment methods other than cards, so they could have switched to a non-card. moving the payment intent out of requires_action would still be ideal, since then we'll know not to prompt the customer for 3DS

vagrant escarp Jun 2, 2022, 7:53 PM

#

You wouldn't use confirmCardPayment with a non-card payment method though

#

But I still don't disagree that we should be moving the PaymentIntent back to requires_payment_method if the paymentmethod is detached.

gleaming turtle Jun 2, 2022, 7:53 PM

#

yeah, that's my point. we can't just blindly call confirmCardPayment() with the new ID, we'd have to check if it's still a card

vagrant escarp Jun 2, 2022, 7:54 PM

#

How do you check currently?

#

Like the same possibility is true regardless of this behavior right?

#

I'd assume you just grab the proper confirm method based on the type of the payment method that you set as the new default?

gleaming turtle Jun 2, 2022, 7:57 PM

#

🤔 i think right now we're assuming any payment intent in requires_action is for a card. i do think cards are the only methods we support that end up in that status right now

#

(we support card, ACH, and SEPA)

vagrant escarp Jun 2, 2022, 7:57 PM

#

Ah okay that makes more sense. Yeah ACH and SEPA shouldn't move to requires_action for off_session payments (I assume they are already properly set up)

#

Alright well I will file a ticket saying that we should move the PI back to requires_payment_method if the PaymentMethod is detached. However, not sure what the Eng team will say or how quickly it will be actioned so for now I'd recommend writing some logic to either confirm again if the client hits this error, or to check on the new payment method type and then pass the new card ID to confirmCardPayment

gleaming turtle Jun 2, 2022, 7:59 PM

#

sounds good. thanks very much for the help!

#david-3DS-detach