How it works

Billwave sits between your payment provider and your application.

You model pricing and permissions in Billwave, collect payment through your provider, and then use the SDK to make allow/deny decisions and track usage.

The flow

1. Create an organization. The sandbox already has payment providers wired up; you connect your own provider account when you go live.
2. Create plans and attach features (entitlements).
3. Start a checkout for a customer.
4. Billwave processes provider webhooks and keeps subscription state in sync.
5. Your app calls check() and track() at runtime.

Customer -> Provider Checkout -> Provider Webhooks -> Billwave
                                         |
                                         v
                                  Entitlements + Meters
                                         |
                                         v
                               Your app (SDK: check/track)

What Billwave manages

• Subscription state changes (active, canceled, past-due)
• Plan switching logic (upgrades, downgrades, lateral moves)
• Entitlements provisioning (features granted by a plan)
• Entity lifecycle (adding/removing seats, projects, etc.)
• Usage metering (atomic increments) and credit balance deductions

What you manage

• Your app’s auth/user model
• Where to call check() and track() (middleware, handlers, background jobs)
• Your UI for upgrade prompts and billing pages

Read next

• If you still need the object model, read Data model
• If you need to decide how to charge, read Pricing models
• If you are ready to model plans, read Plans & products
• If you are ready to run checkout, read Checkout