#geekcorner_subscription-duplicate

1 messages · Page 1 of 1 (latest)

cinder havenBOT
#

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

📝 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.

woven pine
#

Oh it's you again? I hope I don't bother you!

random zephyr
#

@woven pine I would recommend using a cookie/browser session to "remember" the person/customer. It's a bit similar to what you likely do if someone is "logged in" on your website and then reloads the page but you remember who they are.
Does that make sense?

#

geekcorner_subscription-duplicate

woven pine
#

that may make sense indeed

#

but isn't there another foolproof method?

#

would save the subscription intent in the database work instead?

random zephyr
#

Ah sure I would definitely store all the information in my database. But you still need to map that Subscription/intent to the person browsing

woven pine
#

i'd send the intent to my client when they fetch the intent endpoint shouldn't i?

random zephyr
#

Yes, but you were worried about someone reloading the page. When they reload you need to identify who it is and what they were doing before. But yes it's definitely a good idea to store the information in your database and then load it from it

cinder havenBOT
woven pine
#

i would save in the user actually

mellow vessel
#

Hi there 👋 taking over, as my colleague needs to step away

When you say "user" what do you mean?

woven pine
#

in my "user" account table

#

thinking about it but how would I make sure the subscription starts when the user confirms its payment method and not before? (using docs step 5)

mellow vessel
#

We always recommend listening for the relevant webhooks (invoice.paid in this case is probably what you're looking for). This acts as the best source of truth when syncing your database and provisioning services

woven pine
#

of course that's planned, but that doesn't really answer the question

#

is there a way to create the subscription as "pending" then start the 14 days trial period on demand (in this case once the user submits the subscription)?

mellow vessel
#

Can you be more specific? Like, having a step-by-step explanation of what you're trying to do would be most helpful

woven pine
#
  • user picks a plan
  • my backend creates a subscription (but puts it in a pending-like mode)
  • user submits its payments details
  • my backend tell stripe to start the subscription and 14 days trial
#

clear enough?

mellow vessel
#

The docs you posted are sufficient to create this flow, the only difference is you would add a trial period when you create the Subscription

woven pine
#

i rather ask the payment details before starting the trial, similar to discord if that's possible

#

otherwise, would setupIntents be the way to go?

mellow vessel
#

Ah, good point, sorry. Yes, you would need to use Setup Intents in place of Payment Intents here, which ensures you collect the payment method without charging it

woven pine
#

okay, thanks!

mellow vessel
#

Sure thing!