JeremyFlight

[raven oyster]

Your code will create the setup intent on your server and pass its secret client side https://stripe.com/docs/payments/save-and-reuse?platform=web#web-create-intent

[agile hedge]

But to create a setup intent, do I need to have created a payment method first?

[raven oyster]

No, the SetupIntent will create the payment method once it is confirmed. I'd suggest reading through that doc if you haven't already. It has good info on how each step of this process works. I'm happy to answer other questions but I think that doc can explain a lot

[agile hedge]

OK... so I have an HTML form that uses Stripe JS. I do this to show the card element:

            const stripe = Stripe('pk_test_XXX);

            let elements = stripe.elements();
            let cardElement = elements.create("card", {
                hidePostalCode: true,
            });

            cardElement.mount("#cardElement");

And I have an event handler on my form:

            let paymentForm = document.getElementById("paymentForm");
            paymentForm.addEventListener("submit", (ev) => {

                ev.preventDefault();

});

Having collected the card details, I want to create a setup intent with usage=off_session so that I'm able to process transactions against this customer's card at a later date.

How do I proceed from here using Stripe JS?

I should add that I need the customer to complete any 3DS verification while they're working with the HTML form.

[raven oyster]

That would be the next step in that doc, it shows how to present the payment element to your user via Stripe.js https://stripe.com/docs/payments/save-and-reuse?platform=web#web-collect-payment-details

[agile hedge]

And the "Payment Element" is the right one to use even though I don't want to take money from the customer right now?

[raven oyster]

And the Payment Element will automatically handle 3DS on initial setup, if you use these test cards you can see that functionality in action https://stripe.com/docs/testing#authentication-and-setup

Correct, the payment element is just the name. It can be used for setups like this as well

[agile hedge]

OK. I've just knocked up some demo code that does this:

stripe.confirmCardSetup({client_secret}, {
payment_method: {
card: cardElement,
billing_details: {
name: "Fred Bloggs",
email: "[e-mail]",
},
},
}).then((data) => {

etc.

});

...where {client_secret} is the client secret returned from the Setup Intent I create. This looks to work OK and gives me back a Setup Intent object from where I can get the ID of the payment method. When I use test card number 4000 0025 0000 3155, I get the dummy 3DS popup as well.

DOes that look correct?

[sweet glade]

Hi 👋 I'm stepping in as @raven oyster needs to go. If your intent is to test 3DS works as expected then yes this looks correct.

However I want to point out that the test card used triggers 3DSv1

[agile hedge]

Should I be able to see in the Stripe dashboard that my payment method is attached to my test customer?

Ah, OK. How do I trigger 3DSv2?

[sweet glade]

Stripe is deprecating 3DSv1 in favor of 3DSv2. For that you want to use the first card shown here: https://stripe.com/docs/testing#three-ds-cards

And yes you can use the Stripe Dashboard to attach this test card to one of your Customer records

[agile hedge]

I don't want to attach the payment method manually: it's more that I'm trying to see if the payment method shows against my test customer in the dashboard? Where would I find that?

[sweet glade]

What do you mean "shows against"?

If you create the Setup Intent with one of your customers and successfully confirm it, you will be able to see that payment method for that customer in the Customer Detail view on the Dashboard

[agile hedge]

So I create a Stripe Customer. And separately, the Stripe JS creates the Stripe Payment method. Should I be able to see that Payment Method in the Stripe dashboard, "attached" to the relevant customer?

Just checking that things have worked in the way I think they should have!

[sweet glade]

That makes sense.

So yes, if you create a Payment Method and attach it to a Customer using a Setup Intent and a Card or Payment Element you will see that in the Dashboard

[agile hedge]

Where exactly? I don't seem to be able to find that?

[sweet glade]

It should be on the Customer detail view. Here is an example of a test Customer in my dashboard

[agile hedge]

Ah, yes. Thank you. Is there anything in the Stripe dashboard that confirms that the customer has completed 3DSv2 verification for their given card / payment method?

[sweet glade]

We don't display that as far as I know. Since the issuing bank can re-request 3DS authentication at any time I'm not sure how useful it would be.

[agile hedge]

Yes, OK.

I've used the new test card number you suggested but when I complete the setup intent and subsequently try to process a payment (with a Payment Intent), I see this outcome: https://dashboard.stripe.com/test/logs/req_tW1CUfMw0DZ57H

Why would it show as "authentication_required" if I've already compelted the 3DS verification step?

[sweet glade]

The 3220 card requires 3DS for every payment

I suggested you use to be certain that your integration handles 3DS2 as well as 3DS1

[agile hedge]

Ah, OK! 🙂 We're taking the customer's payment details up front and then billing them each month on a subscription basis. So each time a transaction goes through, the customer isn't present and, therefore, isn't available to complete the 3DS verification.

Is there a better way for us to handle recurring payments to mitigate potential issues with 3DS?

[sweet glade]

No you are taking the best possible approach. You will just want to make sure that, if the bank decides to request 3DS again (the payment will fail), your integration does something like send an email to the customer to bring them back on-session to confirm the payment.

[agile hedge]

Yes, OK. Is there a test card I use can that will require 3DS v2 verification when I create the setup intent and the complete a successful payment intent thereafter, without further 3DS intervention?

[sweet glade]

I don't think we have that one specifically. But if you. have confirmed that the 3220 card works for your integration, then you don't need to worry about 3DSv2 since you've already confirmed it works for your integration.

[agile hedge]

But it's correct that the 3220 card fails when I use it for a Payment Intent is it, despite passing 3DS verification previously?

[sweet glade]

It doesn't fail. It just requires you to perform 3DS authentication for each Payment Intent.

Which is why the Payment Intent has a status of requires_authentication

You could still confirm that Payment Intent using the Card Element again

It won't automatically confirm because it requires 3DS on every payment

[agile hedge]

I can't do that as my payment intent happens away from the screen the customer sees (in a batch process on our server), so I don't have a Card Element in the environment.

Which test card can I use that shows the payment intent working, once I've completed 3DS verification?

[sweet glade]

The one ending in 3155 should work just fine in that case

https://stripe.com/docs/testing#authentication-and-setup
It's designed to test integrations where you need to set up the payment method for future off-session usage.

The language isn't always super clear, but the Details section in these tables of card numbers tries to explain the scenarios you want to use each card for.

[agile hedge]

Yes. Just tried that other card and the payment did succeed: pm_1M0SodBZ9qUe1kQ5TgQ6o0qK

I haven't used Discord before: when I look at this again next week, how do I get back to this conversation thread in case I need to check something?

[sweet glade]

You can search threads by your screen name and find this one pretty quick

We will close/lock this thread but you can still find this whole conversation.

And if you have new questions next week you can come back to this channel and we will be happy to answer them.

[agile hedge]

Thank you. 🙂