#gold3n_best-practices

1 messages ¡ Page 1 of 1 (latest)

leaden oreBOT
#

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

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

jovial kernelBOT
#

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.

versed echo
#

hello! you'll want to use a buy button where you can pass an existing Customer id

silk quail
#

Hmm I see. I could almost do all I needed with this payment links (buy.stripe.com/id), which required no code on my backend or frontend, but if I want customers to be persistent, despite stripe is totally able to leverage prefilled_email for that in some use cases, there is no other way around creating a session in the backend and use the checkout API?

versed echo
#

pretty much yep, you have to involve your backend server in some way if you want to pass in an existing Customer id

#

the buy button is slightly simpler in that you just have to create a customer session

silk quail
#

my point is I didn't need to pass any customer id for stripe to know the user with the same prefilled_email as before must be the same customer and therefore show them "you already have a subscription" screen, but ok I understand

#

And can I just generate a link on backend and use it on frontend without using all the buy-button.js machinery (with needing to pass CLIENT_SECRET and BUY_BUTTON_ID to the frontend)?

versed echo
#

Stripe generally doesn't de-duplicate customers for you. That feature that limits one subscription per customer is great if you only allow one subscription per customer email. It doesn't work if you want to allow your customers to have more than a single subscription.

If you use Checkout Sessions, when the customer clicks on the pay button, you generate a link on your backend server and then redirect the customer to that hosted page. You can't use that same link indefinitely, it'll expire

silk quail
versed echo
#

The answer is really to implement your own logic to check if an existing customer already exists, and create a new customer if not.

#

hrm, actually let me test what happens for that feature if you cancel the subscription and try to resubscribe

silk quail
#

it seems weird that there is a way to limit one subscription per user, but when user cancels using his own stripe hosted management screen, he cannot re-subscribe after that without needing me to change the whole logic and not use paymentlinks anymore

versed echo
#

it's a bit unfortunate but that's the current behaviour. if you would like to see a feature to allow Stripe to help manage/de-duplicate customer ids, I'd suggest writing to https://support.stripe.com/?contact=true to explain your use cases/feature requests as that helps the product team capture demand for prioritisation