#dux_best-practices

1 messages · Page 1 of 1 (latest)

green zodiacBOT
heady voidBOT
#

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.

green zodiacBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1255579784109494384

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

narrow bay
#

in other words, are there advantages to using setup intents vs creating payment methods manually?

vagrant flame
#

I'm not sure I understand the question. Setup Intents confirm a Payment Method and set it up for future usage. Simply creating a Payment Method without using Payment Intents or Setup Intents doesn't do that.

narrow bay
#

can you elaborate on 'confirm a payment method and set it up for future usage'

#

thats the piece i'm missing

#

also, i only wear one shoe when i go out

vagrant flame
#

Confirming a payment method is essentially just validating that it's usable. When you confirm a Payment Method, you're asking Stripe to check with the issuing bank to make sure the information provided by the customer is correct.

Setting it up for future usage means that it can be used without the customer being present. You're basically saying "hey, this is a valid Payment Method and I intend to use it again without the customer being around to provide CVV/Zipcode"

narrow bay
#

🤔
so in our codebase, we create a payment method manually and add it to the customer.

we use this to bill recurring subs (obviously stripe handles the billing when its time to charge the customer)

but we also use this payment method when customers subscribe to other products (without needing them to input card data again)

we've never had an issue with that

is there some other use-case where the manually created payment method wont work?

vagrant flame
#

I'm not really sure how you're doing that, the description given is a bit vague, so it's possible you're setting up the Payment Method for future usage without realizing it. It's also possible that you're not and it's just working, which is possible though not recommended since it can result in higher decline rates.

narrow bay
#

hmmm...

#

lemme look at the code real quick and make sure we're not doing anything else

#

yea ok. so it looks like we just use stripe.createPaymentMethod and then we assign it as the default on the customer like this:

const paymentMethod = await stripe.paymentMethods.attach(
            paymentMethodId,

make payment method default

        const customer = await stripe.customers.update(
            customerId,
            {
                invoice_settings: {
                    default_payment_method: paymentMethodId,
                },
            },
#

so you're saying that it works, but not recommended

vagrant flame
#

Correct. How are you collecting the actual card credentials from your customer?

#

Are they just submitting a form you built on your website?

narrow bay
#

yea

#

we use stripe elements

#

but not the drop-in-form

#

we're migrating over to the drop-in-form stripe elements solution

vagrant flame
#

Ahhh, okay. Are you creating a Setup or Payment Intent in that flow? Or are you using the deferred intents flow (i.e. no payment/setup intent is created until after you create the Payment Method via Elements)

narrow bay
#

umm

#

i dont think we ever create an intent

vagrant flame
#

Like, what does your Elements code look like?

narrow bay
#

it doesnt do anything on the front-end besides create the payment method

#

we create a sub for the customer later in the process

#

and then they get charged by stripe using the default payment method i think

#

i have to dig into the code

#

which is why i'm asking about this. so its better to use the setup-intent to collect payment method info

vagrant flame
#

Right, I'm going to be a bit limited in what advice I can give without looking directly at the code, but at a high-level: yes, you should be using Setup Intents if you intend to charge the customer for off-session payments and not create a payment immediately

narrow bay
#

so we also have functionality in our site to allow a user to change their credit card

#

how should we do that?

#

create a new setup intent?

vagrant flame
#

For the new Payment Method, yes

narrow bay
#

and that will automatically attach it to customer and mark it as default?

vagrant flame
#

No, you'll need to still perform that as a separate action one the Payment Method is created

narrow bay
#

ok. so we create a new setup intent, which creates the new payment method (i'm gonna assume it automatically attaches it to customer if we provide a customer id in the request)

but then we manually mark that as the default payment method if we choose

vagrant flame
#

yes, exactly correct

narrow bay
#

cool thanks for the help!