#franco-romano-losada_best-practices

1 messages · Page 1 of 1 (latest)

lusty valeBOT
#

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

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

jovial merlin
#

hi there!

lusty valeBOT
jovial merlin
#

if that's not possible, then maybe you can use some metadata on the Checkout Session object or PaymentIntent object to keep track of who made the purchase

solar basalt
#

Hi Soma, thanks for your help.

I understand. These are checkout pages that connected accounts of my platform would create, so no customer is known at the time the end customer visits the page.

The metadata could be an alternative, but the Stripe dashboard of the connected account would have multiple duplicated customers, right? Is that an issue in general?

tranquil lantern
#

👋 taking over for my colleague. Let me catch up.

#

I'm not sure I follow

solar basalt
#

Thanks! In my db I can imagine something like this:

export const customers = pgTable(
  'customers',
  {
    id: generatePrefixedPrimaryKey('cus'),
    storeId: text()
      .notNull()
      .references(() => stores.id, { onDelete: 'cascade' }),
    // userId: text()
    //   .notNull()
    //   .references(() => users.id, { onDelete: 'cascade' }),

    stripeCustomerId: text().unique(),

    name: text().notNull(),
    email: text().notNull(),

    firstOrderAt: timestamp(),
    lastOrderAt: timestamp(),
    lifetimeValueC: bigint({ mode: 'number' }).default(0),

    metadata:
      jsonb('metadata_json').$type<Record<string, string | number | boolean>>(),

    createdAt: timestamps.createdAt,
  },
  (t) => [uniqueIndex('unique_email_per_store').on(t.storeId, sql`lower(${t.email})`)]
);

But ideally the stripeCustomerId is one, not many... that's the problem I have with dupes.

I could go with raw PaymentIntents and Subscriptions but the Checkout Sessions API have everything I need, included taxes

#

I'm not sure I follow
Sorry, which part?

tranquil lantern
#

let's just take a step back if you don't mind

#

if I don't have the customer email and multi-step form is not an option
since you're using Checkout Sessions with embedded components you can actually do a multi-step form

#

you can collect the customer email and check whether you already have a customer with that email address and if not you create a new one, but in all cases you pass a customer ID to the Checkout Session creation

solar basalt
#

Yes, I mean "multi-step form is not an option" because I want to have everything at once, as there are a few fields. Just name, email and the payment method

#

Maybe I should think about this in other way. If I were using stripe hosted checkout, and one customer buys two different subscriptions with the same email (hello@test.com), would I have two customers in Stripe with hello@test.com email?

tranquil lantern
#

yes you could end up with multiple guest customers with same email

solar basalt
#

same email you mean?

#

I mean two stripe customers with same email

tranquil lantern
#

yes my bad

#

and if you're creating the Checkout Session in subscription mode than they would be customers and not guest customers

solar basalt
#

No problem. Okay, then what would be the best practice to handle the subscriptions management in your app for that one customer that has two customers in stripe?

tranquil lantern
#

as I said you need to collect the email before creating the checkout session

solar basalt
#

Okay, understood