#brian_subscription-item-update

1 messages · Page 1 of 1 (latest)

glad tokenBOT
#

👋 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/1490755208936947716

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

short ruin
#

You can update Subscription Items through the Susbcription itself, whic allows you to use the Subscription ID

dreamy yacht
#

ahh interesting. That being said, would you say using a meter for seat-billing is an option too for "simple" sake of it or still keep quantity?

as a secondary follow up to it, what is the recommended way to handle compound subscriptions? Example use-case:

Plan: Starter ($9.99)

  • add-on A: $5.99
  • add-on B: $29.99

would it be better to create line items on the starter plan and track those line-item IDs in our database, or create individual subscriptions for each add-on price

short ruin
#

For per-seat billing, I think meter events are overly complicated. Meters are intended to track usage of a resource that updates hundreds of times (or thousdands/millions) per billing period.

#

In your case, I think separate licensed prices make the most sense

#

So, for your example

Plan Starter - Price 1 ($9.99/month)

  • Add-on A: Price A ($5.99/month)
  • Add-on B: Price B ($29.99/month)

Users can add the add-ons and see those line items added to their Subscription in the Invoices.

#

If that doesn't match how you were thinking of the add-ons, please provide a more specific example so I can review.

#

If you have multiple plans a user can subscribe to at the same time, each with it's own add-ons, you can use Line Item Grouping to help make that more clear to your users.

dreamy yacht
#

i think that'd be correct, a full use example would be something along the lines of:

Plan Starter - $9.99/month

  • Add-on SAML Login ($5.99/month)
  • Add-on MFA auth ($29.99/month)

we're a fairly simple SaaS in practice with the cashflow coming primarily from seat-based billing.

with the add-on approach would that be a matter of looking up the plan starter subscription and adding a line item for each add-on?

then just store that add-on item ID to our subscription info in the database, then primarily just doing something like:


if (organization.subscriptionId === whateverIdOfAddonIs)```
short ruin
#

Pretty much. If these services are billing per-seat, the combination of Add-ons + quantity should allow you to charge the correct amount. For the add-ons, you would Update the Subscription to add the new items - API.

For quantity updates, you could either update the Subscription directly or store the SubscriptionItem ID in your DB and use that to directly update the Subscription Item.

As for how you identify which Subscription to update, that would be up to you.

dreamy yacht
#

Makes sense so with the code sample I provided initially I should do a compound lookup? If I’m storing subscription id then I should find the subscription id and then a separate api call to update the subscription item from the subscription id?

short ruin
#

I think that would be the best way to be certain you are updating the correct Subscription Item.

dreamy yacht
#

Cheers! I’m currently away from my desk atm but I’ll post my solution here when I get back just to clarify again that it’s not more complex than it needs to be 🙂

short ruin
#

FYI, we close threads due to inactivity after ~45m of no chatter back and forth but if you get back before then I'll be happy to review your solution.

glad tokenBOT
#

brian_subscription-item-update

dreamy yacht
#

no worries I got back 🙂

const subscription = await stripe.subscriptions.retrieve(
organization.stripeSubscriptionId
);

const subscriptionItemId = subscription.items.data[0].id;

await stripe.subscriptionItems.update(subscriptionItemId, {
quantity: members.length + 1,
});

this would likely be the best way to handle it then right

short ruin
#

If you are certain that the first item in the list of items is the one you want, then yes.

It's a good place to start but you could also add more checks like validating the subscription.items.data[0].price.id.

#

If you want to ensure you are incrementing the quantity by 1, you could use subscription.items.data.[0].quantity also

#

e.g.

const quantity = subscription.items.data[0].quatity + 1

await stripe.subscriptionItems.update(subscriptionItemId, {
  quantity
});
dreamy yacht
#

makes sense, is there any downside to chaining it via 2 api calls, or would you recommend re-structuring our stored data to only retrieve it via a single api call?

and regarding discount codes, what's the best way to automatically apply them?

short ruin
#

makes sense, is there any downside to chaining it via 2 api calls, or would you recommend re-structuring our stored data to only retrieve it via a single api call?

It depends on the frequency of these updates but, in general, there isn't too much downside. If you are operating a very high throughput service, you might hit latency issues. For Rate Limits, Stripe treats GET and POST requests separately so the two API calls add to different buckets

and regarding discount codes, what's the best way to automatically apply them?

I don't know what you mean by "automatically apply them". In what conditions do you want discounts to be applied to Subscriptions?

#

Unfortunately it doesn't cover all use cases.

For instance, you can create Promotion Codes that apply specifically to an individual Customer by including the Customer's ID in the customer parameter when creating the Promotion Code

dreamy yacht
#

context would be say someone visits our pricing page and wants to upgrade to a plan let's say during a holiday, anyone that clicks "subscribe" when they get redirected to stripe checkout have whatever active code is available automatically applied;

ah nvm the docs show you can just specify the coupon ID!

final thought would be then if we enable the auto collect tax setting, does that activate stripe as an MoR from that point on, or only if we choose to pay for Stripe's tax service?

short ruin
#

final thought would be then if we enable the auto collect tax setting, does that activate stripe as an MoR from that point on, or only if we choose to pay for Stripe's tax service?

Stripe as the Merchant of Record is a separate feature altogether. Even when using Stripe Tax, I don't think Stripe is considered the merchant of record. But let me dig a little bit.

#

In our doc about filing and remitting taxes here: https://docs.stripe.com/tax/filing, the very first sentence states you (the merchant) are still responsible for your tax obligations. Stripe Tax is a tool that helps you calculate the correct amounts and helps with registration but does not transfer the legal responsibility for taxes.

dreamy yacht
#

interesting so that being said it might make more sense then for us to switch to Polar

short ruin
dreamy yacht
#

just came across that, from your experience do you have a generalized timeline usually when preview features get shipped as a "full release"

short ruin
#

Unfortunately I cannot speak to that. In my experience, there is no "usual" timeline. It is hugely dependent on the internal priorities at Stripe as well as the complexity of the feature.

dreamy yacht
#

fair enough! Appreciate the help, will converse with the team and see where our heads are at internally. Perhaps as to not replace our already existing implementation we'll just delay this product launch until preview releases 😛

short ruin
#

Fair. I'm happy to shed what 💡 I can 🙂