#Sleepyhead-3ds

1 messages · Page 1 of 1 (latest)

spiral latch
sick reef
#

Ok, i will try. I assumed those would trigger Stripe::CardError.

spiral latch
#

generally no, they don't, they return a 200 with the PaymentIntent with status:requires_action (specifics depend on how exactly you're integrated but overall that should replicate the issue you're looking for)

sick reef
#

Thanks. Sorry I am a bit confused how I could trigger that. Can I skip 3DS somehow in JS? I want to setup the intent, save the card, skip 3DS, then confirm the PI server side.

snow wedge
#

No, if you try to skip 3DS when a customer's issuing bank requires it then that transaction will be rejected.

#

Oh sorry, I think I misunderstood.

#

You're trying to simulate a card needing to complete 3DS but it didn't go through that flow before being confirmed?

sick reef
#

i actually do not know what is the cause. or whether the card supports 3ds. I am seeing "This PaymentIntent could not be captured because it has a status of requires_action." in my logs and would like to trigger that error so I can at least handle the response. Then the next step is to figure out what the actual problem is in the flow.

snow wedge
#

Gotcha, any chance that payment intent is still in the requires_action state? If so, then you could just try capturing it again to recreate that error.

sick reef
#

yeah, not sure how it is able to proceed with that state (I have been mostly following the doc flow setup). Anyways, I could trigger capture but not sure how to save the card in the PI without triggering 3DS in JS before triggering capture.

snow wedge
#

Could you share the ID of the payment intent?

sick reef
#

pi_3KPPSWASXnirMqH33TEQfXGz

snow wedge
#

Alright, so for this one it looks like the 3DS flow wasn't completed successfully the first two times it was attemtped.

#

I'm running through a test to confirm if you can simulate this.

#

So if you use one of the 3DS test cards that require authentication (in test mode) then that will trigger a simulated 3DS flow. When the popup appears, don't click the succeed or fail buttons, just close the window. This will simulate a canceled 3DS and the payment intent should remain in the requires_action step. (If you click fail then the authentication will fail and the PI will instead transition to requires_payment_method)

sick reef
#

Thanks, I am able to replicate the error now

#

But how is it possible that Stripe.js is able to continue the flow when skipping 3ds? I have to manually trigger stripeIntentHandler instead of my error handler to be able to replicate this now

snow wedge
#

Can you clarify what you mean by that?

sick reef
#

"it looks like the 3DS flow wasn't completed successfully the first two times it was attemtped."

How could it bypass 3DS? I am unable to replicate that in my normal flow. I assumed stripe.js would take care of such requirements?

snow wedge
#

Can you talk through what happened? Based on what I'm seeing 3DS was required, and not completed which is why the payment didn't complete.

sick reef
#

yes, exactly. when using stripe.js confirmCardPayment would result in 3DS flow for me. I don't understand how the user is able to bypass 3DS. I only submit the form when confirmCardPayment results in no error.

#

so somehow the result does not include error and thus submits the form.

snow wedge
#

Hm, taking a closer look.

#

Alright, I think this is falling into a sort of in-between case. The confirmation call isn't throwing an error because the payment isn't failing, but it's not completing either which is why the payment intent goes into the requries_action state 0. Based on what I'm seeing, it looks like the 3DS flow actually timed out. I can see it was launched and then about 20 minutes later it was canceled.

When you try to capture server-side, you can add logic to check if the payment intent is still in a requires_action state to catch this scenario.