#jared_error

1 messages · Page 1 of 1 (latest)

hidden crescentBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1222585244285272107

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

placid schoonerBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

echo light
#

The linked thread is related to the same issue, although we are still having trouble after trying to implement those suggestions

steep vessel
#

Hello! Looking...

echo light
#

Hi 👋 thank you

steep vessel
#

You never set this Payment Method up for future use. Is the flow you're trying to build one where you collect payment details without charging, then take a payment later?

echo light
#

Yes that is correct. In the previous thread we had yesterday someone advised us to not include the parameter setup_for_future_use

steep vessel
#

The issue is that you're creating the Payment Method, skipping the setup for future use step, and jumping straight to an off-session payment. You can't skip setting it up for future use. See here: https://docs.stripe.com/payments/save-and-reuse

#

The setup for future use step should happen when the cardholder is present, at the same time they provide the payment info.

echo light
#

Setting up for future use means we need to create a checkout session?

#

We have a functioning checkout page and are currently able to charge customers later so long as they are not using a 3DS card

#

I guess I just want to make sure this is specific to 3DS card needs since I've been down a few different rabbit holes at this point

#

Is the idea that we need to create a setup intent before we get the customer's card details?

steep vessel
#

This is not specific to 3D Secure, although that's the main use case. Setting up Payment Methods for future use is a general best practice and covers both 3D Secure and other things.

echo light
#

Okay yes I've reviewed that

#

Is the issue that we need to create the setup intent before collecting the card information or can we create the setup intent after we collect the card information?

steep vessel
#

You can do it either way.

echo light
#

If we can do it either way then I'm not seeing what we are missing

#

We 1) collect payment info, 2) reach out to stripe to create payment method, 3) create stripe customer, 4) attach customer to payment method, 5) create setup intent, 6) try to auth but get error

steep vessel
#

Yeah, so step 4 shouldn't be happening. You should not be calling the /attach endpoint ever. Skip that step, create the Setup Intent, then in the last step confirm the Setup Intent client-side so the customer can complete the 3D Secure or other authentication process. Then the Payment Method will be set up for future use, and you can then use it for off-session payments.

echo light
#

Oh interesting

#

Okay so we'll try skipping attaching the card to the customer

#

"Skip that step, create the Setup Intent, then in the last step confirm the Setup Intent client-side so the customer can complete the 3D Secure or other authentication process. "

We're not able to get to the last step right now because the confirmation step occurs after the auth attempt. We expect that attempting the auth would transition the card to "requires action" status, then we can ask the customer to confirm.

Does skipping the attachment step allow us to create the auth without the error?

#

Or are you saying don't auth the payment intent and instead just create the setup intent and have the customer confirm the setup intent?

If we do that are we still able to perform an auth on a payment intent or do we have to wait on that?

steep vessel
#

Backing up a bit, I think there's an issue with the terms we're using. When you say "the auth attempt" what API(s) are you calling to make that happen?

echo light
#

Ah fair

#

I mean creating a payment intent

steep vessel
#

And to clarify, the flow you're trying to build is where someone provides their payment information, you save it without taking an immediate payment, then some amount of time passes (hours/days/weeks/etc.) and then you charge them when they're no longer present?

echo light
#

yeah that's correct. when we create the payment intent at checkout we are just authorizing the card though and not charging them until later

#

this works except for in the 3ds card scenario

steep vessel
#

Yeah, okay, that's where the disconnect is. You don't create a Payment Intent until the very end of that process, when you actualy want to take payment.

#

Setup Intents are used to set up a Payment Method for future use without taking a payment. During the first part of the process, when the customer is present, you should only be using a Setup Intent. The only time you use a Payment Intent is later, when you actually want to make a payment.

#

So, when the customer is present, you need to collect their payment information, create a Payment Method, set that Payment Method up for future use with a Setup Intent that the customer confirms while they're present, and then that's it for the first part of the process. No Payment Intent is involved.

#

Then, later, when the customer is no longer around, you create an off-session Payment Intent and use the Customer + Payment Method to charge them an amount.

echo light
#

Okay I think I understand what you're saying here

#

In that case does the SetupIntent service as an auth on the card for us? Like are we able to verify the funds are available or is that something we basically can't have with 3DS cards like we can other cards?

steep vessel
#

The Setup Intent validates the card, yes, but it doesn't verify funds or anything like that. How much time passes between when the Customer provides their payment info and when you actually charge them?

echo light
#

It varies quite a bit because we are just a platform facilitating the payments and our clients can set somewhat arbitrary timelines

#

I think the maximum would probably be 60 days

#

But either way is this something you recomend that we do regardless if the card is 3ds or not? I mean skipping auths via payment intents and using setup intents instead

steep vessel
#

Yeah, you should be doing this for all Payment Methods.

echo light
#

Okay we can try this approach. My take aways are 1) skip attaching the payment method to the customer, 2) skip the auth via payment intent creation and 3) replace that auth with a setup intent

#

Anything else I'm missing there?

hidden crescentBOT
steep vessel
#

Nope, I think that's it. Give it a try and see if it works for you!

echo light
#

Awesome. Okay thank you so much for all your help here. The details really made things more clear