Developer experience

I propose adding a customer payouts feature to Lago, supporting both automated and manual payouts to enhance its utility for platforms and marketplaces that need to distribute earnings to users or vendors. This would make Lago a more comprehensive revenue operations solution, complementing its metering, invoicing, and billing capabilities. The feature could be implemented in multiple stages to ensure a smooth rollout and alignment with Lago’s existing infrastructure. Key Details: • Functionality: Enable both automated and manual payouts to customers (e.g., vendors, creators, or partners) based on revenue collected, with configurable rules for splits, fees, or thresholds. Manual payouts would allow for custom adjustments, especially useful for one-off bank transfers. • Integration: Support payout providers like Stripe Connect, PayPal, or direct bank transfers, similar to Lago’s existing Stripe integration for billing. • Use Case: Ideal for marketplaces (e.g., SaaS platforms, e-commerce, or creator economies) where revenue needs to be split between the platform and end users after deducting fees. Manual payouts would be particularly helpful for handling irregular or ad-hoc distributions. • Benefits: Streamlines payout workflows (automated for efficiency, manual for flexibility), reduces reliance on external tools, and aligns with Lago’s focus on flexible, usage-based revenue management. • Example: A marketplace using Lago could collect payments, deduct a 10% fee, and either automatically distribute the remaining balance to vendors weekly via Stripe Connect or manually process a bank transfer for a specific vendor, with payout status tracked in the dashboard. Implementation Stages: 1. Stage 1: Core Payout Framework (Manual Payouts) o Develop a basic payout module allowing manual payout initiation within the Lago dashboard. o Support one-off bank transfers and manual exports (e.g., CSV for bank processing). o Include basic tracking of payout status (e.g., pending, completed) and simple fee/split calculations. o Focus on integrating with a single provider (e.g., Stripe Connect) for manual payouts. 2. Stage 2: Automated Payouts o Build automation for recurring payouts based on configurable rules (e.g., weekly/monthly schedules, minimum thresholds). o Expand integration to additional providers like PayPal. o Add support for automated fee deductions and split calculations tied to Lago’s billing data. 3. Stage 3: Advanced Features and UI Enhancements o Introduce a robust payout dashboard for tracking, filtering, and managing payout history. o Add support for multi-currency payouts and more complex split rules (e.g., tiered commissions). o Enable customer-facing payout reports or notifications (e.g., via API or email). o Incorporate user feedback from earlier stages to refine the feature. This phased approach allows Lago to incrementally build and test the payouts feature, ensuring stability and alignment with user needs while leveraging existing billing and metering capabilities. Thank you for considering this suggestion! I’m happy to discuss further or provide more details.

The need to provide an external subscription ID with every event when I have multiple different subscriptions for different users means that I have to query lago for the currently active subscription type. This causes a lot of back and forth for each event. I would instead like to provide the external ID of the user in the event, and no subscription ID, and have lago determine what subscription (potentially plural) to apply the metric to based on the metric code. This would vastly simplify having different user levels (IE a "pro" or "enterprise" user might get decreased per-event usage rates, as opposed to a "basic" user)

Following the new ingestion system, it would be great if we could see in the event logs a list of all "unused" events. By "unused", I mean ingested events that are not currently used in any calculated charges. Use Case 1) I send an event for a subscription and/or a customer but the entity is not yet created in Lago With this new list, I'll be able to see that something is going wrong. 2) I send an event for a newly added group for a billable metric. But I forgot to edit the group in the billable metric. With this new list, I'll be able to see that something is going wrong.

Plan API Add a parameter for searching by name or code, allowing partial matches UI Add some additional filter fields for easier tracking Coupon API Add a parameter for searching by name Add a parameter for filtering by status Add a parameter for filtering by customer_id UI Add a parameter for filtering by status Some other filters I think filtering features are very useful on both UI and API. I hope the team will consider this.

Stripe provides tokenized card information that we would like to retrieve through the Lago API. https://stripe.com/docs/api/tokens/retrieve Showing the card type, last 4 digits and expiration date would enhance the customer experience. For instance, enterprise customers would be able to check whether they've used the right payment method (e.g. hardware card vs recurring services card).

Create a single API endpoint that retrieves customer total lifetime spend

Currently when we create a new customer, we have to make 3 calls Create customer Start subscription Create wallet It would be great if we had the option to create a wallet at the same time as when we create the customer

For self-hosted users, it would be useful to have access to data points to set up Prometheus monitoring.

As a developer, I want to select the types of message that each webhook URL should be listening to, so that we don't have to process a large volume of unnecessary events.

If webhooks fail for an unexpected reason (network issue, etc), we have no way to know about them unless we happen to check. It would be great to set an alert and get notified by email when this happens (like how stripe does)