One invoice for multiple subscriptions with variable quantity

[lexdewilligen]

Let me first explain what we’re trying to achieve. We’re currently creating a SaaS application offering management software in several modules. Organizations are free to choose whatever modules they’d like to use. Prices are calculated based on the amount of users which an organization has.

In short, there’s the following demands:

1. invoice (the day does not matter, may be a fixed date, may also be variable bases on the day an organization subscribed)
2. Variable quantity (for every user that registers for an organization, we increment the subscription quantity)
3. Multiplan (currently we create a new subscription for every chosen module, would be nice to use cashier-stripe’s new feature)

Several solutions to our issues have been provided already, but the combination does not work. We can create a single invoice by running cashier:run on one single day every month (#65 ). All due OrderItems will be processed into one Order.

However, this results in problems when using the quantity feature. Because if the quantity is raised from 2 users to 5 at the end of the month (and the organization hasn’t paid anything yet), this will result in an order for 5 users for the whole month (since prorating didn’t do anything because there was no pre-paid amount to reimburse).

A solution to that problem might be to invoice after every increment/decrement of a subscription, but that doesn’t seem very user friendly to me since they might get an invoice for every day of the month (some organizations change employees very quickly).

Another suggested solution might be the subscription anchor date (#66 ). Every time a subscription increments/decrements charge the organization for the rest of this month. But anchor dates are missing at the moment.

Then there’s one solution I thought of: what if there would be an incrementByCredit/decrementByCredit method to increment the quantity and subtract the costs from the users credit (might get negative). This negative credit will then be invoiced at the first moment cashier:run is being run. In that way, organizations get just one invoice per month and all increments/decrements from that month are nicely prorated so that the organization really only pays for the days that he used a module or had a certain amount of users.

Do you think of any combination of solutions that would fix our problem? I have time to create some new features like multiplan subscriptions, anchoring dates or this new in/decrementByCredit feature. What would you suggest?

[sandervanhooft]

Hi!

Have you tried setting the updateQuantity parameter $invoiceNow to false?

The seat prorating will then be invoiced the next time you execute cashier:run instead of directly.

[lexdewilligen]

Well I tried that before, but I think I did something wrong, because I've just tried it again and works nicely! Thanks a lot