#aaron_api

1 messages ¡ Page 1 of 1 (latest)

pale remnantBOT
#

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

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

rapid hamletBOT
#

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.

craggy moth
#

Basically we have a case, similar to Stripes Pricing Tables feature, where we want customers who use our embeddable tables to be able to pass a customer_id as simply as possible (these people can't code) without exposing security vulnerabilities.

#

But we can't find a way for them to do this. If we allow them to pass a customer_id as a URL parameter or anywhere on the front-end, really anyone can pass a customer_id and imitate someone else which obviously we can't do.

Is there any kind of solution to this? Or are we SOL

stark prairie
craggy moth
#

Does this essentially just pre-fill the checkout field with their email?

stark prairie
#

Yes

craggy moth
#

Okay so the issue we're having is this.

We create Checkout Sessions when users use our pricing tables right, which lets them put their email in Stripes Checkout page.
But when they put an email in that already corresponds with a customer, it just creates a new customer with the same email, it doesn't attatch to the customer with that email already.

#

So now a customer wants to upgrade their plan via our pricing tables, they click a higher plan, and now they have 2 different customers with the same email both with different active subscriptions

#

So ideally we're trying to set it up where if the same email is passed, it goes "oh you already have a subscription, lets go to the billing portal upgrade page instead"

#

But we can't figure that part out

stark prairie
craggy moth
#

Yeah

#

Well we're using our own pricing table, not Stripes

stark prairie
#

You would need to handle that on your end. I assume you store your data on your server, so you could need to search for a customer with that email.. then, if they have an existing subscription, you would use the Customer Portal, https://docs.stripe.com/customer-management/integrate-customer-portal. If not, you'd use your own Pricing table to create a subscription.

craggy moth
#

I think I am explaining badly to be honest hahaha

#

So our product is embeddable pricing tables. Non coders can build a pricing table with us and embed it on their site.
We want them to be able to pass a customer somehow on their front-end.

I guess this is what we're trying to do

  • If a customer is passed (somehow), we can direct that customer to their billing portal (if they exist)
  • if no customer is passed, we just create a Checkout Session

The problem we're hitting is

  • you can't pass a customer_id on the front-end securely

We're not storing their customer information on our side, and our customers are non-coders so we can't expect them to add app logic

stark prairie
#

Can you try expalining it again so I can try to unblock you?

craggy moth
#

So since our customers aren't savvy enough to pass an email or customer_id securely...

...what I THOUGHT would be a solution was

  • we just create a new Checkout Session every time
  • user just types in their email already associated with their customer on that stripe account
  • Stripe knows what customer that is, does some kinda validation, boom they're brought to billing

But instead Stripe just creates a new customer every single time, and now we have like a bunch of different customers all with the same email, and no way to tie them back

stark prairie
craggy moth
stark prairie
#

Yes!

craggy moth
#

This is exactly what we're looking for!

#

Is there an API we can use to enable that "One subscription per user" on the users Stripe account?

stark prairie
#

No, it is just the Dashboard setting

#

Glad it was what you were looking for!

#

It just took the two of us a couple of times to fully understand what we were trying to achieve

craggy moth
#

This is all being done through a Stripe App where users auth their Stripe with our app, and we want to try to keep the entire flow within-app

stark prairie
#

yeah, it is just a Dashboard setting

craggy moth
#

Is there anything we can use in the API to check if that setting is turned on on their account?

#

to direct them to their Dashboard to enable it if not

stark prairie
#

I do not think so, no. I am happy to share this feedback with the team to allow the Platform to be able to control the Checkout Settings. There is no promise here but I will share your feedback for their review.

craggy moth
#

that would be awesome!

#

Okay I have one more question

#

So if a user doesn't turn that One subscription per customer setting on, and now there's multiple customers under the same email with active plans, how does the Billing Portal Login Page know which customer to pick?

#

Because you have to type your email in there right, then it sends you a magic link, then it logs you in

#

But to which account?

stark prairie
#

I would highly recommend that you test this on your end to confirm

#

I'm happy to further debug issues/ talk about other integration paths after your test!

craggy moth