#jean-emmanuel-bois_api
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/1413084434252693566
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
๐ happy to help
if we can use both solutions (API integration + Stripe no code/low code)
yes you can
Ok thanks, however I am wondering if this would not affect the billing solution we use right now, let me explain:
-
Current solution:
-Users pay on our dashboard, which is connected to Stripe via the API.
-When an invoice is paid, then our current external billing solution (Quaderno) which is connected to Stripe, generates an invoice. Same thing if a credit note is generated in Stripe. -
New solution for concerned users:
-Users would now pay/manage their subscription via the customer portal, and purchase new plans by clicking on "subscribe to this paid plan" -->that would trigger a Stripe checkout session (only if the customer is new).
Question regarding the "2.":
-I think that invoices generated by Stripe for the 2 scenario would also generate a finalized invoice via our external billing solution once the invoice has been paid. Do you think i'm right? If yes, do you think there would be a way for us to avoid this duplicate? Maybe by creating another Stripe account for our new product version?
-Another question: is it best practice to use a Stripe checkout session only for new plan subscription? What should we use for a plan upgrade, if the customer is already paying a plan but wants to upgrade? I thought that Stripe checkout session would generate a new customer every time, I am correct?
Thank you very much for your assistance ๐
-When an invoice is paid, then our current external billing solution (Quaderno) which is connected to Stripe, generates an invoice. Same thing if a credit note is generated in Stripe.
whether you're using the API or the no/low code solutions we generate the same events
-I think that invoices generated by Stripe for the 2 scenario would also generate a finalized invoice via our external billing solution once the invoice has been paid.
yes that's correct
do you think there would be a way for us to avoid this duplicate?
no in both cases you would still have both since Stripe auto-generates invoices for subscriptions
oh you mean you don't want to use the external billing for the new subscriptions, right?
Another question: is it best practice to use a Stripe checkout session only for new plan subscription?
as opposed to what?
What should we use for a plan upgrade, if the customer is already paying a plan but wants to upgrade?
Customer Portal
I thought that Stripe checkout session would generate a new customer every time, I am correct?
Checkout Session can't handle upgrades
Thank you for your answer, currently reviewing it
Ok thank you very much for this confirmation
That's what I though as well, thanks for the confirmation
Yes, we don't want to use the external billing for the customers that will subscribe to our new product that I talked about
As opposed to Stripe Customer Portal I guess, but I think you answered the question below "Checkout Session can't handle upgrades"
Thanks again for your answers. So basically, yes technically it is possible to use both at the same time, but because Stripe would issue the same events for invoice generation and marked as paid, the customers using our new products would also create invoices to our external billing solution, meaning that we would have invoices duplicates (Stripe invoices + Quaderno invoices)
If we create a new sub account in Stripe, would that enable us to seperate the two scenarios and thus not have invoices duplicates?
We would have a Weglot 1 account with the old billing workflow, and Weglot 2 with the new workflow (customer portal + checkout sessions)
If you think it's possible, what are the consequences regarding Stripe's pricing? Would it be the same the as the current pricing we have? Or would we move the Stripe public pricing?
Thanks again
you can avoid the duplication on your external billing system
if that's what you're looking for
but I wasn't sure which invoices you wanted to remove
Ok thanks for the info, how exactly would that be possible?
If you think it's possible, what are the consequences regarding Stripe's pricing? Would it be the same the as the current pricing we have? Or would we move the Stripe public pricing?
we don't know anything about pricing on this channel unfortunately
it depends on how you're integrating with your 3rd party
Ok thanks, and if we remove our 3rd party completely? That means that we would rely on Stripe invoices for our rev rec/accounting processes (using Stirpe invoices + credit notes)
Would that be ok to have a custom dashboard communicating with Stripe via the API, and another dashboard for users using our new product on which they would have a button to access their Stripe customer portal and if they are new, be able to subscribe to our product generating a new stripe checkout session? thanks
Would that be ok to have a custom dashboard communicating with Stripe via the API, and another dashboard for users using our new product on which they would have a button to access their Stripe customer portal and if they are new, be able to subscribe to our product generating a new stripe checkout session? thanks
you can do both on the same account
there's no issue with that
the 2 integrations can work side-by-side
it's just that you will be maintaining 2 integrations
Ok, is there a way to activate Stripe Customer portal only for some users? Or we would have to enable Stripe customer portal for all users, but we would only give the Stripe customer portal access for users using our new product/dashboard?
I think at some point you could easily shift everyone to no/low code solution if that's the aim in the long run
Or we would have to enable Stripe customer portal for all users, but we would only give the Stripe customer portal access for users using our new product/dashboard?
Customer Portal is an access only feature
I mean that you don't enable it to anyone
That's the aim in the long run indeed, however our dev team is heavily developing the new product and they are also working on the new billing integration, so that's why Weglot 1 would not have this update yet
Ok, I thought it was a feature in the Stripe settings to activate
you either give your customers access through either a URL that you send them or via a button or a CTA on your application
Ok thank you very much for you answer, that's good to hear.
Another question regarding the customer portal: I saw that there could be some issue regarding the log in.
Can you confirm the following process:
-When a user is logged in on our website, and clicks on "access my customer portal", how does Stripe know which user is requesting access to its customer portal? The idea would be for them to NOT have to log in again. But one of the challenges is that our application can have multiple people connecting to the same accounts, with different roles (some people have editing roles, some have admin roles, some have billing roles) -->if i'm not mistaken, there is ONE email attached to a Stripe customer profile right? So if a billing user has a different email than the Stripe customer profile one, how will he be able to access the Stripe customer portal?
Sorry for the long messages and please tell me if it's not clear ๐
When a user is logged in on our website, and clicks on "access my customer portal", how does Stripe know which user is requesting access to its customer portal?
this is where low code comes in play
the no code requires login as you can see here https://docs.stripe.com/customer-management/activate-no-code-customer-portal
Ok so there would be a login issue for users having access to our app but that do NOT have the same credentials as the Stripe Customer profile right?
even if you prefill the email (https://docs.stripe.com/customer-management/activate-no-code-customer-portal#url-parameters) they would still need to confirm and they can change the email
for me the best solution for you is to integrate with the Customer Portal API https://docs.stripe.com/customer-management/integrate-customer-portal
and specifically use Deep Links https://docs.stripe.com/customer-management/portal-deep-links
this way you could control what user is connected (from the current session on your app) and you control which action you want them to do (e.g. update their PM, upgrade a subscription, etc.)
Ok and it would still be linked to the specific stripe customer id, meaning:
-A user of our app linked to a specific account would have access to the stripe customer portal but with a โ email than the Stripe customer profile, and would have access to only certain features (for example change payment method only)
If yes, how would the log in into the customer portal would be handled since this user would not have the same email address as the Stripe customer profile?
-A user of our app linked to a specific account would have access to the stripe customer portal but with a โ email than the Stripe customer profile, and would have access to only certain features (for example change payment method only)
it would work based on the customer ID. so you need to do the mapping on your side
We have the Stripe customer id on our side in our backoffice, but our users do not see their stripe customer id on their dashboard, so basically we would need to reference the role of the user, and the stripe customer id
If i'm correct:
-a user connected to our dashboard wants to access the stripe customer portal, when clicking on "access" via their dashboard, there would be a workflow on our end that would: 1. check the users roles and access rights (that would be defined by us), then, based on that, 2. create a stripe customer portal access via the api and giving him the permitted actions defined by the mapping we have done on our side
is that correct?
correct
Ok thanks, is it possible to create a flow using deep links but with multiple possibilities, for example if a user with the role "billing" connects, he can access the customer portal for paying the invoices, and update the payment method, whereas an "admin" user would be able to do all the customer portal features ?
I see in the deep links documentation that -d "flow_data[type]" needs to be equal something, but can we give multiple possiblites in one api request?
Ok thanks, is it possible to create a flow using deep links but with multiple possibilities, for example if a user with the role "billing" connects, he can access the customer portal for paying the invoices, and update the payment method, whereas an "admin" user would be able to do all the customer portal features ?
yes these wouldn't be configured by the deep links but instead you could configure a customer portal configuration per profile
Ok thanks, and so if I understand correctly, when a user linked to one account would want to access the Stripe customer portal, but with a different email than the one in Stripe customer profile, this would feasable right? There would not be an email verification code sent to the Stripe customer profile email right? Because the user would not have access to it since he would have a different role and email address than the user who created the Stripe customer profile.
hi! I'm taking over this thread.
Thank you, please don't hesitate if my question is unclear/incomplete
sorry for the delay. could you try to rephrase your question? I'm not sure I follow the issue.
Ok sure, we have multiple users that can connect to an account on our app. Some of them can use our app, and NOT manage billing information. Some of them can manage certain billing information, and others are ADMIN and can manage all billing information.
Depending on each roles, the users have their own credentials, which can be different from the the Stirpe customer profile email address.
My question is the following: if a user wants to connect to the Stirpe Customer Portal, but has a different email than the Stripe customer profile that is linked to this account, will they be able to access the customer portal and make modifications ? For example, user1 with the email "user1@weglot.com" wants to access the Stripe customer portal, but the Stripe customer profile email address is "admin@weglot.com", will user1 still be able to access it, without having to log in with the admin@weglot.com credentials?
what type of customer portal are you using? the no-code one, or the one using the API?
we are currently not using anything, but the idea is to use the no code one, but since we do have multiple users for one account in our web app, with different roles, your colleague told me that it would be best to use the customer portal via the API.
Do you have access to the old messages of this conversation by any chance?
it would be best to use the customer portal via the API.
yes I agree, this would give you more control, for which user get access to which feature, by creating multiple portal configuration.
Do you have access to the old messages of this conversation by any chance?
yes I do.
For example, user1 with the email "user1@weglot.com" wants to access the Stripe customer portal, but the Stripe customer profile email address is "admin@weglot.com", will user1 still be able to access it, without having to log in with the admin@weglot.com credentials?
if you are using the API, then the email address itself wouldn't matter. you just pass the correct Stripe Customer ID when creating the Portal, with the correct Portal Configuration.
threads get automatically close when inactive. but:
- you can continue to access the thread to read its content
- and you can easily reopen a new thread if needed
FYI I just deleted your latest message, to avoid sharing your email in a public space.