Product feedback

Having metadata for Plan and Coupon objects are the most important for us. Eg: anyone on plan_A gets awesome_perk_1 and anyone on plan_B gets awesome_perk_2. Currently, we have to store that info in separate tables and make sure they are synced with the lago tables.

Laravel is asking for support of Google Workspace as a SAML identity provider, similar to how Okta is handled.

Currently, Lago lacks direct support for Alipay and WeChat Pay, which are the two overwhelmingly dominant payment methods in mainland China. This poses a significant barrier for any SaaS or digital business using Lago to operate in or sell to the Chinese market. Relying on international credit cards is not a viable strategy in China, as their market penetration for online payments is extremely low compared to the two aforementioned mobile payment giants. Without them, it's practically impossible to process payments from Chinese customers. I propose the direct integration of Alipay and WeChat Pay as first-class payment providers within Lago. A desirable implementation would look like this: Configuration : Admins should be able to securely add their Alipay and/or WeChat Pay merchant credentials directly into the Lago dashboard, similar to how Stripe or Adyen are configured. Payment Method : Customers in the checkout or billing portal should be able to select Alipay or WeChat Pay as their payment method for a subscription or one-time invoice. Payment Flow : Upon selection, Lago should handle the payment intent, which typically involves: * For Alipay: Redirecting the user to a payment page or generating a QR code for them to scan. * For WeChat Pay: Generating a QR code for the user to scan with their mobile app. Status Sync : After the payment is completed, the payment status should be automatically updated back in Lago via webhooks or callbacks, marking the corresponding invoice as paid. The primary alternative is to use a gateway like Stripe, which already supports Alipay and WeChat Pay, and then connect Stripe to Lago. However, this approach has several downsides: * Increased Fees : It introduces an additional layer of transaction fees from the intermediary gateway. * Added Complexity : It complicates the payment stack and introduces another point of failure. Furthermore, and most critically, for companies legally registered in mainland China, using Stripe's global service is not a viable option as it typically does not accept registrations from Chinese entities to process domestic RMB payments. This makes a direct integration of local payment providers into Lago not just a matter of efficiency, but a matter of necessity for this significant user base. ### Additional context Adding support for Alipay and WeChat Pay is not just about adding two more payment options; it's about unlocking one of the world's largest digital economies. * Market Dominance : Alipay and WeChat Pay collectively hold over 90% of the mobile payment market share in China. They are not just popular, they are essential infrastructure for daily life and commerce. * Unlocking a Huge Market : For any B2B or B2C SaaS business, supporting these payment methods is a non-negotiable prerequisite to enter the Chinese market. By implementing this feature, Lago would instantly become a viable solution for a vast number of companies with a global or China-focused strategy. * Competitive Advantage : This feature would be a massive value-add and a key differentiator, making Lago a significantly more attractive billing solution compared to other open-source and commercial alternatives that lack this crucial integration. Thank you for considering this important feature request.

When api key rotation Button is pressed from the UI then a graphql query with this payload is sent. { "operationName": "rotateApiKey", "variables": { "input": { "id": "787d5d1b-47e1-4c98-b802-a0c9d6f4e55d", "expiresAt": "2025-06-17T17:25:32.380Z", "name": "Security Key" } }, "query": "mutation rotateApiKey($input: RotateApiKeyInput!) {\n rotateApiKey(input: $input) {\n id\n ...ApiKeyRevealedForApiKeysList\n __typename\n }\n}\n\nfragment ApiKeyRevealedForApiKeysList on ApiKey {\n id\n value\n __typename\n}" } And the response is this: { "errors": [ { "message": "forbidden", "locations": [ { "line": 2, "column": 3 } ], "path": [ "rotateApiKey" ], "extensions": { "status": 403, "code": "cannot_rotate_with_provided_date" } } ], "data": { "rotateApiKey": null } } I'm using the Open source version of lago

I need the ability to add a specific quantity of a plan, similar to Stripe's feature. The initial invoice should include the charge for the required quantity of the item rather than update future invoices via usage-based API.

When a subscription is set up with a start date in the past, Lago assumes there is no need to generate invoices for periods prior to today. We would like the ability to manually create invoices for these periods in the past.

Invoices are not batched until the renewal period. This means if a customer has multiple subscriptions getting assigned at once or has a subscription plus an add-on fee, the invoices are generated and emailed individually. Second example related to this other feature request: https://getlago.canny.io/feature-requests/p/allow-add-ons-to-be-included-in-subscriptions

As a user, I want to assign coupons that only apply to the subscription fee of the plan (i.e. plan.amount_cents ). It is currently possible to create coupons limited to plans (i.e. including all charges) or to specific billable metrics, but not limited to subscription fees. Example: 20% discount for yearly plans, which would be deducted from the subscription fee, but would not apply to usage-based charges.

We want the prices to be updated when we update them and Lago to do the prorata. Lago does not support it so we have to fall back to end of month updates. But what this means is that even at the end of month there is a buffer period where we can't really update the prices, we'll still announce it but it won't be visible since I have to wait for the end of the grace period. That's a lot of unhappy constraints on the pricing updates. When our competitors announce a price change on the 16th, usage is billed with past price from 1 to 15 and with new prices for the rest of the month.

Let's imagine that Group A has its main entity in France, and two other entities in Spain and in Germany: Each entity may have its own contract (i.e. one subscription per entity), in which case, even if the subscriptions are renewed at the same time, they shouldn't be consolidated. There may be a different payment method for each entity. In addition, Lago should provide aggregated billing data at the group level; or There may be a group contract (i.e. a single subscription that covers all entities), in which case the fees on the invoices should be broken down by entity. Invoices are sent and paid by the main entity.