#luna-dana_best-practices
fleet flameBOT
đ 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/1245744802524430406
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
dry gazelle
Currently, each therapists has a subscription that is adapted to their needs "council of therapist free subscription", "classical subscription", etc.
When we have a group practice of for example 9 people. We will have 9 quantities of for example product : Group practice - Tier 2 (monthly) ⢠plan_OctTFBa4hOFQwy. The issue we are having is that the 9 subscriptions are all linked to the same SUBSCRIPTION ITEM ID since there are the same product and therefore each of the 9 items can't have metadata associated to it. We could only associated metadata to the SUBSCRIPTION ITEM ID which englobes the 9 subscriptions.
We want to shift to coupon code to better handle the pauses, free trials and reasons behind discount for analytics. We would therefore have to shift everyone to a standard 150$ subscription and then apply coupon based on the case (i.e group practices get 75$ off and would be applied coupon "GP - 50% off")
Our options are the following:
1.Shift everyone to classical subscriptions with corresponding coupons and have multiple quantities for GP (as we have now). Populate the metadata field of the subscription with each portal id: metadata={therapist1id:portal_id1, therapist2id:portal_id2,etc.} The issue with this is that if one person of the group practice cancel, it is harder to go update the metadata and track who is paying for who.
2.Shift everyone to classical subscriptions with corresponding coupons and create a different product for each member in the same subscription of the GP (GP member n1, GP member n2). Populate the metadata field of the subscription item id this time with the corresponding portal id: metadata={therapistid:portal_id}. In this case, we can better track who is paying for who if one cancels since the subscription item id can just be deleted. The downside is that we need to create a lot of new stripe product
3.Shift everyone to classical subscriptions with corresponding coupons and create n different subscription for a GP of size n. Populate the metadata field of the subscription with the corresponding portal id: metadata={therapistid:portal_id}. In this case, we can better track who is paying for who if one cancels since the subscription can just be deleted. The downside is that the person paying will receive n charges on their credit card instead of one large charge. This can cause problems when the GP are of large size
do you see another way of going around this ?
civic mirage
Yeah you could store the therapist: portal id mappings in your database instead of in the subscription's metadata
dry gazelle
yes but the problem we have if for group practice. If someone pay for someone else we need to track this
imagine I pay for 5 people. We store the mapping and then of them leaves, we need to automatically know the fifth person is not paying
civic mirage
Not sure I understand. Why could you not track that in your own db?
dry gazelle
we have no link between stripe and our db
dry gazelle
yes but our issue is how we map
becaue one customer in stripe can pay for n people in our database
civic mirage
Yeah and you could keep track of that
dry gazelle
and if one customer churns, the stripe subscription would be updated ?
civic mirage
You'd need to update the subscription
dry gazelle
another question i have. Can I put my prod data in the test env ?
dry gazelle
this is another problem. it is very hard to test stuff
civic mirage
You shouldn't need to use prod data though
dry gazelle
to test our mapping with our system I need to right customer_ids
When I have quantity = 2 of the same product, could I still update the metadata field of each product or not ?
Thank you for your help! It is very much needed and useful!
civic mirage
to test our mapping with our system I need to right customer_ids
Well if testing you should use test customer id's