#_kevinx
frail parrot
It'll be null unless you pass a customer to create the session
Or require a customer to be created
mystic scaffold
based on what I read from the doc, if it's a new customer and subscription, session creates a customer by default right
mystic scaffold
not really because the customer is null
I thought once the session create a customer, there should be a customer ID at least
frail parrot
Yeah one should be created, but I think the customer param in the session object will still be null since you didn't pass one
Can you share the checkout session id so I can confirm?
mystic scaffold
cs_test_a14r1OAhKSa2XaFPvUwIzTzgT1cJIlaBGSNVByBC2AiKFhlpd4jQFKb1DT
frail parrot
Ah no I was wrong we do populate customer once you finish checking out
Use this endpoint to retrieve it: https://stripe.com/docs/api/checkout/sessions/retrieve
You can see that customer is populated
It won't populate until payment is complete though. So, the checkout.session.completed event would have the customer object
mystic scaffold
Thanks, does this mean information in session is not that important to be saved into local database?
because there is no reference value
frail parrot
Depends on your integration
Completely up to you on what's important to save
There are many people who rely on the checkout.session.completed event and store info from that
mystic scaffold
ok, let me ask this way, what is important in session that will be used again later on
frail parrot
Again, depends on your integration
I have no idea what you'll want to use later on
Here's what the object looks like: https://stripe.com/docs/api/checkout/sessions/object
You can see if you need to store anything from there
mystic scaffold
You are right, there are tons of info in checkout.session.completed
One more question, I noticed that the subscription status is still incomplete even with the checkout.session.completed, so does the event listing order in webhook matter? should I put the subscription case below checkout.session.completed?
frail parrot
The order of your cases in the code doesn't impact anything. That code is called once per event.
And event order isn't guaranteed
So your code will need to be able to handle any order of events
mystic scaffold
Great, thanks, how to read the time format here btw
current_period_end: 1690747836,
current_period_start: 1688155836,
Interesting, thank you 😄
frail parrot
No problem
mystic scaffold
Since you are a pro, can I ask, which events are key to a subscription that people normally have to listen?
I list them all here so it's easier for you to just remove irrelevant ones
account.application.deauthorized
account.updated
balance.available
charge.captured
charge.dispute.created
charge.failed
charge.refund.updated
charge.refunded
charge.succeeded
checkout.session.async_payment_failed
checkout.session.async_payment_succeeded
checkout.session.completed
customer.created
customer.deleted
customer.source.created
customer.source.updated
customer.subscription.created
customer.subscription.deleted
customer.subscription.updated
customer.updated
identity.verification_session.canceled
identity.verification_session.created
identity.verification_session.redacted
invoice.created
invoice.finalized
invoice.paid
invoice.payment_action_required
invoice.payment_failed
invoice.payment_succeeded
invoice.updated
issuing_authorization.request
issuing_authorization.request.eu
issuing_authorization.request.gb
issuing_card.created
issuing_card.created.eu
issuing_card.created.gb
issuing_cardholder.created
issuing_cardholder.created.eu
issuing_cardholder.created.gb
payment_intent.amount_capturable_updated
payment_intent.canceled
payment_intent.created
payment_intent.partially_funded
payment_intent.payment_failed
payment_intent.requires_action
payment_intent.succeeded
payment_link.created
payment_link.updated
payment_method.attached
payment_method.detached
payout.created
payout.updated
plan.created
plan.deleted
plan.updated
price.created
price.updated
product.created
product.deleted
product.updated
reporting.report_run.succeeded
subscription.payment_failed
subscription.payment_succeeded
subscription_schedule.canceled
subscription_schedule.created
subscription_schedule.released
subscription_schedule.updated
frail parrot
Likely you won't need all the ones listed, but that guide does a good job of going over all of them so you can decide which you need
mystic scaffold
Yeah, I went over this guild already, obviously checkout.session.completed is not even in there, that's why 😄
frail parrot
Yeah because that's only relevant if you use checkout
The above is specifically just for subscriptions
Many people do not use Checkout
mystic scaffold
ok, so for checkout, what are the key events that are relevant
frail parrot
Again, depends on your integration
I can't answer that unless I know what you need to store and action upon
Up to you to read that guide and decide based on your integration
Unless you need specific fields from the checkout session that aren't available anywhere else, the above guide should be applicable to you too
mystic scaffold
Got you, thanks
if a return customer comes back to use checkout again, do I need to provide the privous checkout session ID as reference?
frail parrot
You do, yes
Sorry no
Read customer id for some reason when you said checkout session id
mystic scaffold
seems I need to provide customer id instead then
frail parrot
You'd just pass the return customer's id to the session here: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer
brisk mulchBOT
mystic scaffold
Got you, thanks, so Stripe doesn't track customers with email etc. we need to track it and feed the api?
frail parrot
Yeah
You can technically have multiple customer objects with the same email
However, we do have a concept of a guest customer (tracked by email) for certain scenarios where customer id isn't passed: https://stripe.com/docs/payments/checkout/guest-customers
But generally that's meant to be a kind of backup way to group payments
Usually recommended you explicitly manage customer objects
mystic scaffold
One more question please, since you are so knowledgeable, I'm new to setup backend logic for subscriptions, for example, how to know if a user's status is active at any given time, do I rely on webhook event changes (assume it is active till event change the status) , or do I have to always check or periodically check (at the end of each day for example)
proven phoenix
Hello! I'm taking over and catching up...
Most people rely on webhooks to keep up to date with Subscription changes, others poll the API periodically, and some do both. Listening for Subscription Events with a Webhook Endpoint is recommended. More details here: https://stripe.com/docs/billing/subscriptions/overview#subscription-events
mystic scaffold
Thanks, I read various ways, some people say check if the timestampes is between period start and period end, some say relys on Webhook triggers, some says check periodically
proven phoenix
If you want to be robust about it you can use webhooks as your primary source of truth and back them up with a periodic check with the API to make sure nothing's out of sync.
mystic scaffold
ok, thanks, what is a good way to grand user access to resource once it's paid, for example, if a user paid, he/she can post max 5 post per month
proven phoenix
That's up to you, it's something you would build on your end.
You can do whatever makes sense for your use case and integration.
mystic scaffold
do you have any recommondations? 😄
proven phoenix
Can you ask a more specific question? Providing a useful answer requires more details, especially about any roadblocks you're hitting.
mystic scaffold
oh, never mind, I probably need to do some research on my own, thanks man
Is it ok to expose price ID on the front end?
proven phoenix
Yep, that's fine.