Product feedback

Native payment provider integration for usage-based billing. Why We Want to Integrate with Lago? Dodo Payments serves global markets with Merchant of Record capabilities. This integration would: • Complement Lago's existing providers (Stripe, Adyen, GoCardless) with coverage in underserved regions. • Follow the partnership model established with MoneyHash for regional payment processors. Be maintained long-term by the Dodo Payments team. This aligns with Lago's stated goal of supporting local payment processors alongside global providers. Summary: This issue tracks building a first-class integration between Lago (usage-based billing) and Dodo Payments to support automatic invoice charging, realtime webhook sync, and refunds. The integration should be usable either as a native Ruby (Rails) plugin for Lago or as a lightweight TypeScript/Bun microservice. Goals: • Create payment intents in Dodo when Lago emits invoice.created . • Update Lago invoice/payment state on Dodo webhook events ( payment.succeeded , payment.failed , payment.refunded ). • Support refund flows by creating Lago credit notes when Dodo reports refunds. • Provide secure, idempotent webhook handling with HMAC verification. • Provide clear setup docs and example code for both native and microservice approaches. Acceptance Criteria • When an invoice is created in Lago, a Dodo payment intent is created with lago_invoice_id in metadata. • payment.succeeded marks the Lago invoice as paid . • payment.failed marks the Lago invoice as failed and triggers retry logic per config. • payment.refunded creates a Lago credit note and links to the original invoice. • All webhooks validated via HMAC; log & retry on transient failures. • Integration can be deployed as a Docker container and run with env vars only. • README and docs include setup, testing, and troubleshooting steps. Requirements Lago >= v1.0 Microservice: Bun >= 1.0 / Node 18+ (TypeScript) PostgreSQL 14+ (for microservice if persistence needed) Dodo API & webhook keys (sandbox/live) TLS/HTTPS for webhook endpoints Auth / Headers: Dodo: Authorization: Bearer DODO_API_KEY Lago: Authorization: Bearer LAGO_API_KEY Webhook mapping: Source: Lago • Event: invoice.created • Action: Create a Dodo payment intent (with metadata lago_invoice_id) Source: Dodo • Event: payment.succeeded • Action: Mark the Lago invoice as paid Source: Dodo • Event: payment.failed • Action: Mark the Lago invoice as failed and trigger retry logic Source: Dodo • Event: payment.refunded • Action: Create a Lago credit note and link it to the invoice Webhook endpoints: • Dodo → Integration: POST https://<HOST>/webhooks/dodo • Lago → Integration: POST https://<HOST>/webhooks/lago Retry & Idempotency: • Persist dodo_payment_id ↔ lago_invoice_id mapping to prevent double-processing. • Use Dodo idempotency keys for create payment intent requests (e.g., Idempotency-Key: lago-inv-<id> ). • Webhook handler should: • Verify HMAC signature. • Check if event has been processed (by event id). • Acknowledge 2xx on success; return 5xx for transient errors to allow retries. Security: • Validate webhooks using Dodo's HMAC signature and configured secret. • Store API keys in env variables / secrets manager (never commit). • Minimum permissions for API keys: only required scopes for payments and webhooks. Implementation tasks (checklist): • Design DB schema for mapping and event dedupe (microservice). • Implement invoice.created handler → create Dodo payment intent. • Implement Dodo webhook handler with HMAC verification. • Implement Lago API updates for payment status and credit notes. • Add retry/exponential backoff for transient failures. • Add configuration entries to Lago admin UI (API key, mode, webhook secret). • Write unit & integration tests (bun test / rspec). • Create Dockerfile & Helm chart (optional) for deployment. • Write README / install & troubleshooting docs. Testing: • Run local service and expose with localtunnel (or use sandbox webhook tools). • Test flow: 1. Create a test invoice in Lago (sandbox). 2. Verify integration creates a Dodo payment intent (checkout URL). 3. Complete the sandbox payment; check Dodo emits payment.succeeded . 4. Verify Lago invoice updates to paid . • Commands: bun test npx localtunnel --port 3000

Customers cannot currently associate a one-off invoice with a specific plan. As a result, exported one-off invoice data cannot be grouped or analyzed by plan without manual adjustments. Add an optional plan association when creating a one-off invoice through the UI and API. Include the associated plan in relevant invoice exports. This association should be reporting metadata only. It should not cause the invoice to inherit the plan’s pricing, charges, or subscription behavior.

Currently, the only webhooks for credits notes are: credit_note.created credit_note.generated credit_note.provider_refund_failure There is no credit_note.updated / credit_note.refunded for example. Please add more webhooks so that, at minimum, we can know when a refund was successful.

Although billing data can be retrieved via the API, Finance teams need to visualize and export data from the API. This is highly important for revenue recognition reporting purposes.

## Context First of all, congratulations to the Lago team — it’s one of the most robust and transparent open-source billing platforms available today. However, deploying Lago self-hosted is still complex and time-consuming, especially for users who want to run it on modern PaaS platforms — both self-hosted and managed cloud solutions . I’ve personally tried to deploy Lago multiple times, even with step-by-step help from ChatGPT, and still couldn’t get it running properly . Most of the issues were related to environment variables, RSA key formatting, and networking between containers ( api , front , worker , clock , pdf , postgres , redis ). Today, many developers use platforms like: ### 🧩 PaaS Self-Hosted Coolify Cloudfy EasyPanel Dokku — GitHub Dokploy CapRover Portainer Tipi Yacht ### ☁️ PaaS Hosted (Managed) Railway Vercel Netlify [ Fly.io ]( https://fly.io ) Orion Ploi These tools have become the modern standard for developers who want “self-hosted Heroku-like” experiences — a simple, visual way to deploy Docker-based applications in production environments. Unfortunately, **Lago currently doesn’t provide an official docker-compose.yml or manifest optimized for these deployers**, which makes installation difficult even for experienced users. --- ## The problem The current documentation focuses on local Docker setup and manual orchestration. There’s no verified YAML definition for external PaaS or automated deployers. Lago’s multi-service stack — api , front , worker , clock , pdf , postgres , and redis — requires precise networking and environment configuration. Variables like LAGO_RSA_PRIVATE_KEY (multiline PEM) and LAGO_API_URL are especially error-prone when set inside UI-based deployers. Common issues include: - API container crashing due to RSA key parsing errors; - Worker and clock services restarting endlessly; - Frontend failing to connect to the backend; - Health checks failing even when containers are technically running. --- ## Why it matters An **official, deployer-friendly docker-compose.yml ** would: Enable one-click deployment on platforms like Coolify, Dokku, CapRover, and Railway; Reduce onboarding friction and YAML misconfigurations; Make Lago more accessible to small SaaS teams, indie devs, and startups that use PaaS tools; Increase adoption among self-hosted users who prefer visual or low-code deployers; Strengthen Lago’s ecosystem as the open-source alternative to Stripe Billing that anyone can run in production. --- ## Suggested improvements **Provide an official docker-compose.yml ** optimized for external deployers (not just local development); Include an example .env with: - Proper variable formatting; - Comments explaining multi-line secrets (e.g., LAGO_RSA_PRIVATE_KEY ); - URL guidance for internal vs. external routing; Add short documentation or notes about deploying Lago in self-hosted PaaS platforms; Optionally, verify the setup on at least one environment (Coolify, Dokku, or Railway). --- ## Closing thoughts Lago is an amazing open-source project that deserves a smoother deployment experience. Offering a **ready-to-use YAML and .env example** compatible with self-hosted and cloud PaaS environments would dramatically lower the barrier to entry — helping more developers successfully self-host their billing systems. Thank you for considering this request and for building such an impactful open-source project.

Add a “Send invoice email” option to the custom void/regenerate flow, enabled by default. When disabled, Lago should not send the invoice.finalized notification email for the regenerated invoice. This suppression should apply only to that specific operation, including invoices finalized asynchronously through a tax provider. Currently, the only workaround is to temporarily disable invoice.finalized emails at the billing-entity level, which can unintentionally suppress notifications for other invoices finalized during the same period. Existing behavior should remain unchanged when the option is enabled or omitted.

As a user, I want to be able to define a billing interval for the subscription fee and each charge. The yearly plan currently supports monthly charges, but we would need more flexibility. For instance, for plan A: Yearly subscription fee; and Usage-based charge X billed quarterly. Another example for plan B: Monthly subscription fee; Usage-based charge X billed monthly; and Usage-based charge Y billed quarterly.

Can we get more customization on the export invoices under invoices? I'd like to be able to see customer name in the Advanced export as well as the current Plan that a customer is on - this is more important now that we have our enterprise customers in billing. The use case here is that i'm trying to make sure we export the enterprise invoices from lago and import them into QBO

I can´t seem to find a way to associate entitlements for add-ons. I want customers that have purchased add-ons to receive specific entitlements. Is this something that would make sense or am I misunderstanding the concept of add-ons?

Once a billable metric is attached to a plan, only its name and description can be edited. Calculation and display properties like rounding function, rounding precision, aggregation expression, and unit label are locked. The only workaround is to delete and recreate the metric under the same code