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

  • 2
    Welcome to ux.stackexchange. Your question seems appropriate for this site
    – Devin
    Jul 8, 2015 at 3:32
  • 1. are the users somehow related to each other? i.e. part of the same company or entitiy? 2. why is the client manually adding users ang charging them? why isnt the system automated?
    – Stanley VM
    Nov 5, 2015 at 18:24

2 Answers 2


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


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.