#mistahugh_invoice-inline-prices

1 messages · Page 1 of 1 (latest)

mystic zephyrBOT
#

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

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

latent thistle
#

For additional context.

Technology Stack
 Backend API: Ruby on Rails
 Stripe SDK: stripe-ruby gem v11.6.0
 Stripe Feature Used: Connect Accounts (invoice creation via connected account)

Description of the Issue
We are creating Stripe Invoices programmatically from our backend API using a connected Stripe
account.

For invoice line items:
 We first create a Price in Stripe.
 We then create Invoice Items using that Price and associate them with an Invoice.
Our application supports fractional quantities (e.g., 0.75, 1.25, 2.5) because quantities represent
billable hours. However, Stripe appears to only support integer values for the quantity field, which
results in truncation of decimal values and an incorrect invoice total on Stripe.
Below is the relevant code used for price and invoice item creation.

Code Snippet
Price Creation
def create_or_find_stripe_price(item, currency)
Stripe::Price.create(
{
product_data: { name: item["item_name"] },
unit_amount: (item["price"].to_f * 100).round,
currency: currency
},
{ stripe_account: secure_stripe_user_id }
)
End
Invoice Item Creation
invoice["items"].each do |item|
price = create_or_find_stripe_price(item, invoice["currency"])
create_invoice_item(
client.stripe_id,
stripe_invoice.id,
price.id,
item["quantity"]
)
end
def create_invoice_item(customer_id, invoice_id, price_id, quantity)
Stripe::InvoiceItem.create(
{
customer: customer_id,
invoice: invoice_id,
price: price_id,
quantity: quantity.to_i
},
{ stripe_account: secure_stripe_user_id }
)
end

Problem Statement
 Stripe supports only integer values for the quantity field.
 Our use case requires decimal quantities (billable hours).
 Due to this restriction, decimal quantities are truncated, causing a mismatch between:
o Our application’s invoice total, and
o The total displayed on Stripe (email, PDF, and payment page)

analog crescent
#

Hello
That's correct. We don't support decimal quantities

#

You could configure pricing per minutes & look into charging the customer based on that.

#

That might simplify things a little bit from billing perspective.

However, you may need to generate your own invoice email/PDF to avoid having usage shown as per minutes.

latent thistle
#

In our case, we’re using Stripe Invoices (via Connect accounts) to support one-off and ad-hoc invoices created by our users (accountants and bookkeepers) inside our Accounting practice management software. The quantities represent billable time (hours), which is why fractional values such as 1.5 hours are common.

Based on your confirmation that Stripe does not support decimal quantities on Invoice Items, we’ll move forward with the recommended pattern of:

*Setting quantity = 1, and
*Calculating the final line amount ourselves (hours × rate) and passing that value via unit_amount,
while preserving the hours/rate breakdown in the line item description for customer clarity.

We did review the usage-based billing documentation you referenced, but since our current workflow involves standalone invoices rather than subscription-based billing, would the adjusted unit_amount approach be the best fit for our use case?

latent thistle
analog crescent
#

Gotcha.
As far as I know, with usage based billing and meter events - you can report fractional/decimal usage.

But since your integration doesn't use a Subscription based flow, it doesn't meet the needs

latent thistle
#

That makes sense, thanks for confirming.

We understand that usage-based billing / meter events support fractional usage, but since our integration is focused on standalone invoices (not subscriptions) created via Connect accounts, that flow doesn’t meet our needs.

We may proceed with calculating the line total on our side (hours × rate), setting quantity = 1, and using the line item description to clearly reflect the billed time (for example, “1.5 hours @ $100/hr”) so totals remain accurate on Stripe invoices.

As a follow-up, we had a couple of questions that would help us further improve the integration. Are there any best practices or caveats we should be aware of when dynamically creating Prices with calculated unit_amount values, particularly around rounding or reuse versus one-off Prices? Also, from a customer-facing perspective, is using the line item description the recommended way to display the hours and rate breakdown on Stripe invoices and PDFs? Lastly, are there any known roadmap items around invoice line items that might eventually support fractional quantities outside of subscription flows?

Appreciate the help, this has been very useful.

mystic zephyrBOT
tender fable
#

Hi 👋

I'm stepping in as my colleague has to go. Let me take a look at your follow up questions

#

Are there any best practices or caveats we should be aware of when dynamically creating Prices with calculated unit_amount values, particularly around rounding or reuse versus one-off Prices?

This is really up to you and what makes the most sense for your integration. If you have set pricing schemes then creating Price objects does allow you to re-use them in conjunction with quantity.

Also, from a customer-facing perspective, is using the line item description the recommended way to display the hours and rate breakdown on Stripe invoices and PDFs?
The InvoiceItem description parameter is a useful way to display additional information, including your hourly rate breakdown, to customers

Lastly, are there any known roadmap items around invoice line items that might eventually support fractional quantities outside of subscription flows?

Not that I am aware of

latent thistle
#

Thanks, super helpful. We’ll move forward by calculating the line total on our side (hours × rate), setting quantity=1, and using the InvoiceItem description to show the hours/rate breakdown on the invoice/PDF.

Just to confirm, there’s no issue with creating one-off Prices for these calculated amounts (or alternatively avoiding Prices and using direct amounts on the InvoiceItem), correct? Either way, thanks again, this clears it up for us.

tender fable
#

Either approach will work on the Stripe side of things. Both approaches offer different levels of customization to allow merchants to tailor their integration to fit their needs.

#

But I get that sometimes having so much choice can make it more difficult to identify the "correct" approach

latent thistle
#

That makes sense, appreciate the clarification. Thanks again for walking through this with us, you guys have been very helpful.

tender fable
#

Great 🎉 Happy to shed what 💡 we can 🙂