How to charge customers per event without generating a per-event invoice

Last updated: July 6, 2026

If you want to charge customers as they consume usage, but without sending an invoice for every individual event, combine a pay-in-arrears charge with a Lago wallet and its ongoing balance. The wallet tracks unbilled usage in real time, so you can gate access on available credit while still billing everything on a single invoice per period.

This pattern gives you:

  • No invoice per event

  • Automatic credit deduction as usage accumulates

  • A single invoice per billing period, with wallet credits applied automatically

  • Optional automated top-ups when the balance runs low

This requires a premium wallet feature. Ongoing balance tracking is part of Lago Cloud and Self-Hosted Premium. On free self-hosted Lago the ongoing balance is never recalculated, so a threshold-based top-up rule (which monitors the ongoing balance) will never fire. The API accepts the rule without error, so this fails silently rather than with a visible error.

How it works

A wallet has two balance figures:

  • Balance: settled credit currently available.

  • Ongoing balance: balance minus the cost of usage already recorded this period but not yet invoiced.

When a customer generates a billable event, the cost is deducted from the ongoing balance immediately, before that usage is ever invoiced. Check this figure before allowing a billable action to gate access on available credit.

At the end of the billing period, Lago generates one invoice covering all usage for that period and applies wallet credits to it automatically, reducing or eliminating the amount due to the payment provider.

Setup

  1. Create your billable metric with the appropriate aggregation type.

  2. Create a plan with that billable metric as a charge, set to pay in arrears, with the per-unit price defined. Pay-in-arrears is required here: pay-in-advance usage does not affect the ongoing balance.

  3. Create a wallet for the customer. Optionally add a recurring top-up rule (see below).

  4. Before allowing a billable action, retrieve the wallet and check ongoing_balance_cents (or credits_ongoing_balance for the credit-unit value). If it covers the cost of the action, proceed; if not, prompt a top-up.

The ongoing balance is recalculated periodically, on the order of minutes, not instantly on every event. In high-concurrency scenarios there is a small window where a customer could proceed without sufficient balance; account for this in your application logic if revenue protection is critical.

As a push-based alternative to polling the balance, Lago also fires a wallet.depleted_ongoing_balance webhook when the ongoing balance reaches zero.

Automated wallet top-ups

To avoid manually monitoring balances, add a threshold-based recurring top-up rule to the wallet. When the ongoing balance drops below the threshold, Lago generates a top-up invoice against the customer's payment method and adds the credits once payment succeeds.

Set this on the recurring transaction rule when creating the wallet: a threshold trigger with a threshold_credits value (the balance that triggers a top-up) and a paid_credits value (how many credits to add). To add or change the rule on an existing wallet, update the wallet's recurring transaction rules with PUT /api/v1/wallets/{lago_id}.

What the customer receives

  • One invoice per top-up, for the funding amount.

  • One invoice per billing period, summarizing usage, typically covered fully or partially by wallet credits.

Customers aren't invoiced for individual events. A mid-period charge on their card corresponds to a wallet top-up invoice, not a usage event.

This article reflects guidance drawn from customer case resolutions. It is not officially supported documentation and may not apply to all situations.