Multy

[fleet tiger]

afaik, the customer_email returned is essentially an arbitrary field, and could be entered differently every time by the user, and is not necessarily the email regisetered in your app

[leaden agate]

If that's the only link you set, yes. You could also create explicit customer objects and track those against use with checkout sessions

[fleet tiger]

so the returning checkout webhook I can link with my customer object, I did make a register for those

but in future months, there won't be a checkout session

[leaden agate]

Yep, assuming you provide a known customer id during session creation, that will be on the webhook data object too

[fleet tiger]

so how do I link the invoice with app user

[leaden agate]

What do you mean by app user?

[fleet tiger]

the user I have stored in my db

[leaden agate]

By the same customer ID you create for them, i would say

[fleet tiger]

so on their first checkout webhook response, I need to write that cus_X id onto my app user, as the canonical link ?

what if they don't pay, and then do a 2nd checkout later

basically I don't understand how I could have a user Bob, who uses his friend Steve's card at checkout.
In future months, as I get webhooks back from Steve's card / Stripe user, how do I know that's Bob's account ?

[leaden agate]

You have your app user multy123

Let's say they go to pay for something

you look up if you have a stripe customer for them already

If not, you create one and record it, cus_456

If you already have one, you use that

You use that ID as the customer when you create the checkout session

and lookup your app user multy123 based on that same customer ID when you get session webhooks

Does that make sense?

[fleet tiger]

maybe that's the issue, I don't understand how / who Stripe is creating this checkout session for

    const session = await stripe.checkout.sessions.create({
        mode: 'subscription',
        line_items: [
            {
                price: priceId,
                // For metered billing, do not pass quantity
                quantity: 1,
            },
        ],
        client_reference_id: checkout_uuid,```

I'll check docs again

[leaden agate]

So in this case you'd to provide a customer parameter explicitly, if you wanted to track that

otherwise using the reference ID is fine too!

[fleet tiger]

but in that case Stripe still doesn't have a way to track who this user is on their / your end it seems

it's just an anonymous purchase which happens to have an email on it

so yea it seems like I do need to inject some key / id from my app logic (not just the client ref id) into Stripe

so that it can be echoed back to me in future

[leaden agate]

You would create a customer up front if you want to do that: https://stripe.com/docs/api/customers/create

Then provide the ID

(and store it in your system for lookups)

[fleet tiger]

ok that does make sense, I think I can do that
just for clarity though - does Stripe key it's users by email?

it seems like you could have the same email address being used for multiple cards / Stripe accounts

well - I know my personal Stripe account is email, but then I could have multiple customer_email records inside it

[leaden agate]

No, we don't. You can have the same email on many customers, de-duplication is up to you to perform if desired

[fleet tiger]

ok tx for help

[leaden agate]

NP!

[fleet tiger]

    const session = await stripe.checkout.sessions.create({
        mode: 'subscription',
        customer: [customer object] / id string ?,
        line_items: [```
do I just add customer during checkout like so ?

[hasty stump]

Yes, if you pass the ID in that parameter, we will use the existing Customer