#dennis_de - multiple subscriptions

1 messages ยท Page 1 of 1 (latest)

neon trout
#

Unfortunately not at the moment. If they all have the same billing cycle you can consolidate all of your subscriptions in to one but otherwise they will need to be separate subscriptions.

harsh shale
#

Is there a change planned as a feature here?

neon trout
#

Not as far as I know. I can put in a feature request but I can't guarantee that this will get added.

harsh shale
#

We just have monthly or annual base fees and alongside that monthly usage-based billing for consumption. In the case of monthly basic fees, I can pack them together in a subscription, but that's no longer possible with annual fees.

neon trout
#

Thank you for the clarification, I was about to ask

#

One other option that you have is tracking when your subscription goes through 12 cycles and then adding your yearly fee as a one time invoice item

harsh shale
#

Therefore I thought to be able to represent it technically better, I put the usage-based billing always separately as a separate subscription. No matter whether the basic fee is paid annually or monthly.

neon trout
#

How often do you bill on the usage based subscription?

harsh shale
#

The idea was that the customer books the monthly or yearly basic fee via checkout and then I add the subscription automatically....

harsh shale
#

We always calculate the usage in volume from the first day of the month to the last.

#

We have several tariffs (Pay-As-You-Go for 0โ‚ฌ, Company Plan for 299โ‚ฌ monthly or yearly in advance) and besides always a fee per transaction which depends on which tariff you have booked. For the Pay-As-You-Go it is 0,20โ‚ฌ per transaction and for the Company Plan e.g. 0,10โ‚ฌ per transaction. If the info still helps.

#

We have created individual products for the tariffs and just once for the transactions and dadrunter the different prices.

#

Ah and perhaps important to know. We settle customers' transactions early when they reach thresholds in euros. Whereby this is supported by Stripe.

neon trout
#

Apologies for dropping off this thread for a bit. To clarify, are you using Stripe's built in metered subscription APIs or are you calculating the prices yourself and charging for them?

#

If I understand this properly, it does sound like you can consolidate this on to one subscription. I believe you can have a monthly fee and monthly metered usage on the same subscription and then all that would be missing is the yearly fee which as I mentioned might have to be done with a bit of custom code.

harsh shale
#

No problem. Exactly, for the usage we use the Subscription metered api.

#

I believe you can have a monthly fee and monthly metered usage on the same subscription and then all that would be missing is the yearly fee which as I mentioned might have to be done with a bit of custom code.
Do you have an example for the custom code?

#

You probably mean Subscription Schedules?

neon trout
#

This would be something other than subscription schedules actually. I am not sure if we have an example of it but will check

harsh shale
#

In the "Usage threshold" function, I can't specify a threshold lower than the base fee even though the overlay info says that only usage-based billing is considered. Is this a bug?

neon trout
#

Can you send me the ID of the subscription that that is on?

harsh shale
#

It's a test subscription (sub_1LK98EKSCBaxYA7anIMGft3b), but here we go ๐Ÿ™‚

harsh shale
neon trout
#

So initially I was just talking about monitoring when 12 cycles happens yourself and then making the API call to create an invoice item for your charge. We don't have example code for the waiting part but it should be our standard invoice item creation call https://stripe.com/docs/api/invoiceitems/create

#

Basically, when your subscription cycles, it automatically creates an invoice and adds an invoice item for all of your recurring prices. You can also add your own by making that call while the invoice is still in its draft state

harsh shale
#

We use Stripe Billing to avoid having to map complex logics ourselves.

compact marsh
#

๐Ÿ‘‹ Pompey had to step away
let me know if you have any follow up questions ๐Ÿ™‚

harsh shale
#

Please read through the conversation. Pompey was still checking.

compact marsh
#

It is a little long/complex thread, mind giving me a short summary?

Is the question still

Is there any option that multiple subscriptions that renew on the same day end up on one invoice? So each subscription does not have its own invoice?

harsh shale
compact marsh
#

Apologies. I've looked but I'm not super familiar with the dashboard as our team mostly work with API questions.

flat ocean
harsh shale
#

The API apparently reports the error on submit as well.

#

Which parameter would be the right one in the API?

harsh shale
flat ocean
flat ocean
#

Sounds good

harsh shale
#

Feel free to leave the thread open, I'll let you know once I've tested it.

flat ocean
#

I'll likely close in a bit (the server can get quite busy) but not for a while

harsh shale
#

Only I can no longer open a thread again?

flat ocean
#

You can't reopen the thread but you can ask a follow up question in #dev-help if needed. But I mostly answered your question I think. If you get the same error as the Dashboard but in the API it means it's not something we support yet

harsh shale
#

It seems that it is really not accepted by the API. And now? But multiple subscriptions?

flat ocean
#

What are you really trying to do? Like do you have one Price, two, three, more? What are those Prices exactly?

harsh shale
#

At the beginning, I asked whether one or more invoices are generated for multiple subscriptions with the same cycle. Thereupon the suggestion of your colleague was that one could pack everything into a subscription.

#

So that multiple invoices are not generated.

flat ocean
#

If you have 2 subscriptions, they each have their own invoice

harsh shale
#

In the end, we would like to charge a basic base fee + usage-based transactions and also define a threshold here above which intermediate billing takes place.

flat ocean
#

that allows you to put the billing thresholds for that specific Price

harsh shale
flat ocean
#

you can't disable the billing cycle anchor reset though

#

but that might be good enough

harsh shale
#

That in turn would be a problem?

flat ocean
#

maybe for you

#

I'm mentioning it because of your screenshot above

harsh shale
#

If the basic fee runs from the first day to the last day of the month and I bill sub-monthly through the threshold limits, then of course the cycle should not be reset.

flat ocean
#

you explicitly set that one to false, but the per SubscriptionItem one doesn't support it

harsh shale
#

Ah Ok, understand.

flat ocean
#

ah yeah you're right

#

maybe it just doesn't reset at all, which makes a lot of sense in the way you framed it

#

if we reset we'd charge the whole base fee again which would be... dumb lol

harsh shale
#

I will build a test case to see how the subscription items behave.

#

Are there any plans to expand the Billing API? For example, the mapping of real contracts with minimum terms or notice periods? Other providers like Chargebee & Co. can do that, too.

#

Of course, it would be great if Stripe would also map such things in the long term.

flat ocean
#

we're thinking about it, but not in the short term at least

harsh shale
#

So I have successfully deposited billing_thresholds usage_gte on the Subscription Item, however nothing happened after I just registered Usage.

#

Maybe you can look up -> subscription id: sub_1LK98EKSCBaxYA7anIMGft3b

#

and sub item id: si_M2DfdymcYD4NAa

flat ocean
#

I think billing thresholds happen async so I'd wait a bit

harsh shale
#

Okay, that makes sense. I was just wondering if this was an "amount" or a number. The documentation doesn't say in detail.

#

What do you think?

flat ocean
#

well it's an amount that is a number

#

so $100 USD is amount: 10000 because it's in cents

#

so if your Price is $0.05 per usage and your threshold is $10 it will fire when you record usage to 200

harsh shale
#

That was exactly the question... so whether it really is an amount... ๐Ÿ™‚

#

Because normally the parameter is then with the "amount" addition, which is missing here.

#

Therefore, I thought, if necessary, the issue here is quantity.

flat ocean
#

ah gotcha I thought you were asking whether to pass a number like with the decimal 123.34 as we get that question a lot

harsh shale
#

No, that Stripe always works with cents, I have now understood, hehe.

flat ocean
#

๐Ÿ™‚

harsh shale
#

When should the process run at the latest? So that I can test whether it is about an amount or the number?

#

Normally, however, I know that it is always dispatched directly...

flat ocean
#

I would assume quickly so I'm surprised if it hasn't run yet but I'm deep in something else (for another user) so will take a while

harsh shale
#

Don't stress, I'm here. I have created a second subscription for testing, the same issue.

harsh shale
#

It really seems to run via scheduler.... 4 minutes ago the invoice was generated...

#

Have already no longer believed it ๐Ÿ™‚

#

Then I have to make another test case to see if it is an amount or a quantity.

flat ocean
#

yeah I know it's async but I thought it was faster than that, does it mostly work?

harsh shale
#

I am testing again... it doesn't seem to be dispatched in a queue but really run via scheduler, at least the timestamps indicate that.

harsh shale
#

14 minutes it took this time...

#

So I tested it again now and it seems that "billing_thresholds.usage_gte" is really the quantity and not an amount in cents.

#

What also fits is that the parameter does not include the word "amount".

#

Or am I missing something @flat ocean?

flat ocean
#

huh yeah

#

that is... so strange to me

#

it makes sense so that it works across Prices if you switch Prices, but it still "feels" off that this one takes a quantity of usage, versus a final amount

harsh shale
#

Can you verify that?

#

Or is there perhaps another option here?

flat ocean
#

yeah I'm testing but will take a while to confirm since it's all async

#

but I think your read is right amount_gte is about the final amount, usage_gte is about the number of records reported

harsh shale
#

Do you have another idea?

#

It would be useful to describe this in more detail in the API documentation, best to pass this on to the team.

#

And the info on the dashboard should be updated as well, see screenshots at the very beginning.

flat ocean
#

another idea of what?

harsh shale
#

Another idea how to solve it? Because the number is difficult to determine for us... because yes the cent amounts can vary per customer... or we must first read the price, then calculate and store the quantity...

#

It's mega painful, but then that's the way it is....