ahemadabbas-d_docs

[gusty maple]

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

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

[pine hearth]

hi! have you considered passing an existing Customer object cus_xxx when creating the CheckoutSession, then?

https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-customer

[shadow olive]

No, i dont want to pass

[pine hearth]

then what do you want? A Subscription requires the existence of a Customer object.

[shadow olive]

Because i have no information of the customer until the checkout is completed

[pine hearth]

I'm totally lost, sorry.

if you use mode:subscription we will create a Customer object automatically for you as part of the Checkout process. Otherwise, you can pass an existing Customer object if you already have one.

[shadow olive]

Example:-
[e-mail] makes a checkout for the subscription
Stripe creates a new customer
now again
[e-mail] make a checkout for the other subscription
Still stripes create a new customer
Instead of it i want to attach the subscription to that existing customer
Just like payment mode

[pine hearth]

then you need to build something in your website that authenticates the user, for example they log into an account before they can pay, and in your user database you store the ID cus_xxx of their existing Customer. And then you can pass that existing ID when creating a CheckoutSession for the logged-in user.

or even better, don't use Checkout at all for the existing user and instead redirect them to the customer portal to edit their existing Subscription. https://docs.stripe.com/customer-management/portal-deep-links

[shadow olive]

Right, but i want a single page checkout so the stripe element is mounted from the start

Without any pre details

[pine hearth]

makes sense but there isn't really a solution like that; if you want to avoid something like this then you will need some user authentication.

[shadow olive]

So summarizing stripe can't attach the customer from the email in subscription mode like payment mode when checkout session is completed

[pine hearth]

I'm not aware of what functionality you're talking about in mode:payment that works differently, I'm not aware of anything like that.

[shadow olive]

Example of payment mode:-
[e-mail] makes a checkout for the payment mode
Stripe checks from the email if a customer is already existed if yes then attach the payment to it otherwise create new
While in subscription mode customer are always newly created

[pine hearth]

Stripe checks from the email if a customer is already existed if yes then attach the payment to it otherwise create new
that's what I mean, I don't think we do that.

[shadow olive]

Well i have tested both the scenario and i can confirm it

[pine hearth]

fair enough! I think there's confusion and you're thinking of https://docs.stripe.com/payments/checkout/guest-customers , which is not quite the same thing.
either way, for subscriptions(and mode:payment where you're using customer_creation:"always" ) , you need to build your own authentication layer for your use case.

[shadow olive]

I'm not using customer_creation:"always"

And i know about guest customers and yes those are different things

[pine hearth]

I know you're probably not, I was just giving a complete answer. It's relevant because mode:subscription always uses customer_creation:"always" implicitly.
fair enough if you believe we have a feature like this which is automatically de-duping customers and so on, I can't say much without seeing an example of what you're talking about. Like I said, for Subscriptions nothing like that exists really and you need your own authentication layer.

[shadow olive]

How can i show you the example?

[pine hearth]

maybe an example cus_xxx Customer ID where you say we detected that Customer existed already and attached a new payment intiated via Checkout to that customer instead of creating a new one?

[shadow olive]

Okay, please wait