kamon000

[proven badge]

Hi there

[silent spade]

Howdy!

How are you doing today?

[proven badge]

Most important thing is to ensure you are using a SetupIntent when you collect the PaymentMethod originally

Good thanks

[silent spade]

That's good to hear!

Why a SetupIntent?

We've been using PaymentIntents without issue

[proven badge]

Because it can handle 3DS if the issuer initially requests it.

Ah maybe I jumped to conclusions here.

You are charging your Customer when you collect the PaymentMethod the first time?

[silent spade]

Sorry, it's a bit confusing, here's the flow:

1. At checkout, user inputs their payment method and we do create a setup intent.
2. We use the Stripe Elements and the Setup intent to grab the payment method ID from that
3. When they complete checkout, we don't always auth the card immediately
4. 5 days before the transaction needs to be completed, if the transaction hasn't been authed yet, we create a PaymentIntent using the Stripe payment method ID from the SetupIntent on the server in the background
5. After the users completes the steps they need to fulfill the order (we're a marketplace), we will capture the PaymentIntent

However, because step #4 is in the background, I'm not sure the best way to display 3D secure to them

[proven badge]

Yep gotcha

So yeah, you have it spot on -- you basically message them at this point (when 3DS is requested) and you bring them back on session. Once they are on your site you call confirmPayment() on the frontend using Stripe.JS and pass the clientSecret from the PaymentIntent: https://stripe.com/docs/js/payment_intents/confirm_payment#confirm_payment_intent-options-clientSecret

That will re-confirm the PaymentIntent and handle 3DS

[silent spade]

Okay, thank you!

Is this flow reasonable as far as handling the user going through the 3DS flow.

1. In the background, when we detect that a PI needs 3DS confirmation, we record the redirect_to_url in the DB
2. We notify the user that action is needed and send them to a page that retrieves that redirect_to_url from the DB via our API
3. On that page on the client, we display an iFrame in a modal of the redirect_to_url
4. The user completes the card networks 3DS challenge
5. On that page, once the 3DS challenge is done, the client requests that our API server confirms the PI (to prevent the need to handle a client_secret and it matches with how we currently handle it)
6. Client is notified that things are good to go

Would that work?

My main concerns on storing the redirect_to_url for an extended period of time and if that'll expire.

I'm also curious on how to actually know that the 3DS challenge is completed. In the docs, it seems like the suggested method is to pass a return_url when initially confirming the PI. Would that still work with this flow? I'm thinking that the return_url would be another page on our app that calls an API method on our server to update our internal PI tracking in the DB to letting us know that the PI is complete and potentially send out web socket events to know to close the iframe/notify the user of sucess.

[proven badge]

That's not how it should work.

If you are charging a saved card here then you should be setting off_session: true when you create/confirm your PaymentIntent.

This optimizes your flow and has us request a 3DS exemption from the issuer since they already set up the PaymentMethod in the past and the customer is not on session to complete 3DS at that time.

So the vast majority of the time, 3DS won't be requested at all.

However, sometimes issuers still do request 3DS. In this instance, we will return an authentication_required decline

At that point you should notify the user that they need to complete 3DS and bring them to your page

If you want to handle 3DS in an iframe, instead of using Stripe.JS, then you confirm the PaymentIntent again server-side and pass a return_url and pass off_session: false since now your Customer is present

At that point you do what you stated above -- you use that URL in an iframe

[silent spade]

Ah, gotcha! Sorry, misunderstood.

When a card does get declined for authentication_required do I simply recreate the PI, or am I able to retry confirm on the same PI (with the same payment method), but this time because they are there, when we go to confirm, we get the return url and have them go through the 3DS flow?

[kindred token]

Hi, stepping in as bismark needs to delurk. Let me catch up.

[silent spade]

Howdy! No worries, much appreciated!

[kindred token]

That is correct, you should be able to retry the confirm on the PaymentIntent with the same payment method details.

[silent spade]

Wonderful.

Is there a time limit on the redirect_to_url from card issuers?

[kindred token]

I do not know what you mean here, can you add more details here?

[silent spade]

So, when the card issue gives us the redirect_to_url when confirming the PI, does that URL ever timeout/expire?

Like, for example, the customer sits on the confirmation page for 24 hours for some reason, then finishes the 3DS secure using that URL that was generated 24 hours earlier, will it still work?

[kindred token]

Confirming now

[silent spade]

Thanks!

[kindred token]

I was able to confirm that we can't guarantee non-expiration. It could expire yes.

But there is not a like a timeline that I can share. Like the redirect can go to the bank and the bank could time out these redirect urls.

[silent spade]

Gotcha, that's good to know. How would I know that it's expired?

[kindred token]

You'd get an error message in this case.

[silent spade]

The user would correct?

Since that redirect_to_url would likely be in an iframe (or displayed on a separate page) only the user would know, correct?