Usage-Based Billing dengan n8n + Stripe + PostHog: Bangun Metering → Aggregation → Invoicing → Dunning dalam 7 Hari

2026-04-24 · 9 menit baca

Usage-Based Billing dengan n8n + Stripe + PostHog: Bangun Metering → Aggregation → Invoicing → Dunning dalam 7 Hari

Usage-Based Billing dengan n8n itu game-changer kalau kamu build SaaS yang growth-nya tergantung pemakaian fitur (API calls, tokens, pages processed, job minutes). Masalahnya, banyak founder dan dev kebentur di titik yang sama: event usage nyasar, aggregate berantakan, invoice meleset, dan dunning manual menguras waktu. Akhirnya pricing terlihat “ngadi-ngadi” di mata pelanggan dan churn meningkat.

Di artikel ini kita bikin pipeline end-to-end yang praktis: metering (event tracking), aggregation (periode billing), invoicing (Stripe metered/dynamic invoice), sampai dunning (penagihan + penjelasan otomatis pakai AI Agent) — semuanya diorkestrasi oleh n8n automation. Fokusnya bukan teori, tapi blueprint yang bisa kamu clone dan iterasi cepat ala vibe coding.

Hook: Kenapa Usage-Based Billing sering bikin pusing?

Event usage datang dari banyak service, format beda-beda, dan sering late-arrival.
Deduplikasi lemah → invoice gembung. Deduplikasi agresif → revenue bocor.
Stripe metered billing itu mantap, tapi reporting usage ke Stripe tanpa idempotency + watermark = bom waktu.
Customer minta penjelasan line-item, kamu cuma punya total angka tanpa “jejak bukti”.
Dunning manual bikin capek, dan kadang nyebar spam tanpa konteks penggunaan pelanggan.

Aha moment: Perlakukan billing seperti data pipeline dengan invariant yang jelas (idempotency, watermark, reconciliation), bukan sebagai “fitur keuangan” belaka.

Konsep Inti (ringkas, no textbook)

Metering: event “apa yang dipakai” dengan schema minimal, timestamp akurat, dan usage_key deterministik untuk dedupe.
Aggregation: rolling window per pelanggan (periode billing) dengan toleransi late events via watermark (contoh: tutup periode H+2).
Invoicing: dua mode praktis
- Stripe Metered: kirim usage records ke subscription item.
- Dynamic Invoice: bikin invoice items dari aggregate.
Dunning + AI Agent: otomatis kirim reminder yang context-aware (pakai data usage pelanggan), eskalasi bertahap, dan siapin “penjelasan tagihan” on demand.

Arsitektur Teknis: Overview

Ingest: Webhook n8n, atau integrasi PostHog/Segment sebagai event source.
Storage: Postgres (Supabase) untuk event usage + aggregates. Redis untuk cache/dedupe cepat.
Orkestrasi: n8n workflows (cron aggregation, webhook ingest, Stripe job, dunning bot).
AI Agent: LLM via OpenAI/HF untuk generate penjelasan tagihan, email dunning adaptif, dan anomali reasoning.

Usage-Based Billing dengan n8n: Desain Event Metering

Mulai dari event yang rapi. Minimal schema seperti ini:

{
  "event": "ocr.page_processed",
  "usage_key": "org_123|2026-04|doc_987|page_10", 
  "org_id": "org_123",
  "unit": "page",
  "quantity": 1,
  "occurred_at": "2026-04-22T10:23:45.321Z",
  "metadata": { "doc_id": "doc_987", "model": "ocr-v2" }
}

usage_key: kunci deterministik yang unik per unit usage. Ini kunci idempotency kamu.
quantity: boleh >1 (mis. batch). Kalau bisa, normalisasi ke unit terkecil (page, token).
occurred_at: waktu kejadian nyata, bukan waktu ingest.

Usage-Based Billing dengan n8n: Workflow Ingest + Dedupe

Bangun workflow n8n “Usage Ingest”:

Trigger: Webhook (atau PostHog Webhook → HTTP Request ke n8n).
Validate: Function node (schema check, required fields).
Dedupe: Redis node (SETNX usage_key → TTL 90 hari). Kalau sudah ada, drop.
Persist: Postgres node (INSERT ke table usage_events).
Dead-letter: Kalau gagal, kirim ke queue DLQ (mis. Kafka/SQS) atau table errors.

Contoh pseudo Function node (idempotency guard di n8n):

// input: items[0].json = event
const e = item.json
if(!e.usage_key || !e.org_id || !e.quantity || !e.occurred_at){
  throw new Error('invalid event')
}
return [{ json: { ...e, received_at: new Date().toISOString() } }]

Usage-Based Billing dengan n8n: Aggregation Window + Watermark

Workflow “Daily Aggregation” (Cron harian/jam-jaman):

Hitung periode: ambil semua open billing periods per org (mis. bulan berjalan) + grace H+2.
Aggregate: SQL query di Postgres, group by org_id, unit, period. Simpan ke usage_aggregate.
Reconcile: bandingkan total hari ini vs kemarin (delta). Simpan delta untuk reporting ke Stripe.
Anomali: If usage naik > X% dalam 1 jam, tag “spike” → kirim alert Slack + aktifkan guardrail (rate limit sementara via AI Agent reasoning).

SQL agregasi contoh (Postgres):

INSERT INTO usage_aggregate (period, org_id, unit, quantity, updated_at)
SELECT period_tag(e.occurred_at) AS period,
       e.org_id,
       e.unit,
       SUM(e.quantity) AS quantity,
       NOW()
FROM usage_events e
WHERE e.occurred_at BETWEEN period_start() AND watermark_end()
GROUP BY 1,2,3
ON CONFLICT (period, org_id, unit)
DO UPDATE SET quantity = EXCLUDED.quantity, updated_at = NOW();

Catatan:

period_tag(), period_start(), watermark_end() bisa kamu implementasi di Function node lalu pass sebagai parameter.
Watermark memastikan event telat tetap terhitung sampai H+2 sebelum periode benar-benar “closed”.

Integrasi Stripe: Metered vs Dynamic Invoice

Opsi A — Stripe Metered Billing

Bikin Price di Stripe dengan recurring.usage_type = metered, aggregate_usage = sum.
Setiap kali agregasi jalan, kirim usage record ke subscription item terkait.

n8n nodes:

Cron → Postgres (ambil delta usage) → HTTP Request (Stripe API) → If (error) → Retry/Dead-letter.

Contoh payload Stripe usage record:

POST /v1/subscription_items/{SUB_ITEM_ID}/usage_records
{
  "action": "set",
  "quantity": 1200,
  "timestamp": 1713859200, // epoch period end (daily)
  "idempotency_key": "org_123|2026-04-22|page" 
}

Tips: kirim “set” total kumulatif per hari (bukan increment), supaya idempotent. Stripe akan hitung per period.

Opsi B — Dynamic Invoice Items

Tidak pakai metered price. Di akhir periode (H+2), buat invoice baru dan tambahkan line-items sesuai aggregate.

n8n nodes:

Cron (period close) → Postgres (get aggregates) → HTTP Request (Stripe Invoice create) → loop add invoice items → finalize.

Gunakan metadata yang kaya agar customer bisa audit sendiri (unit, period, link dashboard usage).

Dunning & Penjelasan Tagihan Otomatis dengan AI Agent

Dunning jangan sekadar “ingatkan bayar”. Tambahkan konteks usage untuk menurunkan friction.

Step 1: Invoice issued → n8n trigger via Stripe webhook invoice.finalized.
Step 2: AI Agent generate email yang berisi ringkasan penggunaan: “Bulan ini 12.430 page, 3x spike karena batch upload pada 11, 18, 21.”
Step 3: Kalau invoice.payment_failed, AI Agent menyusun rencana follow-up bertahap (hari ke-3, ke-7, ke-14), channel-aware (email → WhatsApp/Slack Connect), menyertakan tombol “lihat detail penggunaan”.
Step 4: Jika user protes, AI Agent siapkan usage ledger berbasis query ke Postgres (read-only) dan menyusun penjelasan per dokumen.

Prompt ringkas yang efektif:

"You are a billing assistant. Given the customer's usage summary and anomalies, draft a concise, friendly email in Indonesian that explains the invoice line items, calls out spikes by date, and proposes 2 plan suggestions if usage stays at current trend. Keep it to 120-150 words."

Use Case Nyata: SaaS OCR AI “Bayar per Halaman”

Anggap kamu punya layanan OCR AI untuk UMKM. Harga: Rp150/halaman, ditagih bulanan, ada subscription base Rp99.000. Target: Usage-Based Billing dengan n8n yang clean.

Event: setiap halaman selesai diproses, service kirim event ke n8n webhook dengan usage_key berbasis org|period|doc|page.
Ingest: n8n validasi + Redis dedupe + simpan ke usage_events.
Aggregation harian: Cron hitung total per org per hari dan per bulan (kumulatif).
Stripe: pakai Metered Billing. n8n kirim “set” quantity harian ke subscription_item “Pages”.
Anomali: Kalau naik >200% dalam 2 jam, AI Agent membuat ticket internal: “Cek apakah ini batch legit? Kirim heads-up email ke admin org.”
Penutupan periode (H+2): final push usage ke Stripe, finalize invoice.
Dunning: kalau gagal bayar, AI Agent kirim reminder dengan ringkasan penggunaan plus opsi downgrade/limit sementara.

Hasilnya: invoice akurat, ada “jejak bukti” usage, dan komunikasi ke pelanggan jauh lebih jelas.

Breakdown Teknis n8n: Node-by-Node

Workflow 1 — Usage Ingest

Webhook (POST /usage)
Function (validate schema)
Redis (SETNX usage_key → if 0, stop)
Set (normalize fields: period_tag, day_bucket)
Postgres (INSERT into usage_events)
Slack (alert on schema violations)

Workflow 2 — Daily Aggregation

Cron (0 * * * * / hourly)
Function (compute watermark)
Postgres (UPSERT aggregates)
Postgres (compute delta since last run)
IF (delta > threshold) → Slack + AI Agent (compose internal note)

Workflow 3 — Stripe Reporter

Cron (every 6 hours)
Postgres (fetch delta to report)
HTTP Request (Stripe usage_records, idempotency-key = period|org|unit|bucket)
Postgres (mark reported_at)
IF (error) → Retry with exponential backoff + DLQ

Workflow 4 — Dunning & Explainer

Stripe Webhook (invoice.finalized/payment_failed)
Postgres (fetch usage summary)
AI Agent (draft personalized email)
Email/WhatsApp (send)
CRM (log activity; e.g., HubSpot/Pipedrive)

Strategi & Insight yang Bikin Stabil

Single source of truth: semua kalkulasi diturunkan dari usage_events di Postgres. Stripe cuma “pembukuan eksternal”.
Idempotency everywhere: usage_key di event, idempotency-key saat push ke Stripe, dan checksum untuk aggregates.
Watermark realistis: minimal H+1 atau H+2 untuk mengakomodasi event telat. Jangan tutup periode di H+0.
Late-arrival handler: kalau ada event telat setelah invoice final, kirim credit note/invoice adjustment otomatis (n8n flow kecil).
Explainability: simpan usage ledger yang bisa difilter per tanggal/doc. Ini meredakan protes pelanggan.
Guardrails teknis:
- Quota + rate limit adaptif (switch via feature flag kalau spike aneh).
- Cost ceiling per hari dengan notifikasi sebelum overrun.
- Shadow-meter: bandingkan usage “server-side” vs “client-side” (PostHog/Segment) untuk deteksi kebocoran.
Model harga yang jelas: bundling base fee + metered unit. Tampilkan real-time usage ke customer via mini-dashboard (embed chart dari aggregates).
Vibe coding approach:
- Hari 1–2: event schema + ingest + dedupe.
- Hari 3: aggregation + delta + spike alert.
- Hari 4: Stripe metered push.
- Hari 5: dunning v1 (email sederhana).
- Hari 6–7: AI Agent explainer + portal usage.

Edge Case Penting yang Sering Terlewat

Proration: upgrade plan di tengah periode. Solusi: split aggregate per plan_version_window (Function node hitung window).
Multi-unit: kalau ada dua unit (pages + storage GB), kirim dua subscription_item terpisah atau dua line-item.
Free tier: cap usage gratis, sisanya ditagih. Implement di aggregation (min(usage, free_quota)).
Backfill: kalau pipeline sempat down, jalankan job backfill berdasarkan occurred_at, bukan received_at.
Reconciliation: job mingguan bandingkan total aggregate internal vs Stripe usage summaries. Jika deviasi >1%, buat ticket otomatis.

Implementasi API & Contoh Konfigurasi

PostHog: kirim event server-side capture() dengan properties lengkap; set Webhook ke endpoint n8n.
Stripe: gunakan Usage Records untuk metered, atau Invoice + Invoice Items untuk dynamic. Simpan subscription_item_id per org di DB.
Supabase: tabel usage_events, usage_aggregate, usage_push_log, billing_period.
n8n: aktifkan queue mode untuk job yang berat, tambahkan idempotency guard di setiap HTTP Request via header.

Checklist Go-Live (Praktis)

[] Event schema dikunci + versioning.
[] Redis dedupe berjalan + TTL masuk akal (≥ 1 periode + buffer).
[] Watermark H+2 dan job backfill siap.
[] Reconciliation weekly + toleransi deviasi jelas.
[] Stripe test mode: skenario pay_failed, disputed, refunded.
[] AI Agent prompt dilatih dengan 3–5 contoh invoice nyata.
[] Customer portal: grafik usage harian + export CSV.

Penutup: Saatnya Build

Dengan Usage-Based Billing dengan n8n, kamu bisa mengubah billing dari “beban” jadi “keunggulan produk”. Kuncinya ada di event yang rapi, watermark yang disiplin, dan orkestrasi workflow yang tahan banting. Stripe mengurus pembayaran; kamu memastikan metering + aggregation akurat dan bisa dijelaskan. AI Agent bantu komunikasi dan dunning yang manusiawi.

Next step: mulai dari Usage Ingest workflow. Setelah itu, tambahkan aggregation + push ke Stripe. Terakhir, aktifkan AI Agent untuk dunning dan explainer. Iterasi cepat selama seminggu — dan kamu sudah punya billing modern yang siap scale.

Ping kami di JIPRAKS Classroom kalau mau template n8n + skema DB + contoh prompt AI Agent. Let’s ship!

Usage-Based Billing dengan n8n + Stripe + PostHog: Bangun Metering → Aggregation → Invoicing → Dunning dalam 7 Hari