florian-ruen_api

[whole 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/1273282427053277234

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

[vast tide]

To add more details on my question:

My problem is that by using this method of charging €0.01/unit and directly going back upstream to the pre-calculated rate, the invoice is not very clear for the customer.

Indeed, on the checkout session (the page where he enters address, credit card details, etc.), he will see that the price is €0.01 per unit, when in reality it is not that, but 3% of the transaction price or €0.25/TiB

Then, on the PDF invoice, if the customer wants to find the amount, it is not easy for him either, since it is pre-calculated. What remains is to flood us with requests for support to have explanations.

To try to fill this, I go back to the billings merger payload, information in addition to the value (the total amount, the total size, the amount before rounding etc...) that I would have liked to recover when I recover the events via API (to display it on my application, in the usage history or on the invoice would be even better)

But these other "metadata" are not returned during API requests, so it is impossible to use them.

This is an example of what the customer sees on the checkout session, which does not represent the reality of the amount charged.
And the description is not readable enough to provide information to the customer before they subscribe.

What I recorded in the billing meter and that I would like to recover (if no other way to implement this type of billing)

{
"identifier": "f6718c05-bfff-4977-bd0f-f1273d4cdafa",
"timestamp": 1723542623,
"event_name": "deals_sent_price_to_bill",
"payload": {
"1_total_deal_price_over_last_24h_in_attofil": "0",
"2_total_deal_size_over_last_24h_in_bytes": "1683627180032",
"3_total_deal_size_over_last_24h_in_tib": "0.15312",
"4_minimun_required_price_on_deal_size": "0.038281",
"5_three_percent_on_deals_price": "0",
"6_multiplied_by_100_and_ceil_minimun_price": "4",
"7_multiplied_by_100_and_rounded_three_percent_price": "0",
"client_address_id": "f02347452",
"stripe_customer_id": "cus_QbgF3mRoLcvdjA",
"value": "4"
}
}

In the end my question is divided into 2 parts:

• how to implement this type of billing? maybe there is another method, but I haven't found it.
• and if no method exists other than the one I tested, how could I make it easier for the customer to understand

[limber karma]

Hello, reading..

[vast tide]

Hello there, I'm adding few more details to the previous message, 1 sec if possible (good i've edited the message)

[modern elk]

Thanks for the details. Read through them and am thinking over how this may be able to be improved. Your implementation is sensible as is, but I do see why you'd want to improve the clarity here

[trim eagle]

Hi there 👋 took a look through your post. To start, I'm trying to understand what you mean when you say the following:

and I want to apply a usage-based billing of 3% on the transaction amount or €0.25 / TiB / month if the amount is below
What is the "3% of the transaction amount" that you're referring to there?

[vast tide]

A transaction contains a price and a size (for example 0.5 €, and 32 GiB)

Every day at midnight, I retrieve for a client all his transactions (the total of the price of all transactions, and the total of the size of all his transactions)
The price I want to apply is 3% of this total amount, but if it is lower than 0.25 € / TiB, it is this second amount (minimum amount) that must apply

Because many of our transactions at the moment have an amount at 0, so we need to define a minimal amount

[trim eagle]

Gotcha (I think). That sounds like a pretty complex billing model, and I'm not readily thinking of a better way to model that using our pricing structures.

I'm thinking the cleanest way to show this to your customers/users is to not use Subscriptions here. It sounds like it'd be cleaner if you track and calculate usage on your end, then at the end of each billing period create a one-off Invoice for the Customer. That way each period you can create an Invoice Item, where you can directly provide the amount you calculate that you need to charge your customer and a description to clearly articulate what the amount represents.
https://docs.stripe.com/api/invoiceitems/create

[vast tide]

Understood, but this complicates management on my side, to know from which moment he subscribed etc.
And how can I register a payment method, to send him the invoice but bill him directly (this simplifies and limits reminders in my opinion) ?

[trim eagle]

You can use Setup Intents to collect payment method details from your customers and prepare them as Payment Methods for future usage:
https://docs.stripe.com/payments/save-and-reuse

I don't think there's a way to avoid complexity with the billing model you described, it seems to me like the key choice here is whether you keep that complexity on your end where you can build code to handle it or let the complexity surface in what the customer sees and be prepared to answer the support question that will lead to.

[vast tide]

Understood, so to do a quick summary, the workflow, for what you suggests is:

• the user want to subscribe to premium, click on a button
• this will create a checkout session, but only to "configure" using "setup" mode
• I run a task on my side to compute the amount to bill (each month, for 1 invoice per month here)
• create a invoice using Stripe API, and use collection_method = charge_automatically
• i need to keep track on my side for invoices, usage and other things

right ?

[trim eagle]

Yup, exactly

[vast tide]

Alright, I'll try implementing this by the end of the week to see if everything can work like this. Is this thread still open, in case I have any questions related to this?

[modern elk]

We typically close out threads after ~20 mins of activity and encourage you to start a new thread with the state of your question after that. When a new thread is created we do link to the old ones for easy reference, but it is still helpful to catch whoever is on the server up so they don't have to do too much background reading to be able to help.

[vast tide]

Great, thanks for help today!