Per-user billing without charging the client many times a month?

Question

I'm working on a small SaaS product that will have a per-user pricing model (many users per client). I want to allow a client to add users whenever they want, but I don't want them to have to set up recurring $9 (or however much per user) charges for each user. If they added one user a day for a month, there'd be 30 separate $9 charges, rather than one monthly $270 charge.

What is the proper way to tackle this? Metered (once a month) billing based off of users + a pro-rating of a user if it was added during the past month? One-time charge for prorating and then a regular $9*users charge? Should I just eat the prorating and only ever charge the user once a month?

(Apologies if this is the wrong SE site, I couldn't find anything for payments/billing/finance, and this didnt seem tech-ish enough for SO).

Answer 1

While more info is needed, and additional data may affect the answer, this is a relatively common scenario, and the most common way to handle it is to use a pre-paid wallet or credits/tokens system. While essentially the same (client pays an amount at the beginning and expenses are taken from this amount), there are additional concerns to both approaches.

If you use the wallet (money) system, users will be able to see at a glance what are they using, knowing at any time the correct amounts. Depending on your business and your approach to it, this could be the most suitable option.

Tokens are a bit more sophisticated and arbitrary, and they allow for very deceptive techniques (even if legal), but they also allow for dynamic "on the fly" pricing promotions, non monetary exchanges (some countries forbid this) and many more tools. Basically, think as if your site is a country with its own currency. You can assign any value to it and create complex economical architectures like crediting, bartering, micro-payments, value rounding, taxation saving and many more. As you may imagine, the more complex you make your system, the most complicated your back end will be.

In the end, you'll probably have to set with one of this 2 options or a sub-version of them, so hope the answer helps you analyze the pros and cons of your future approach

Answer 2

An alternative is to have pricing levels e.g. single user, 2-10 users, 11-100 users with price breaks. This would give your users better understanding of what they are spending, would make accounting easier, etc. etc.