#nancyyeh_best-practices
oak gladeBOT
đ Welcome to your new thread!
âąď¸ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime!
đ 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/1212190807319384074
đ Have more to share? You can add more detail below, including code, screenshots, videos, etc.
â˛ď¸ 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. Thank you for your patience!
open vaporBOT
Hello! We'll be with you shortly. 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.
- nancyyeh_code, 2 hours ago, 12 messages
- nancyyeh_api, 4 hours ago, 4 messages
jovial pasture
Hi there! Could you clarify what you mean by "save"? You'll want to pass the client secret from backend to frontend but there's no need to save it anywhere long term
obtuse vale
Hi @jovial pasture - currently we it all set up in the front end since we have stripe element pass in to use stripe.confirmsetup to create the setup intent
we then follow up with a few other things such as create customer and subscription on the backend.
if say the create subscription backend endpoint fails, but the confirmsetup has completed.
it seems like we have to check if an existing setup intent was created already
so we need to save or store the 'client_secret'
the first time it was created
what is the best pratice, in where to save it?
I saw this
const clientSecret = new URLSearchParams(window.location.search).get( 'setup_intent_client_secret' );
as a sample code, so is the best pratice to save in search params?
jovial pasture
So after you confirm a SetupIntent, we'll redirect to your return URL and append setup_intent_client_secret to the URL. That part of the docs is retrieving the client secret from URL params in order to call retrieveSetupIntent
Let's back up a bit. I'm a bit confused about your flow. Can you share more details about SetupIntent creation? If your goal is to set up a Subscription, why not create the Subscription first and use the client secret from the latest invoice's PaymentIntent?
obtuse vale
Current flow =>
FE: payment element is used,
[on click submit]:
- check if there is in existing setup Intent [?]
- if not, we use the stripe.confirmSetup to get the setupIntent. [save setup intent client secret somwhere, but where?]
- we then have backend endpoint to => create stripe user, create subscription (with or without promo code)
My case here is: if step 3 fails (i.e. not valid promo code), but step 2 succeeded. Then there is an existing setup intent, so when we retry, we need step 1 to check if there is an existing setup intent. If so, we skip step 2.
jovial pasture
This doesn't really make sense to me. For # 1 above, does this mean you're using the deferred intent flow to create a PaymentMethod first and then create a SetupIntent server side? For # 3, why not create a customer first? Also for # 3, how soon after are you typically creating the customer and subscription?
obtuse vale
@jovial pasture - step 1 -3 is all done on submit
jovial pasture
Could you share a SetupIntent ID?
obtuse vale
seti_1OobACIt5oCpEszukEp8TAUX
this is a successful sign up ^
what I am trying to do is for the first time the customer sign up
we collect their payment information, create customer, create subscription on to the customer
jovial pasture
Gotcha. I recommend doing this instead: https://docs.stripe.com/billing/subscriptions/build-subscriptions?ui=elements
No need to create a SetupIntent followed by a Subscription. You can just create a Subscription from the start and use latest_invoice.payment_intent.client_secret to render the PaymentElement
obtuse vale
how does coupon play into this?
jovial pasture
When you create a Subscription, you can pass a coupon. Do you have a more specific question?
open vaporBOT
obtuse vale
so what's the difference between setup Intent and payment Intent
tidal bison
A SetupIntent is meant to save the PaymentMethod for future usage. A PaymentIntent is meant to collect a payment
obtuse vale
So if we do a subscription sign up for trial, do we collect setup intent or payment intent?
Also question, is there a problem caused if we create the customer at the time of subscription? why do we need to create the customer first?
tidal bison
If a subscription has a trial, you'll want to expand [0] the pending_setup_intent [1] when creating the Subscription and use that to initialize the Payment Element.
Your integration should be able to handle both SetupIntents and PaymentIntents though, you can take a look at step 6 and 7 in the example here : https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription#create-intent
[0] https://stripe.com/docs/api/expanding_objects
[1] https://stripe.com/docs/api/subscriptions/object#subscription_object-pending_setup_intent
obtuse vale
ok question => in the docs sent:
- collect payment method > create customer > create subscription > confirm subscription
https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription#create-intent - create customer > create subscription > collect payment method
https://docs.stripe.com/billing/subscriptions/build-subscriptions?ui=elements
what is the best approach in that, currently we have a trial period. We want to add support for coupon codes.
Our Current flow => which is number 1 above
payment element is used [client side]
----- on click submit ------
- [client side] check if there is in existing setup Intent [?]
- [client side] if not, we use the stripe.confirmSetup to get the setupIntent. [save setup intent client secret somewhere, but where?]
- [server side] we then have backend endpoint to => create stripe customer, then create subscription (with or without promo code), attached setup intent.
My case here is: if step 3 fails (i.e. not valid promo code), but step 2 succeeded. Then there is an existing setup intent, so when we retry, we need step 1 to check if there is an existing setup intent. If so, we skip step 2.
is there an issue with our existing setup?
tidal bison
for Subscriptions, you should use the Subsciption's underlying PaymentIntent or SetupIntent to collect the payment method details. Alternatively, if you don't want to create the Subscription first, you can use the deferred intent flow to collect the payment method details first then create a Subscription : https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription
In short, if a customer intends to make payment for a Subscription immediately, we strongly discourage creating a separate SetupIntent, then using the newly created PaymentMethod to create a Subscription. There are several reasons for this :
- Doing so results in additional (unnecessary) API calls which contributes to your rate limits as your business grows
- This can result in in customers needing to authenticate twice, once for the SetupIntent, and once for the Subscription payment which can confuse customers
for step 3, i don't recall the Subscription failing if the promo code is invalid, i think the subscription just goes ahead without a promo code being applied?
obtuse vale
correct => we added a custom promo code verification in step 3, and failing if promo code is invalid
hence we will go back to step 1/2 again
tidal bison
alright, what i said still stands though. I think for your flow you should consider using the deferred flow instead whereby you can validate the promo code is valid first, then create the Subscription
obtuse vale
So based on this doc, do you do the code validation between step 5 and 6 where you create a server side endpoint to validate it first, or would you combined it to one endpoint where you validate the promo code, and if invalid, you return error.
https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription