# How it works (https://docs.billwave.example/getting-started/how-it-works)

How it works [#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 [#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.

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

What Billwave manages [#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 [#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 [#read-next]

* If you still need the object model, read [Data model](/getting-started/data-model)
* If you need to decide how to charge, read [Pricing models](/pricing/pricing-models)
* If you are ready to model plans, read [Plans & products](/pricing/plans)
* If you are ready to run checkout, read [Checkout](/subscriptions/checkout)