#pacher2k-Subscription

1 messages · Page 1 of 1 (latest)

cursive tusk
#

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

worn narwhal
#

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?

undone sentinel
worn narwhal
#

jinx !

#

anywho, what I was wondering, is if there are any additional things you generally recommend to also store in your database

undone sentinel
#

nothing I can think of really

worn narwhal
#

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?

undone sentinel
worn narwhal
#

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?

undone sentinel
#

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

worn narwhal
#

aaah

#

makes sense

#

thank you for the quick and helpful responses!

#

hope you both have a wonderful week 🙂

worn narwhal
#

does it make sense to store the subscription ID, or would you just fetch this on demand via the customer id?

undone sentinel
#

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