Overview
Start here for GetPaidHQ docs: system model, API reference, billing, usage, dunning, and integration guides.
GetPaidHQ is a processor-agnostic billing system. The docs are split by how you work with it: the API contract, the billing model, usage metering, dunning recovery, and integration concerns.
Where to start
Architecture & Concepts
Runtime shape, core objects, workflow boundaries, and adapter model.
Self-hosting
What you run, which services are required, and how local self-hosting works.
Billing Model
Products, variants, prices, orders, subscriptions, metered prices, and failed-payment recovery.
Usage Metering
Meters, metered prices, event attribution, ingestion modes, and current-period usage.
Dunning Management
Campaigns, retry configuration, communication records, payment-update tokens, and recovery history.
Developer Guide
Integration notes and API Reference.
Deploy
Runtime services, environment variables, migrations, and production checklist.
Release Notes
Public release notes when tagged releases are published.
Core model
- Catalog: products contain variants; variants have prices.
- Checkout: orders collect priced items and customer/payment context.
- Subscriptions: recurring prices become subscriptions when an order is completed.
- Usage: meters define how usage events aggregate for metered prices.
- Recovery: failed subscription charges can open dunning campaigns.
- Runtime: the API server uses pluggable adapters for persistence, workflows, pub/sub, cache, auth, and payment gateways.
Common paths
- Understand the system: Architecture & Concepts
- Self-host the backend: Self-hosting
- Deploy the backend: Deploy
- Build a product catalog: Products
- Create subscriptions: Orders & Checkout
- Manage subscriptions: Subscriptions API
- Send metered usage: Usage & Metering
- Recover failed payments: Dunning Management