#luka-finderle_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/1349351230446501918
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
I guess the Stripe concepts would remain the same as to whether it was for a friend or not โ you'd create a Customer that maps to the individual who'll pay and how you map that to a 'friend' in your system would be an implementation details
Perhaps you leverage metadata: https://docs.stripe.com/metadata
What happens if I pay for a subscription for a friend and they already have an active subscription? Will their already active subscription be canceled or will it be added to their existing one?
Nope, a Customer in Stripe can have multiple active subscriptions
So it's actually best if we don't show anything inside the app, but let the user go into Stripe and manage their subscriptions there?
Sure, makes sense I guess. You can manage that however you want, but there's no conceptual limit to 1x Customer (cus_xxx) havuing multiple active Subscriptions (sub_xxx)
Ok, thats great. Thanks a lot!
You can close this ticket
No problem, glad I could help!
Just one more question. In this case when I pay a subscription to a friend, can my friend see in his dashboard that I have payed the subscription to him?
I'm confused now, which Dashboard are we referring to?
Does every user have an active dashboard or some kind of a account details in Stripe to see all the history and other options about his subscriptions?
Not a Dashboard per se, only if they have a Stripe account which I don't think is relevant here. You're probably describing this: https://docs.stripe.com/customer-management
Ok, but can that mentioned friend see somehow in Stripe that I have payed a subcription to him?
Not really no, you'd need your own UI to convey that
Can you just clarify to me is it even necesery to create a stripe a account to pay a subscription?
No, not at all
I only mentioned that because you said 'active dashboard', so wanted to clarify we weren't talking about an account when you said 'user'
(e.g. some kind of Connect setup)
Ok, but how can Stripe now what data to show on this screen https://billing.stripe.com/p/session/test_YWNjdF8xR3kxaUZBbHF2S3B4SkN1LF9SdmZqN2Z6YlhvWnEzcmFhUGd2cnQ3bjU3QWo2Q2E40100gSF5gv6K when user enters this screen for the e.g. second time?
I don't know what you're asking me
The portal (the link you sent me) displays relevant subscriptions and other configured info for the Customer in question. The URL is generated for a specific Customer object (cus_xxx) so all the info there is scoped to one customer
So let's first confirm if the following is possible.
A user comes into our app and we open Stripe for them to pay for their subscription. After they pay for their subscription and come back into the app and after a few days they want to see when their next subscription charge will be. When they get to this screen, will they see that?
Ok, great. So somehow the Stripe window will show data exactly related to that user.
I'm asking how can Stripe now to which user to map the data if the user isn't created in the Stripe database?
It can't. You must give us a cus_xxx ID (customer) when you create the subscription, and that's who it is associated to. Whether that sub is for a 'friend' or themselves, we are agnostic to that
So it would actually be best if we show the user all the subscriptions he has in the application (something like history) and then when he clicks on the subscription to take him to the stripe and the stripe then shows him everything related to that cus_xxx ID we sent?
You don't need to leverage the portal (the link you sent). It's just a prebuilt UI to allow customers to manage their subscriptions within your application/business. You can build all that yourself via the API and get the more granular control and UI you likely need, just comes with more overhead for you. It's about trade-offs
But yes, that is how it works conceptually
I didn't think we should create our own portal, but we need to somehow show the user all the subscriptions they have in their application because as far as I understand, one cus_xxx ID is equal to one subscription?
No, that's not a limitation as I've explained several times
So we can arrange the logic so that when a user clicks on a subscription, for example cus_XX1 ID, we open a portal with data from only that subscription, and if they click on a subscription, for example cus_XX2 ID, we open one from the other. Did I understand correctly?
Or will I always send you the same cus_XXX ID for the same user and you will show all subscriptions in the portal?
Thanks for having nerves for me ๐
I don't know enough about your business concept (friends, etc) but how you map that in Stripe is important. Does the 'friend' need to be a Stripe customer if they're not paying for anything? If not, then that seems like a detail that is irrelevant to Stripe and is only important to your application
This. The portal session is scoped to the cus_xxx ID you provide and will only surface their subscriptions, payment methds, etc