#hendr1x_confirmation-tokens

1 messages · Page 1 of 1 (latest)

random pythonBOT
#

👋 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/1267460400526524438

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

jaunty mountainBOT
#

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.

small yew
#

The issue is, payment methods can change

#

based on configuration settings

#

Is there no way to set a default for all payment methods?

twilit tinsel
#

Hi, let me help you with this.

#

Where in the docs are you looking exactly?

small yew
#

"Optional
Setting conditional parameters setup_future_usage or capture_method based on payment method"

#

I was also told in the chat at one point that I should do set it on the front end in the elements object but I can't find any reference for that

twilit tinsel
small yew
#

So what is the best way?

twilit tinsel
#

stripe.elements(...

#

That's the only way if you use confirmation tokens really.

small yew
#

That conflicts with the documentation I provided

twilit tinsel
#

I see. I would say, as long as you don't run into any issues, you can use the method I provided.

small yew
#

ok

#

and that is the only place I have to set setup_future_usage?

twilit tinsel
small yew
#

what do you mean duplicate all the parameters?

turbid glacier
#

Hi there 👋 jumping in as my teammate needs to step away soon.

small yew
#

converting an existing checkout to use them

#

I'm just trying to implement setup_future_usage properly at this point

#

it seems like I have to do the flag on the elements now

#

and I should keep the existing flags on paymentIntent->create()

#

does that cover everything?

turbid glacier
small yew
#

ok. So this checkout also supports setupIntent

#

does that have the exact same setup?

turbid glacier
#

Those will use the usage parameter instead. Additionally you'll need to change the mode that you use when creating the Elements instance to setup.

small yew
#

I don't see a usage parameter

turbid glacier
small yew
#

ok. The setup on the elements is the same though between paymentIntent and setupIntent?

turbid glacier
small yew
#

You do

#

I got an error

#

message": "The provided setup_future_usage (off_session) does not match the setup_future_usage from the provided confirmation_token (null). Try confirming with a Setup Intent that is configured to use the same parameters as the ConfirmationToken."

#

So if I do setupIntent I just need to set it to 'setup'

#

nothing else to it?

turbid glacier
small yew
#

Unfortunately my setup is complicated

#

Its a two-step confirmation that needs to support both setupIntent and paymentIntent based off configuration settings

#

It also needs to support saving payment methods to accounts for later usage

#

and I'm using confirmationTokens

turbid glacier
#

I'm not sure I understand. The two-step confirmation flow is for when you need to collect payment method details before you're able to confirm the amount the customer should pay and are able to show them that amount. So I'm not grasping how this corresponds to a flow using Setup Intents. What are you confirming with the customer after collecting their payment method details?

small yew
#

I have a checkout flow that collects payment information, then shows a confirmation page for everyone.

#

Depending on configuration of the site it will charge payment immediately or confirmSetup() and then let the admin review the amount before collecting payment

#

I'm not sure if this answers your question

turbid glacier
#

Hm, gotcha, I don't think that setup flow sounds the same as the two-step process for payments. This also aligns with why our guide for the two-step process only shows using Payment Intents.

For your Setup Intent flow, I'd suggest your checkout page use one of these patterns:

small yew
#

I'd like to clarify, the only difference between creating elements for setupIntent and paymentIntent is the mode. If I am using a setupIntent I set mode to setup. That is the only difference?

turbid glacier
#

That's the key one yes, you may need to drop other parameters that supported your payment flow like setupFutureUsage. Hard to say definitively without understanding your payment flow fully.

small yew
#

Ok. So that was my next question.

#

So I am using setupIntent, and I want to allow the admin to submit the payment off_session in the future AND I want to store the payment method to the visitors account is that going to be an issue?

turbid glacier
#

No. That's the flow shown in our guide for using Setup Intents that I shared above.

small yew
#

Ok. I will review those documents. Thank you for your help.

turbid glacier
#

Any time!

small yew
#

I have an issue. I am trying to elements.update()

#

I need to 'disable' setupFutureUsage that was previously assigned. The only options I have are on_session, off_session

#

How do I delete this setting or disable it

#

Something like

#

elements.update({'setupFutureUsage':null});

turbid glacier
#

What do you see if you pass an empty string or null for that parameter?

small yew
#

I can't test it easily...but I will be able to in an hour or so

#

I will attempt that and see how it goes

#

Thanks again

turbid glacier
#

Just tested and confirmed, passing null for that parameter unset it.

small yew
#

great thank you

#

I just ran into a new error "Payment details were collected through Stripe Elements using payment_method_types and cannot be confirmed with a Setup Intent configured with automatic payment methods"

#

So I am passing in the payment_method_types when creating an elements

turbid glacier
#

That means your frontend and backend are using two different configurations, and they need to be brought into alignment. If you pass paymentMethodTypes when creating the Elements instance then you also need to pass payment_method_types when creating your intent.

small yew
#

Ok, I can pass that in

#

I also see 'automatic_payment_methods'

#

do I need to declare that false?

#

or .enabled=false

turbid glacier
#

No, I'm pretty sure passing payment_method_types automatically disables that, but I expect you'll see an error pretty quickly if I'm mistaken.

small yew
#

sounds good

#

there one issue I know I'm gonna have...

#

At some point I need to get the payment_method_code to save to an account

#

However, because I switched to confirmation_tokens I no longer have that

#

Is there an easy way to get it?

#

I would like to avoid getting all payment_methods on a customer level

turbid glacier
#

What is a "payment_method_code"? And what are you referring to here when you say "account"?

small yew
#

sorry

#

I can't keep track of all the variables

#

So I mean 'payment_method'

#

and account, is a user in my database

#

which will have payment_methods saved to them

#

So, if a customer saves their payment for future usage...I was planning on saving the payment_method.id into my db so it can be selected later for usage.

#

however I don't have that value any longer because I switched to using confirmation_tokens.

turbid glacier
#

You mentioned confirmation tokens again, so is this back to talking about your two-step payment flow? Or are you looking at the Setup Intent flow with server-side confirmation?

small yew
#

I am using both paymentIntent and setupIntent with confirmationTokens

#

Does that answer your question?

#

Both checkout flows are also two step

#

both flows ask the visitor if they want to save payment to account if they are logged in

turbid glacier
#

It doesn't, because we don't have a two-step flow for Setup Intents. So I'm trying to understand if you're using this server-side confirmation flow for Setup Intents, which is the only time you use Confirmation Tokens and Setup Intents together.
https://docs.stripe.com/payments/finalize-payments-on-the-server?platform=web&type=setup#web-collect-payment-details

Regardless, the place you're likely going to want to look for that ID is on the intent that was used once you've confirmed it. Both Setup Intents and Payment Intents have a payment_method field that holds the ID of the payment method that they used/created.

random pythonBOT
#

hendr1x_confirmation-tokens

small yew
#

Ok. That's what I'm looking for

#

I'm creating setupIntent server side, confirming via the frontend

#

WHen I say two step, I mean how my checkout process flows.

#

I think it might mean something different to you and your system

turbid glacier
#

Yup, I'm very specifically referring to our one particular two-step confirmation flow:
https://docs.stripe.com/payments/build-a-two-step-confirmation
where details about a payment method must be collected in order to know what to charge the customer (for scenarios like: changing different fees per payment method type, adding in tax after collecting billing address details, etc)

There isn't a parallel for that for Setup Intents, because creating the Payment Method is the outcome of a Setup Intent's lifecycle, there isn't anything more that needs to be done once payment method details are available. This is from the Stripe side, there may be more things to do in your flow once you have those details.

small yew
#

Ok. That makes sense.

turbid glacier
#

If you're confirming a Setup Intent client-side, you don't need Confirmation Tokens in that flow.

small yew
#

My understanding is that confirming will reduce the need for handling authentication when I try to process a payment in the future

#

There is a field to submit a confirmation_token to confirmSetup

turbid glacier
#

That's for if you're confirming the Setup Intent server-side.

small yew
#

It's in the JS docs

turbid glacier
#

Which is mutually exclusive from the elements parameter, and if you're confirming client-side it's much easier to just pass in the Elements instance.

small yew
#

So, at this point I don't have the elements object any longer

#

that is a different page

turbid glacier
#

Maybe I'm missing some context about your site, but I wouldn't build it that way. If you're doing client-side confirmation, I'd use one of these flows:

Neither requires the use of confirmation tokens, and once you confirm the intent you have the ID of a Payment Method to use downstream rather than needing to handle a Confirmation Token.

If you absolutely need to split the collection of payment method details and confirmation of the setup intent, then that's diving down undocumented territory and some we'll likely need to go through some trial and error.

small yew
#

I wish you guys didn't have setupIntent and paymentIntent be so different

#

I was only alloted 2 days to work on this...I'm over 8 days in and I worked all weekend

#

I can't recode everything at this point and try to support two completely different flows

random pythonBOT
small yew
#

no need to catch up

#

you can close this thread

#

I'm all set

#

If you have the ability to thank toby for me