#pacher2k-Subscription
1 messages · Page 1 of 1 (latest)
I believe plan status and current period end can be retrieved via Stripe API based on the customer ID, so you can leave it to Stripe to manage those information
Generally speaking, not storing them reduces the cost of double-management
in that case, you would query Stripe for every request to check if a subscription is active -> the customer is allowed to access the features they are paying for?
it's generally better to store that in your database, https://stripe.com/docs/billing/subscriptions/webhooks#tracking describes an integration pattern for that.
in "Tracking active subscriptions" (https://stripe.com/docs/billing/subscriptions/webhooks#tracking) you mention storing a current_period_end, which I assume is in addition to a customer_id and a plan
jinx !
anywho, what I was wondering, is if there are any additional things you generally recommend to also store in your database
nothing I can think of really
sweet!
when creating a Subscription and Customer through a Checkout Session, I see that the client_reference_id can be supplied to "reconcile the session with your internal systems".
is this where I would specify eg. the user_id that corresponds to the user in my database?
and will this field be returned in the checkout.session.completed webhook?
I would use metadata (https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-metadata) instead of client_reference_id but yes you can use it for that and yes it's returned in that webhook
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
oh, okay! it sounds like that's what it's for, but is using metadata an easier or superior way? I guess with metadata it would be visible in the dashboard as well?
yes metadata is more structured and appears in the dashboard
basically Checkout didn't support metadata when it launched and client_reference_id was the stopgap
aaah
makes sense
thank you for the quick and helpful responses!
hope you both have a wonderful week 🙂
does it make sense to store the subscription ID, or would you just fetch this on demand via the customer id?
it makes sense, sort of depends on where you'll be trying to get that information and if the latency of a GET request is important to your app in that flow