Product feedback

If Lago detects a lost dispute linked to a wallet top-up transaction, the credits should automatically be voided. Fraudulent users should not be able to keep their wrongfully acquired credits.

Some times, we need to charge an item once only such as integration fee for a specific feature and we don't want to send 2 invoices to our customer but one invoice with the subscription fee, the usages and the one-off items.

Currently Lago does not provide any options to delete past event data. But in production this leads to accumulation of events data and soon database size increases to tens of GBs. It'll be helpful if there is an option where retention time can be specified, which routinely deletes old events(for example events older than 1 year) making database manageable and cost effective

We currently query the current usage endpoint to determine whether a customer should still be able to access some features based on their plan and allowance. It would be easier if Lago could alert us when a customer has used up their usage quota.

It’s currently not possible to top up a wallet using a different ratio than the one defined. However, this flexibility could be very useful — for example, when a customer purchases credits at a discounted rate.

As we have an integration with Stripe payment, having an integration with Mollie as a payment provider. https://www.mollie.com (n.b. they already have an active ruby-client https://github.com/mollie/mollie-api-ruby )

After the customer has already started a subscription, they may want to change their payment frequency from monthly to weekly, fornightly, annually for example (any number of times). Billing period should be able to change while the subscription is already active, and if they are prepaid, any change would take effect at the end of the period they have paid until. If appropriate, the period should be prorated so they don't pay more or less than required if changing multiple times.

Credit added to the customer wallet is automatically deducted from invoices. It applies to subscription fees and usage-based charges, but it would be useful if we could limit the use of credit to usage-based charges (i.e. billable metrics, same behaviour as coupons).

Lago is an incredibly flexible tool, but it will never be able to answer every user's needs. Custom expression are a reasonable stop-gap, but do not provide complete flexibility as they currently only allow referencing the data in a single event, and only using a pre-defined set of operations. As a way to allow users to define their own metrics calculations with complete flexibility, it would be very nice to have billable metrics have the ability to call a user-definable webhook that then returns the value to use on the invoice when it is necessary (During viewing of usage, and invoice calculations). The way that I imagine it, the webhook provides 5 main parameters, tho I can see more being useful. The start and end of the time being billed for, the external user ID being billed, the plan ID that is currently being billed, and the metric being billed. (If the webhook handler needs any more data, it can fetch it from Lago using that provided data.) From there, the handling endpoint can calculate the usage metrics based on the given parameters and return the "events" to Lago. Lago then calculates the invoice as it would any other and returns it, either to the end user looking at their portal, the lago user hitting the test invoice endpoint, or the billing engine itself charging the user and sending out the emails etc. Potential complications 1: The external service being called may have errors or instability and how to handle the invoice in that case is then complicated as it may not be able to be created with correct data. 2: The external service may be called several times in excess, including from the user directly loading their portal page. This could lead to a manner of overloading the end service. Some form of rate-limiting or caching should be used for atleast this call. 3: The user writing the webhook handler needs to make sure that it is a "read-only" request given the request may be made from several sources that are not actually charging the user. 4: Knowing how to bill an example invoice is complex as billing from start to now, or start to expected end may produce different results. 5: Given the filtering that a single metric can have, the single request to the webhook should have the ability to return multiple events, each with different properties. How to handle the excess metrics if filtering is not used, I don't know. Potential additions 1: It may be useful to allow the user to define extra query parameters of their own that are included in the request (or including some others automatically). I can see this being most useful for a user defining a single endpoint for multiple metrics, and switching the query they perform based on a query parameter defined in the webhook.

Ability to pause and resume subscriptions (sometimes after several billing periods) via the API and user interface as well. If a subscription is paused, the customer should not be billed. If the subscription is resumed over the course of a billing period, fees should be prorated.