#brel_best-practices
slate swiftBOT
👋 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/1285923707696451637
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- brel_best-practices, 1 day ago, 11 messages
- brel_api, 1 day ago, 11 messages
granite blade
You'd look at using this flow to save cards, and then the Payment Element supports displaying this cards for them to use them for future payments: https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements#save-payment-methods
hollow narwhal
Thank you
what about this? Can this be used instead or is not recommended?
this doesn’t even require client secret
granite blade
No, don't use those methods as they don't handle 3DS/auth which may be requested by the bank when saving the card
Your integration will require a front-end component via Stripe.js to initialise a Payment Element (to collect card details) and confirm the Setup Intent. Then process then generates a reusable Payment Method object (pm_xxx)
hollow narwhal
Ok I was just wondering where is it supposed to be used or is it deprecated?
granite blade
Well it tokenises payment info/card details into a pm_xxx object, but it doesn't actually validate that the card exists with the issuer/bank, nor does it facilitate 3DS/auth flows. It's just an older function that is still relevant for some merchants but most should not use it and follow the guide(s) I linked
granite blade
Sure!
hollow narwhal
I want the possibility to mark the card the customer is creating as default
how can I define that in the creation
granite blade
Sure, you can use this field on the Customer object – it's not something you set on the Payment Method itself: https://docs.stripe.com/api/customers/update#update_customer-invoice_settings-default_payment_method
hollow narwhal
The problem is that I want that card to be marked automatically as default since the moment I create it
is there a way?
granite blade
There is not no
You can trigger the related API call in an async webhook or something, listen for setup_intent.succeeded events and then update the cus_xxx
hollow narwhal
The problem is that I want it to happen instantly on the frontend as immediately after the card details are filled it should also fire a create subscription operation on my backend
granite blade
When you say 'set as default', what exactly do you want to set it as a default for?
Also, if you're collecting a card for an immediate subscription/payment you don't need a Setup Intent
hollow narwhal
I wanted to make the card as default so that by the moment I create the subscription for that customer I would already have a default card to charge him for
what do you suggest should be a flow without setup intent?
granite blade
Just create a Subscription which handles the intent creation for you: https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements
slate swiftBOT
granite blade
You can set payment_settings[save_default_payment_method] parameter and it'll save the card to be used for recurring payments for that subscription
granite blade
The Setup Intent flow is only really needed if there is no immediate payment/subscription and you're just saving the card. In this case there is, so to avoid multiple intents just need the one the subscription generated
hollow narwhal
ok so in case of the subscription it will be a payment intent generated behind the scenes
different from setup intenet
I can continue to use setup intent for adding cards though
granite blade
It depends – if there's an immediate payment yes. Otherwise if there's no payment (trial, 100% discount) then we'll generate a Setup Intent. Your code needs to handle that depending on your requirements
round blaze
hi! I'm taking over this thread. let me know if you have any other questions.
hollow narwhal
thank you. What I need is that for the first ever subscription and the first card customers add on the creation of that subscription I want that to became default for that customer. How can I handle this?
round blaze
you can either save it on the Subscription with this: https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method
or you'll need to make an extra API call after the Subscription is active to update the Customer's default payment method here: https://docs.stripe.com/api/customers/update?lang=node#update_customer-invoice_settings-default_payment_method
hollow narwhal
the first option makes the card default to customer or to subscription?
I am interested to be it default to customer so that on upcoming purchases or subscriptions the customer can be charged automatically on the default card
round blaze
the first option makes the card default to customer or to subscription?
Subscription.
hollow narwhal
and if it is default to subscription what happens if that card gets removed? What card will be charged on upcoming subscription charges?
round blaze
the priorities of payment methods for Subscription is explained here: https://docs.stripe.com/api/subscriptions/object?lang=node#subscription_object-default_payment_method