Pains of building your own billing system

Original Article ↗ Hacker News Discussion ↗

Building your own billing system for a SaaS or online business often seems straightforward but quickly spirals into complexity around taxes, proration, refunds, entitlements, legal compliance, rounding rules, and integration with accounting and payment processors. Many engineers who’ve done it warn that it diverts huge time and risk away from core product work, arguing in favor of specialized billing platforms or merchant-of-record services—while a minority counter that constrained, incremental in-house systems can be viable for simple or early-stage needs. A recurring theme is the value of separating billing from entitlements and treating billing as a rigorously auditable, policy-driven subsystem rather than a set of ad hoc scripts glued to Stripe or similar APIs.

Build vs Buy for Billing

  • Strong consensus that billing is deceptively complex; many argue most companies should not build their own and should use Stripe/Braintree/Chargebee/Lago/killbill/etc.
  • Counter‑view: for simple products or early stages you can start small, build incrementally, and accept some manual work; over‑general “never build” advice is seen as overstated.
  • Another view: you build if billing is core to your business or you operate where major providers don’t work (e.g., some non‑US/EU jurisdictions).

Complexity and Hidden Edge Cases

  • Real pain is in the long tail: proration rules, upgrades/downgrades, grandfathering, trials, custom enterprise deals, affiliate payouts, refunds/chargebacks, and running the entire flow “backwards” (credits, corrections, partial returns).
  • Time zones, different billing cycles, forward vs arrears billing, usage‑based pricing, tiered discounts, and rounding behavior all interact in non‑obvious ways.
  • Many accounts of homegrown systems causing large financial losses via rounding bugs, scaling issues, and fragile “duct‑tape” logic.

Entitlements vs Billing

  • Strong endorsement of separating billing (money, invoices, rev‑rec) from entitlements (what the customer can actually use).
  • Suggested architecture: entitlements store capabilities/limits; billing computes charges; a separate policy layer ties them together and supports one‑offs and manual tweaks.
  • Debate on using feature flags for entitlements: convenient and flexible, but risks overloading one system; some prefer dedicated entitlement/authorization services.

Security, Compliance, and Regulation

  • Discussion around “dump a file in S3 + cron” idea: viewed as naïve, but technically can be made robust; encryption in transit/at rest is standard but may not meet stricter threat models.
  • Some argue only client‑side encryption with independent keys truly fulfills “encrypted at rest” intent.
  • Conflicting claims about EU rules: several clarify that writing your own billing is allowed; regulation mainly targets payment processing and PSD2 flows, not in‑house invoicing.

Accounting, Taxes, and Legal Issues

  • Integrating with accounting/ERP, revenue recognition, cash‑in‑transit matching, month/quarter close, and auditability are major burdens.
  • VAT/sales tax, different country rules, corrective invoices, document numbering, and retention requirements are described as soul‑sucking but mandatory.
  • Mistakes can lead to fines or worse; you must be able to explain “why this customer paid this amount.”

Tools and Platforms

  • Stripe praised for making payments easy, but criticized for confusing APIs, weak higher‑level abstractions, and operational gaps (webhook loss, state sync).
  • Open‑source and commercial billing platforms (e.g., generic OSS engines, usage‑based billing startups, merchant‑of‑record services) are mentioned as options, though pricing opacity is a common complaint.

Design Patterns and Anti‑Patterns

  • Recommended patterns: clear separation of concerns (entitlements vs ledger vs invoicing), ledger‑style accounting, scheduled processes instead of real‑time coupling, idempotent operations, configurable rounding rules.
  • Anti‑patterns: monolithic “billing blob,” tightly coupling entitlements to payments, real‑time side‑effects everywhere, and naive state‑machine histories that don’t scale.

Anecdotes and Attitudes

  • Stories include “magic money” checks from insurers, chaotic healthcare AR reconciliation, travel and telco systems that became unmaintainable, and a small success story where custom billing unlocked flexible payment methods.
  • Several experienced engineers compare billing to “septic plumbing”: unpleasant, risky, and under‑appreciated, but technically interesting and always in demand.