How to build usage-based billing with GoHighLevel and Stripe

Short answer: GoHighLevel cannot meter usage by itself. To bill per conversation, per seat, per location or per event, you need three pieces: a way to capture billable events from GHL, a ledger that records and deduplicates them, and a Stripe integration that turns ledger totals into metered invoices. We build this with n8n for capture and orchestration, Supabase for the ledger, and Stripe's subscriptions and metered billing for invoicing.

Who needs this

Agencies billing sub-accounts per seat or per location. SaaS-mode operators billing on conversations or contacts. Service businesses invoicing by milestone as deals move through a pipeline. Anyone currently counting usage in a spreadsheet at month end.

The architecture

1. Event capture

GoHighLevel webhooks and workflow triggers emit the events that matter: a conversation started, an appointment completed, a sub-account created, a pipeline stage reached. n8n receives them on authenticated endpoints, validates the payload and normalizes it into a standard billable-event shape with a stable event identifier.

2. The ledger

Every normalized event is written to a Supabase (Postgres) table with a unique constraint on the event identifier, so retried webhooks cannot double count. The ledger also holds the mapping between GHL contacts or sub-accounts and Stripe customers, plus an error table for anything that failed validation. This table is the single source of truth for what was billed and why.

3. Stripe invoicing

On the billing schedule, a flow aggregates ledger totals per customer and reports them as usage to Stripe metered subscription items, or creates one-off invoice items for milestone charges. Stripe generates the invoice, collects payment and emits its own webhooks for paid, failed and disputed events.

4. Status back to the CRM

Stripe payment webhooks flow back through n8n and update the GoHighLevel contact: plan, status, last payment, days past due. GHL workflows then act on those fields, sending dunning messages, pausing service or triggering a win-back sequence.

Phase it

1. Subscriptions and status sync. Stripe products and plans connected to GHL, payment status flowing back to contacts. Immediate value, low risk.
2. Metering. Event capture, ledger and metered invoicing. Run in parallel with manual billing for one cycle and reconcile.
3. Dunning and reporting. Recovery sequences, service gating and dashboards built from the ledger.

Edge cases that break naive builds

• Webhooks are retried. Without a unique event identifier you will bill twice.
• Events arrive out of order. Use event timestamps, not arrival time, for period assignment.
• Customers dispute. Without a ledger you have no evidence.
• Plans change mid-period. Let Stripe handle proration; do not reimplement it.
• Test and live keys get mixed. Separate environments and restricted API keys from day one.

Who owns it

The client. The n8n instance, the Supabase project and the Stripe account are theirs, with documentation and runbooks. A billing system you cannot inspect is a liability, not an asset.

We designed a conversation-based version of this architecture for a client billing on GoHighLevel usage. Read the case study or see the service.