captainskippah_unexpected

[cobalt glade]

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

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

[dreamy yew]

Is what intentional? Unclear from your message what is unexpected

We don't dedupliocate Customer records based on a unique email address, no. If that's what you're asking

[thin lily]

whoops sorry. i meant does passing customer_email as parameter when creating checkout session and stripe looking for an existing record with that email instead of like just "pre-filled" email and creating new customer record

[dreamy yew]

No – it'll just use that to create a new Customer record according to the customer_creation value on the session. If a customer already exists with email a@b.c then we'll just create another

[thin lily]

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

this one you can use if you want to reference an existing customer.

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

this one i assume should just pre-fill email as set by your app and create a new customer.

[dreamy yew]

this one i assume should just pre-fill email as set by your app and create a new customer.
It should do yes

[thin lily]

customer_creation however only works with payment and setup mode but not subscription

[dreamy yew]

Yes because a customer is always required for subscriptions so you can't configure that. If you don't pass customer then we'll always create a new one with details from the payment page

[thin lily]

to make the intent clear so we're both in the same page

i have env A (remote) and env B (local) and i want to test using same email in these 2 environments.

however having an existing record with the same email created via one of these 2 environments, creating a session and visiting it gives me:

You already have a subscription with us

message

[dreamy yew]

Then that's because you have this setting enabled: https://docs.stripe.com/payments/checkout/limit-subscriptions

[thin lily]

yes.

although with that setting, i'd expect that to work if i passed in an existing customer id instead.

because in these 2 environment setup, they are technically not the same?

say staging/qa env and local.

staging/qa could probably used that email but in my local setup i haven't yet.

hopefully you get the picture now?

[dreamy yew]

I don't know what staging/QA environments means in the Stripe context

[thin lily]

i will get back on that question...

stripe allows multiple customers with same email.

• cus_abc with email "[e-mail]"
• cus_def with email "[e-mail]"

passing in customer_email parameter with value of [e-mail] how would stripe checkout know which of these 2 will it use?

[thin lily]

just think 2 machine running the same app code.

person A running www.foo.com website on his machine

person B running www.foo.com website on his machine.

[dreamy yew]

Depends what you mean by 'use'? Use in which context?

[thin lily]

:\

[dreamy yew]

Well, in your scenario here we'd 'use' neither – Checkout would create a new record (cus_xyz)

[thin lily]

yes. i would expect that too. that's the ideal outcome

however instead i get this

[dreamy yew]

But if you mean which of the customer records are 'used' for the portal redirect as part of the subscription uniqueness feature, then it's the most recent one

[thin lily]

i think this answered it.

but that's unexpected i'd say

[dreamy yew]

Well because we check to see if there's any customers with that email and prevent signup, regardless of whether you pass a cus_xxx ID:

Stripe uses either the Customer object (if you provide it in the Checkout Session) or the email address to detect if a customer already has an active subscription.

[dreamy yew]

Not really, you said 'use'. Use could mean anything

That's how the feature works today – it checks for an existing subscription tied to either a cus_xxx record or the email address

[thin lily]

ooof. that's unfortunate.

it just seems inconsistent with how 2 customers share same email but then when creating checkout session it tries to use the most recent one.

[dreamy yew]

Inconsistent with what?

[thin lily]

inconsistent with the nature of multiple customers using the same email being allowed.

but when creating checkout session using the said email, it assumed the most recent customer is the one trying to checkout

[dreamy yew]

It's actually more a limitation of how the customer portal works – that determines which cus_xxx record to use for the email address

[thin lily]

i would instead just consider this as a feedback for now then.

for recap, i 100% expect this outcome if i pass customer parameter because that's being explicit.

if i pass customer_email instead which could be ambiguous in Stripe, this will be confusing.

instead i expect it to always create a user with that email instead.

not find the most recent customer with that email.

[dreamy yew]

I'll relay that feedback

[thin lily]

is there a public tracker btw? something like github issues?