#harry_best-practices
ivory zenithBOT
👋 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/1351842345070366802
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- harry_api, 8 hours ago, 61 messages
quartz sierraBOT
abstract charm
Our main questions:
Tracking Individual Purchases: Since Stripe tracks only the total quantity in the subscription item, is there a best practice for knowing which devices were purchased when? Do businesses typically track this externally?
Subscription Structure: Would you recommend handling these as:
One subscription with multiple items (one for Online Ordering and one per device type), adjusting the quantity as needed?
Separate subscriptions for each purchase to track them independently (considering this may lead to multiple payments on different billing cycles)?
Hey Toby 🙂
vestal summit
Hi 👋 yes, typically if you need to track when changes were made to a Subscription's quantity, that would be tracked outside of Stripe.
One possible alternative to that, is to structure the data you need as key/value pairs inside of the metadata field on the Subscription Item:
https://docs.stripe.com/api/subscription_items/object#subscription_item_object-metadata
https://docs.stripe.com/metadata
That would allow you to store data that is important to your flows on Stripe objects. If you rely on that being your source-of-truth though, then there will be additional latency in your flows when you have to reach out to us to get your information, which won't be present if you store this information on your end.
Whether this should be structured as one Subsccription with multiple items, or multiple Subscriptions, is up to you and your business needs.
Both approaches will charge your customers on a recurring basis, but they will be represented in different ways in our UIs if you're using our prebuilt UIs (like Checkout Sessions or the Customer Portal). If you're building your own UIs, then you have more flexibility to show either model as you want to your cusotmers.
If you have specific business requirements that you need to satisfy, and can share those with me, then I may be able to give a more specific answer.
abstract charm
We do store the subscription items on our end, the main issue is knowing which item (for example device 1 out of a QTY of 4 against the single subscription item) was purchased when etc. We can add our device ids to the subscription line meta data, e.g device_type_1_product with a qty of 4, meta data contains 4 device ids, but say they purchase another one in the future, the device id would just get thrown into a mixed bag of ids if you see what I mean?
vestal summit
Then it sounds like you'd want to track purchase dates in the metadata as well?
abstract charm
I feel like the most logical way would be to have one subscription item line per device, so I can then say on our end that this device points tot his subscription line, but the API rejects when trying to add the same product/price_id to to the same subscription?
vestal summit
Correct, you can't have multiple Subscription Items in a single Subscription that are subscribed to the same Price.
abstract charm
Could you provide some clarity on why you cannot add the same product/price_id to the same subscription multiple times (as seperate lines). I think knowing why that restriction is in place might help me understand why the metadata way is the correct way to do it?
As I think thats whats a bit jarring to me, that seems the most logical way of doing it IMO?
vestal summit
I don't have the specifics of why that decision was made when the product was built, but in general you'd just increase the quantity of the existing Subscription Item instead.
abstract charm
is it possible to add a minimum length to a subscription item? Say we wanted to have device licenses be a 6 months minimum term?
vestal summit
Can you elaborate?
Subscriptions recur indefinitely, unless they're canceled. If you don't want to let the Customers cancel them in the first 6 months (and are legally allowed to enforce that restriction where you're operating) then you wouldn't expose any cancellation flows to your Customers before then. That's not controlled by any sort of parameter/field on the Subscription object.
abstract charm
okay I see, reason for asking is because it related to main my question, and that we wouldn't know which device has 3 months left as its just a mixed bag of ids in the meta data if you see what I mean?
vestal summit
If you want to track this with metadata, then you'd have to figure out how to put all of the information you need to track within that field. I don't know your business requirements as well as you do, so I don't know what all that entails. metadata accepts up to 50 key/value pairs, so you can put a lot in there.
If that isn't enough to track all the nuances of your device lifecycles that you need to though, then this sounds like something you'll want to track on your end.
Like you could store:
device_1_id: devices_id_goes_here
device_1_purchase_date: device 1 purchase timestamp goes here
device_2_id: ...
abstract charm
I'm more asking for advice on the best practise for this sort of setup, a different support member yesterday also suggested creating new price_ids per device but don't think that sounds like the best option
For example say for the devices you'd recommend seat pricing right? Say a company sells seats for their software, user buys 10 seats which then are assigned to users on the companys end, the company then reduces their subscription to 5, would they just disable 5 random seat users on their end?
where as if they were seperate line items, you could say remove this user, remove that user specifically?
vestal summit
They can't be separate line items though, unless you create a unique Price for each one, and in that case you may even want to create a separate Product for each so you can give them different descriptions.
abstract charm
yeah I did have a similar thought but that sounds like overkill as they are all the same product
vestal summit
Again, it goes back to whether you're using our prebuilt UIs (in which case without unique descriptions it may be hard for your customers to tell which line maps to which specific device like you're hoping), or if you're building your own UIs in which case you can abstract over the Stripe object models and represent the details as appropriate for your flows.
abstract charm
We are using our own UIs at the moment.
Okay so
Just to confirm, it is impossible to have the same product multiple times on the same subscription via any method/price type? And it’s just a case of having to manually track specific device models to specific lines, you just get a qty field no matter if I choose seat based pricing, flat rate etc?
And the price types all behave the same (qty field) it’s just a case of handling price differences against that subscription line item?
vestal summit
Just to confirm, it is impossible to have the same product multiple times on the same subscription via any method/price type?
The same Product can be used for multiple Subscription Items, the same Price cannot be.
And it’s just a case of having to manually track specific device models to specific lines, you just get a qty field no matter if I choose seat based pricing, flat rate etc?
I'm not too sure what you're asking here, since seat based (licensed within Stripe) and flat rate are opposing choices, you can have flat-rate licensed Price. You will want to track device details on your end from what I'm gathering about your use case, and let the Subscription mostly just handle creating the recurring payments for the customer.
And the price types all behave the same (qty field) it’s just a case of handling price differences against that subscription line item?
Again, not exactly sure what Price types you're referring to here. Licensed Prices use thequantityfrom the Subscription Item. Metered Prices use either Usage Records or Meter Events to track usage and determine how much to charge customers.
abstract charm
Okay gotcha. I am fine with implementing it that way, I just felt like I was implementing it wrong because I would have expected seperate line items for the same price_id would be a common want. So moving forward with that being impossible. Would it be best practise to show the user a list of devices they currently have paid for (say 4) then they can select a device specifically, I can disable that on my end and then just reduce the qty down to 3 on stripes end?
vestal summit
Yeah, that sounds reasonable.
abstract charm
okay cool I'll rock with that, thanks for your help Toby
vestal summit
Any time!
abstract charm
Sorry another question if you dont mind. Say customer buys 2 licenses on the 5th, they get billed for $10 per device per month, say they want another device on the 15th, I update the subscription to qty 3. The customer then gets billed the prorated amount for the new device (from the 15th) in their next billing cycle on the 5th?
vestal summit
Depends on what value you use for proration_behavior when making the update request, but by default, yes:
https://docs.stripe.com/api/subscriptions/update#update_subscription-proration_behavior
https://docs.stripe.com/billing/subscriptions/prorations
abstract charm
okay gotcha, so typically businesses would just grant access/license right away rather than waiting till the next billing cycle for the third device?
vestal summit
Depends on the business.
vestal summit
Happy to help! 😄