#gold3n_best-practices
1 messages ¡ Page 1 of 1 (latest)
đ 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.
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.
- gold3n_best-practices, 21 hours ago, 6 messages
hello! you'll want to use a buy button where you can pass an existing Customer id
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?
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
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)?
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
I don't want to allow my user to have more than a single subscription! I am glad with that behavior. The problem is that when this user cancels its subscription, and then wants to re-enable it, how can I allow him to do that without having stripe creating another customer?
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
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
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
Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.