#nukesforbreakfast_best-practices

1 messages Ā· Page 1 of 1 (latest)

terse stagBOT
#

šŸ‘‹ 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/1342279612599635989

šŸ“ 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.

lethal river
#

Hello! Will wait for you to finish typing. šŸ™‚

robust karma
#

I could try to model these as a single product with multiple prices over time, but it becomes much more complex to keep things up to date and in sync. I'm not going to be displaying these prices in a Stripe pricing table, and it's not something a user would subscribe to. I can't see any obvious downsides to simply creating a new product each time I need to make a change.

Is there's something I'm missing that would lead this to be a terrible idea?

lethal river
#

To clarify, are you creating one-off Invoices that use these Products and Prices?

robust karma
#

yes, as I can't shoehorn this 365 day lookback period and count the number of fineable events into Stripe's usage based billing models.

lethal river
#

Okay. The first question that comes to mind is if price_data will work when creating the line items? price_data allows you to supply ad-hoc price data, and will create a Price under the hood, but the Price won't be visible in the Dashboard by default and will only be intended for that specific Invoice.

#

Ad-hoc Prices created this way are designed to be one-offs, and aren't something you would need to keep in sync with anything else.

robust karma
#

The fine schedule I'm modeling is something like:

365 day lookback period:

  • 1st event $0
  • 2nd event $0
  • 3rd event $75
  • 4th event $150
  • 5th event and every event thereafter $250
robust karma
lethal river
#

Yeah, ad-hoc Prices aren't default Prices, they're one-off Prices that don't clutter the Dashboard and that you don't otherwise have to worry about. In the scenario you described above you'd make a single Product called "Event" and then you'd use that Product ID when specifying the ad-hoc price_data for each Invoice ($0, $75, $150, etc.).

robust karma
#

it's really more like 3 products in order to display the line items correctly:

  • 3rd false alarm
  • 4th false alarm
  • 5th or greater false alarm
#

However, not having those prices show in the dashboard might be something useful. I didn't see that detail documented anywhere though.

lethal river
#

That's not a problem, just specify whichever Product ID is appropraite for the ad-hoc price_data.

robust karma
#

There's no similar method for an ad-hoc product, is there?

lethal river
#

Not with Invoices, no.

robust karma
#

One that would also not show up in the dashboard.

lethal river
robust karma
#

that would have been perfect, as I'll probably end up with a bunch of products managed for different Connect accounts in my account.

#

is there anywhere in the docs that talks about these ad hoc prices not showing up in the dashboard?

lethal river
#

Hm... not sure, let me look.

#

You can give it a try in test mode to see how it works if you're curious.

robust karma
#

alright. So back to the original question, it seems like the main issue would be cluttering my stripe dashboard with prices?

#

products and prices, rather.

lethal river
#

Well, I'm not certain I have full context, but given what you've described so far, if I was building this system, I'd have a handful of Products ("First Event", "Second Event", etc.) and use those with ad-hoc price_data for each Invoice.

#

Does that sound good, or do you think that won't work for some reason?

robust karma
#

Hmm, I guess I'm stuck on there being a many rows in my DB to one product relationship. This is because I allow the users to do things like schedule all fines to increase by $50 at the start of the new year, so theres a new 3 rows for each of those price changes.

It's easier to have a 1 to 1 relationship between a row and a product + default price since I can set the product ID to == the ID of each row. I guess I could figure out how to model the many to one relationship somehow so I know when to create a product because they added a new fine level that never existed before.

šŸ¤”

#

but I will definitely test out this ad hoc pricing thing in test mode to confirm they don't appear in the dashboard.

lethal river
#

Hm, not sure I completely understand. Why does there need to be a 1:1 relationship? For example, if you had a Product on Stripe called "Third Event" why would you ever need it's default Price or anything from it other than that name? Each Invoice would generate an ad-hoc Price behind the scenes you would never see and wouldn't need to worry about.

#

Like, for example, you can create an Invoice Item with the "Third Event" Product, add whatever description you want, and whatever price_data you want. That would all be fed in from your system and wouldn't need to be kept in sync, right?

#

To put it another way, the only thing your system needs to keep track of is which Product has which name, and there would only be a handful of those, right?

robust karma
#

The disconnect is when they're first creating the fine schedule, I need to know if a product already existed for the fine level and if not, create it. It seems the only reliable way that doesn't rely on search features to look up a product is via a custom ID.

lethal river
#

Can you give me an example?

robust karma
#

Sure, take two Jurisdictions (tenants), Poway and Vista. They each set up their own fine schedules:

Vista:

  • 1st $0
  • 2nd $0
  • 3rd $150
  • 4th $250
  • 5th and each after $500

Poway:

  • 1st $0
  • 2nd $0
  • 3rd $75
  • 4th $150
  • 5th $250
  • 6th and each after $500

Vista onboards first, so no products exist. As they store their fine schedule the backend has to create a product for each level with a fine in order to be able to display the line item on the invoices correctly.

Poway onboards second, but since their 5th level is not the final, I need to either have an entirely separate set of products so their 5th levels name is "5th false alarm" instead of Vista's "5th false alarm or greater", or just have two separate level 5 products, in order to render the item properly on invoices.

Then, Vista decides they need to change the fines in 2026 to be:

  • 1st $50
  • 2nd $150
  • 3rd $250
  • 4th and each after $500

I now have to know I need to create products for level 1 and 2, as well as potentially a different level 4 to get a different name for invoice display from the level 4 of Vista if I'm not duplicating all products for each tenant.

The only easy way I see to look up these products reliably to be able to manage these changes is to set a custom ID. In the many fine levels to one stripe product case, I would have to find some ID scheme that remains unique across tenants, such as <tenant id>_fine_<level_number> or something. If I just created a new product each time there was a scheduled change for a fine level, that custom ID would simply be the ID of the fine level row in my DB. That's so deliciously simple I'm trying to figure out if it's actually a poison apple.

Maybe there's some way to instead use ad-hoc invoice line item descriptions or names?

#

That way I wouldn't need to worry about products in Stripe at all.

lethal river
#

So, I think you're trying to couple Products in Stripe too closely with everything else. What I'm proposing is that you think of Products in Stripe as nothing more than the high-level name of the line item. The thing they're paying for. That's it, nothing more.

So, for example, you could have these Products and reuse them across all of your Invoices:

  • "First False Alarm"
  • "Second False Alarm"
  • "Third False Alarm"
  • and so on...

Then, when you go to create a specific line item, all you need to look up on your end is the Product ID for the high-level name you want to use. Any additional detail you need to specify for that line item wouldn't be associated with the Product at all, it would be specified in the Invoice Item's description and price_data, which are both ad-hoc and unique to that specific item, and thus don't need to be kept in sync with anything.

#

Would that work?

robust karma
#

so the line item "description" overrides the line item's name as it appears on the invoice?

#

or is it just some subtext underneath the line item's name?

lethal river
#

It's subtext.

#

You'll get both the Price's name and the item's description on the Invoice.

robust karma
#

ok, so I literally only need the product in order to set the display name of the line item in the invoice.

#

so I can just ID each thing "fine_level_N" and look it up that way.

lethal river
#

As far as I understand your use case, yes. Give it a try in test mode and see if it works for you.

#

This is the first thing I would try if I was building this.

robust karma
#

ok, that would be really simple. For some reason I guess I thought products and prices had to be tightly coupled together.

lethal river
#

If it works, great. If not, you'll know specifically why it doesn't and you can then have a lot more clarity on what needs to change.

robust karma
#

I'll give this a try, as it seems the simplest approach.

#

and just to double check

#

however, those same docs also say price or price_data is required. What does amount do in that case, since wouldn't the amount be set by the price or price_data?

lethal river
#

We really need to clean up those docs... šŸ˜…

#

One sec...

robust karma
#

BTW, I'm looking at this version:

lethal river
#

Yeah. So, I was so caught up in the assumption that you needed Products visible in the Dashboard that I didn't even consider this. Do you need Products? If not, you can indeed create Invoice Items by only specifying customer, amount, and currency (and you'll also want description).

robust karma
#

I think the only time I need products is when I need to model a permit fee that renews. In that case I need a product with a recurring price in order to get the subscription to generate properly.

#

otherwise, I don't need any products/prices as those will all be done ad hoc.

lethal river
#

Yep, you would need a Product in that scenario, but for one-off Invoices I don't think you need to worry about Products at all.

#

Sorry, I should have asked about that more explicitly sooner. šŸ˜…

robust karma
#

ok, so when the docs say price or price_data is required, that's not the case if you specify amount?

#

let me just create an invoice and see.

lethal river
#

What the docs are trying (and failing) to convey is that if you're using Products or Prices you need to either specify price or price_data, but you don't need either one if you specify amount and currency instead.

#

I am currently typing up a detailed docs update flag for this BTW. šŸ˜…

robust karma
#

so then does "description" set the line item name?

lethal river
#

Yes.

robust karma
#

ok, yeah, I'm glad we had this talk. That makes things a lot simpler for me. I still wish I could manage this all with Stripe's built in usage tracking stuff, but there's no way I know of to sum usage using a custom time window formula like I need for this case.

#

and attach that to a fine tier.

lethal river
#

Yeah, that would be extremely difficult (if not impossible) to model with our recurring Billing system.

robust karma
lethal river
#

That what you want?

robust karma
#

perfect, so I don't need to manage products and prices at all for these things.

lethal river
#

Awesome!

robust karma
#

invoice_item = stripe_client.invoice_items.create(params={"customer": customer.id, "invoice": invoice.id, "amount": 5000, "description": "1st false alarm."})

robust karma
lethal river
#

Yep, writing up my suggested revisions for those now.

robust karma
#

There isn't some plan to deprecate amount or unit_amount when creating invoice items, is there?

lethal river
#

Not that I'm aware of. I don't see how we could do that in any practical way. Those parameters are commonly used. If we did remove them it would be a breaking change in a newer API version you would need to opt-in to.

robust karma
#

and for the permit renewals case I can just have 2 products, "Permit fee" and "Permit renewal fee", and then do a price for each tenant + amount with the correct recurrence intervals for subscriptions to work.

lethal river
#

These are my recommended revisions if you want to take a look (don't know when these will be live though):

amount:

The integer amount in cents of the charge to be applied to the upcoming invoice. Passing in a negativeĀ amountĀ will reduce theĀ amount_dueĀ on the invoice.Ā  When usingĀ amountĀ you must also specify theĀ currency.Ā  Required ifĀ priceĀ orĀ price_dataĀ is not set.

currency:

Three-letterĀ ISO currency code, in lowercase. Must be aĀ supported currency.Ā  Required when specifyingĀ amount.

price:

The ID of the price object.Ā  When using Prices, one ofĀ priceĀ orĀ price_dataĀ is required.Ā  If not using Prices,Ā amountĀ andĀ currencyĀ are required.

price_data:

Data used to generate a newĀ PriceĀ object inline. When using Prices, one ofĀ priceĀ orĀ price_dataĀ is required.Ā  If not using Prices,Ā amountĀ andĀ currencyĀ are required.