#rohrig-checkout-subscriptions
radiant steeple
I think I understand. That being said, redirecting to Checkout is less favorable than simply using the Customer Billing portal for handling upgrades: https://stripe.com/docs/billing/subscriptions/integrating-customer-portal
There is an example preview of the portal at the top of the page I linked that you can use to see if that would better suit your use-case.
That way you don't have to worry about duplicating subscriptions and customers on your end
wary hull
Sorry, I used the wrong term, I am using the customer portal. The question does remain the same
well maybe not . . . here is the doc I was following . . . https://stripe.com/docs/billing/subscriptions/build-subscriptions
If follow this doc exactly (I could be wrong 🙂 ) I will have the issue I described
radiant steeple
Okay, so if you followed that doc then you're using Checkout for new subscriptions and the Customer Portal for managing existing subscriptions. Is that correct?
radiant steeple
Okay, and you're trying to make sure that all new subscriptions created are associated with existing customers in your local database, is that correct? Since customers could theoretically navigate back to your website and start an additional subscription via Checkout on top of an active subscription that they already have.
wary hull
yes, but not only to prevent duplication, but the know who has subscribed at all.
If the webhooks come out of order, which I experienced during development, I don't have the customer_reference_id on the invoice.paid obj for example
radiant steeple
I may not fully understand the problem, since you should have a webhook handler that checks the Event type before doing anything with the payload. So, for example, it shouldn't matter if you receive invoice.paid before checkout.session.succeeded if your webhook endpoint has a handler that does X with invoice.paid events and Y with checkout.session.succeeded events.
Does that make sense? Or am I overlooking something?
Also, I have to run, but @unkempt otter is here to help with any follow-ups
wary hull
checkout.session.succeeded contains the cusotmer_reference_id. That I can use to match the stripe_customer_id to my local user. Once that webhook is handled, I have the connection between the two. . .
but the invoice.paid, does not contain the customer_reference_id . . .
unkempt otter
👋
wary hull
so, if invoice.paid comes first, I don't know for which of my local users the the event is for
hi hanzo 👋
unkempt otter
Let's take a step back from webhooks for a bit
Can you give me a short summary of the issue you're facing while I read up on previous messages?
wary hull
Please read from the top, and I can clear things up if needed.
unkempt otter
Basically, you're trying to make sure that the subscription that was created has been paid for and identify which customer paid for it?
wary hull
yes
quick note, I notice in the checkout, the user can submit any email they wish, which may differ from the email they used to register on my site. Also, I use different OAuth providers, in that case I don't always have an email associated with the user . . .
unkempt otter
Okay give me just a sec and I'll write up a response
wary hull
So attaching the stripe_customer_id to my local user for the initial "transaction" is a must
unkempt otter
So on checkout.session.completed event, you'll receive customer_reference_id as well as a subscription ID
https://stripe.com/docs/api/checkout/sessions/object#checkout_session_object-subscription
You can retrieve the subscription to check its status
https://stripe.com/docs/api/subscriptions/object#subscription_object-status
If you have payment_behavior set to default_incomplete when creating a subscription then subscriptions will only transition to status=active when the payment intent of the first invoice succeeds
wary hull
I got that 🙂
unkempt otter
does that help with your use-case?
wary hull
It doesn't answer the question
The question is about the "correct way" to attach the stripe_customer_id to the local user. Is the scenario I described above the correct way?
Is it necessary to build in a retry mechanism to account for non-sequential webhooks?
unkempt otter
Are you creating the customers before initiating the checkout session?
unkempt otter
Yes
wary hull
no
should I?
I don't see how the customer would be attach to the create session . . .
const session = await stripe.checkout.sessions.create({
billing_address_collection: 'auto',
line_items: [
{
price: price.id,
quantity: 1,
},
],
mode: 'subscription',
success_url: `${config.public.appDomain}/subscribe/manage?session_id={CHECKOUT_SESSION_ID}`,
cancel_url: `${config.public.appDomain}/subscribe/cancel`,
client_reference_id: customerId
});
that is how I create the checkout session. Even If I created the customer beforehand, I don't see a way to attach that information to this checkout session. I'm I making sense?
unkempt otter
You can pass in a existing stripe customer ID with the customer field
https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer
wary hull
😎 that's why you get paid the big bucks! thanks man. I overlooked that. So, the preferred way is to first create a customer, then the session. Is that correct?
You guys should add that to the guide.
unkempt otter
NP! 🙂 Happy to help
wary hull
just to confirm, this is the standard way to do it? I ask, because I make youtube videos, and my upcoming video I build this integration, and I don't want to teach people the wrong way of doing it.
unkempt otter
this is the most straightforward approach that I can think of, yes
