brian_code

[kind shard]

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

📝 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.

• brian_code, 10 hours ago, 18 messages

[acoustic shard]

Hi 👋

We have multiple docs dedicated to how you can build a layered pricing scheme to model these kinds of subscriptions. I recommend you review our guide to see what works best for you

[hearty adder]

hey there 🙂 I've taken a look over it, but i'm not seeing how to apply metered based billing within a base subscription, specifically with creating a default base value before charging the overage-fee;

so regards to clarifying, I would need to chain multiple subscriptions then for the different values?

we want the physical base subscription to be a fixed value, but then have additional parameters that change as your team scales;

[acoustic shard]

For usage based billing, we cover how to do a fixed fee and overage pricing model in this doc

[hearty adder]

how do you apply a meter for example to another subscription?

say at the point of a user signing up, the only thing they need to do is pay the $5.99 for their subscription to start, how do you link that meter to that subscription, rather than sending 2 separate invoices/2 subscription prices

[acoustic shard]

You need to create the metered price and include it as part of the subscription but you specify the pricing tiers such that it generates a $0 line item unless they go over the amount you specify as your threshold for overage.

You could also use a graduated price for the overage where you log the quantity and any amount less than your threshold charges $0 but once you go over your threshold you start accruing charges

[hearty adder]

is there perhaps a code example to look at how to attach that to an existing subscription

[acoustic shard]

The docs I have shared demonstrate how you can create a Price object that is configured to bill an extra amount for any overage you want to record. Do you understand that part? I.e. could you create a Price object in Stripe for your overage and understand how to increase the amount in order to record overage fees?

[hearty adder]

yeah, doing it via the dashboard has been easy.

I'm just not sure how to pair it with a particular subscription;

I.e when i subscribe for $5.99, assuming I had something like 3 seats are included, would I just find the user's subscription, find the line item that handles seats, and just update the quantity, and it'll automatically move to the next tier'd price?

[acoustic shard]

What do you mean "subscribe for %5.99"? Is this a price that has a per seat charge configured?

If you have configured this as a tiered Price object, and specified the thresholds at which you will change the per seat charge, then all you need to do is increase the quantity

This is covered in detail in the first doc I shared

[hearty adder]

the context is you visit our pricing page, subscribe to our $5.99/month subscription plan, we include 3 seats "for free", and each extra seat being $4 for example:

 // Get the Stripe subscription
    const stripeSubscription = await stripe.subscriptions.retrieve(subscription.stripe_subscription_id)

    // Find the seat price item
    const seatItem = stripeSubscription.items.data.find((item) => item.price.metadata?.type === "seat")

    if (!seatItem) {
      return NextResponse.json({ message: "No seat price item found in subscription" }, { status: 200 })
    }

    // Get the included seats from metadata
    const includedSeats = Number.parseInt(stripeSubscription.metadata?.includedSeats || "1")

    // Calculate additional seats
    const additionalSeats = Math.max(0, currentSeats - includedSeats)

    // Update the subscription quantity
    await stripe.subscriptionItems.update(seatItem.id, {
      quantity: additionalSeats,
    })

    // Update the subscription metadata
    await stripe.subscriptions.update(subscription.stripe_subscription_id, {
      metadata: {
        ...stripeSubscription.metadata,
        currentSeats: currentSeats.toString(),
      },
    })```

this is basically the solution I have currently

but i'm not sure if i'm over thinking it

[acoustic shard]

Okay so the $5.99 would be your fixed fee. That is one Price object. The second is tiered price where the first tier is from 0 - 3 with an amount of $0.

The second tier, ( 3-inf) or whatever you want, is where you specify the per seat amount that the customer gets charged

[hearty adder]

ah so I'm overthinking using the product metadata for the rest of this logic

[acoustic shard]

Yeah I think it's actually a prety straight-forward fixed fee + lisenced pricing scheme

You just have that Free tier with the quantity from 0 to 3

Like this https://docs.stripe.com/products-prices/pricing-models#tiered-pricing

[hearty adder]

do I still need to to at least do:

// Update the subscription quantity
    await stripe.subscriptionItems.update(seatItem.id, {
      quantity: additionalSeats,
    })```

in order to charge the new seats, and do a lookup of the productid that's associated with seats

[acoustic shard]

You would need to update the quantity, yes. That would create a pro-rated line item on the next invoice

(or bill immediately if you configure the API call to do that)

[hearty adder]

got it, that makes sense for the per-seat related billing, what about metered usage, how do I apply that to the same subscription as well?

[acoustic shard]

Same thing. Create a Metered Price and add it to the Subscription.

The Price objects are what define how Stripe will determine the amounts to charge your Customers.

[hearty adder]

ah makes sense, appreciate the help 🙂

i'll throw a ping if I have any other questions/concerns;

my last follow up, regarding taxes, do we have to define each tax manually, or can stripe automatically determine the different taxes for different jurisdictions

[acoustic shard]

If you are using Stripe Tax, Stripe can automatically determine taxes provided you have collected enough data from the customer

I recommend reviewing this doc for a general explainer.

We also have a Subscription-specific doc here

[hearty adder]

thanks! 🙂

[high grotto]

Hi hi! I’m going to be taking over for my colleague here; can you please summarize your issue/question for me?

[hearty adder]

hey! no worries 🙂

Basically, concerned about overthinking how we've implemented our backend for payments;

our pricing model is as followed(using an example):

$5.99/month base subscription fee(the value you see on our /pricing) page.

3 seats included with the subscription, $4 per additional;

we also have a meter we need to track and bill accordingly;

my base question is how do I properly assign the per-seat to our base subscription(and update accordingly) along with the meter

I provided a couple code snippets above as well 🙂

[hard tendon]

Hello! What have you tried so far to assign the per-seat to your base Subscription? How has that approach not worked?

[hard tendon]

It sounds like you want a combination of per-seat pricing and tiered pricing, but I'm wondering if you've tried that and it hasn't met your needs?

[hearty adder]

I think the main concern is implementing it with the least amount of lines of code;

The couple snippets I posted above in the chat, I feel like is being completely overthought

[hard tendon]

It seems like you're on the right track to me. Once the pricing is set up correctly it really boils down to setting the quantity (meaning the number of seats) correctly.

[hearty adder]

is that still overthought though on the regard of relying on the product metadata to determine everything else, or can that be removed and simply look up by the productID

[hard tendon]

It's really up to you and what works best for your needs and integration. Some people keep track of this stuff entirely on their end, like with database entries that associate your internal pricing data with Stripe Product and Price IDs. Other people use metadata like you're doing in the code above to keep track of things. Generally speaking neither approach is inherently better or worse, but one approach may have distinct advantages or disadvantages which are unique to your specific situation.

[hearty adder]

ah makes sense, so technically speaking the way it's implemented now in theory should work;

I ultimately just want the least overhead for longevity, and least amount of tech debt-focused maintenance

[hard tendon]

I can't say if it will work for you or not. That's what test mode is for. 🙂

UIltimately you know what your specific needs and requirements are. We can help you with questions about how Stripe works here, but we can't tell you if a specific approach will work for you or not because we don't have enough context.

Testing a lot in test mode is highly recommended to verify that everything will work as expected.

[hearty adder]

yeah fair enough! given the tiered base pricing, hypothetically if the base subscription was let's just say test_123, and the team seat price id was testing_123 could one in theory look up the current subscription and get the sub-products that way?

or do you still kind of need to do what we're doing now

[hard tendon]

Just to make sure I understand your question, you're asking if given a Subscription ID (sub_) can you get to the Products (prod_) it's using?

[hearty adder]

yeah, like if i'm on the "starter plan" for example, can I use that product ID to look up the number of seats or usage

[hard tendon]

Not sure I completely follow. Can you give me an example scenario?

[hearty adder]

sure, in this example, can we grab the product id of let's say "startup tier", and directly link it to it's actual price value with a customer, or do we still need to do basically

const stripeSubscription = await stripe.subscriptions.retrieve(subscription.stripe_subscription_id)

    // Find the seat price item
    const seatItem = stripeSubscription.items.data.find((item) => item.price.metadata?.type === "seat")```

in other words, if we on our backend add another user to an organization within their billing period, can we simply just do:

// Update the subscription quantity
    await stripeSubscription.subscriptionItems.update(seatItem.id, {
      quantity: additionalSeats,
    })```

in order to update the seats, or do we need to chain a lookup in order to figure out what price they're actually paying

[hard tendon]

So you're talking about a scenario where a single Subscription has multiple items, only one of which is the per-seat pricing, and you're asking what the best way is to determine which specific item you need to adjust the quantity of when a seat is added or removed?

Like given a Subscription with, say, three Subscription Items (si_1, si_2, and si_3) for a seat addition you need to know which of those three needs the quantity adjustment?

Or am I totally off track? 😅

[hearty adder]

yeah you're on the the right track! I guess best way I can explain it is if a user signs up on the business tier, but they're currently a single user on their organization, how we can properly update the tier when needed

[hard tendon]

So I think your current approach is fine and will probably work (but test it in test mode to be sure). That said, I think if I was building this I'd try a couple of other approaches first... (typing)

This first idea might not work for you, but each Subscription Item has a price.billing_scheme which would be set to either per_unit or tiered. If in your situation you always want the tiered one because you never use tiered for anything else, you could check that instead of setting/checking the metadata. I don't know that I would recommend this approach, as it would be somewhat fragile to potential changes in the future if additional tiered items were introduced later, but I wanted to throw it out there as something that might be useful in some way...

The second idea is, instead of adding metadata to the individual items (where you're currently setting type to seat on the item level) you could instead set metadata at the Subscription level where you set a key like seat_item_id with the value being the ID of the Subscription Item you're using for seat pricing for that Subscription. You could also add more keys to indicate what the other Subscription Items are for (e.g., <purpose>_item_id). Having this information at the top level of the Subscription instead of nested down in the Subscription Items themselves might make things easier to reason about and code.

The third option, of course, it to keep track of all of this on your end where you have database entries that keep track of Subscriptions, Subscription Items, their purpose, and so on.

Does that help?

[hearty adder]

Yeah that makes sense to me 🙂 I know this is probably a relatively ambitious ask, but given the large feedback Theo the youtuber made about stripe's pain points and you guys being involved in working on addressing it,

Could I perhaps suggest maybe extending some of the billing APIs in the SDKs to maybe help solve some of these scenarios, perhaps, something similar to how the metered API works, but an easier way to prevent tons of logic on the implementation side

[hard tendon]

It's certainly something that's on the Billing team's mind. It's difficult because the system has to accommodate an incredibly wide variety of use cases, and introducing an approach that helps one group of users can often make things harder for another group. We also have to not break things for all existing users. We have to walk the line between making things best for as many users as possible. We don't always get it 100% right, but we do our best. Not trying to make excuses or anything, just giving you some idea of why things are the way they are.

There's also the balance between making the system powerful enough to accomidate a wide variety of use cases (which makes it more complex to use) and making it easy to use (which makes it less flexible and thus inappropriate for some people to use).

[hearty adder]

Understandable 🙂 and I completely agree with that justification as well, I mean as it goes without saying there's a reason Stripe is more widely preferred over competitors such as PayPal, the overall DX and experience in general is a lot better

[hard tendon]

Yeah. I've been here for a number of years, and I've talked to a lot of developers. Some of them we're a perfect fit for, everything works amazingly well, they have no notes. Others struggle to make things work because their specific requirements just don't mesh well with our systems. And everyhing in between. It's wild how many different business and pricing models are out there. 😅

[hearty adder]

Yeah absolutely haha, I appreciate the chat though, and i'm glad i'm not the only one feeling like outside of "simple" billing, Stripe gets extremely complex 😅

[hard tendon]

Yeah, I can't argue with you there. 🙂