> ## Documentation Index
> Fetch the complete documentation index at: https://docs.linquid.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Billing, Plans, and Credits

> Plan entitlements, credit lifecycle, top-ups, feature gates, and billing operations

# Billing, Plans, and Credits

Billing controls feature access, limits, and credit usage.

## Billing page structure

Most workspaces use two billing views:

* **Overview**: current plan, credits, auto top-up, usage, billable events
* **Billing History**: invoice/payment history and cycle records

## Plan model

Plans define:

* available feature families
* usage ceilings
* retention windows
* team and workspace capabilities

Typical feature-gate areas include:

* analytics depth and export surfaces
* conversion and attribution modules
* integration catalog and automation controls
* affiliate program and payout modules
* enterprise identity/governance modules

Plan period typically supports:

* monthly billing
* yearly billing (discounted effective monthly rate)

## Credits and balances

Credits are used for billable analytics/traffic-linked operations depending on your pricing model.

Two pools are commonly visible:

* **Plan credits**: included with subscription and reset each cycle
* **Purchased credits**: add-on balance that does not expire

Track:

* current balance
* usage over billing period
* auto-recharge status
* top-up and ledger history

Balance operations should be monitored for:

* deduction source correctness (which balance pool is used)
* recharge trigger behavior
* failed recharge fallback behavior
* reconciliation between ledger and visible balance

## Billable event model (typical)

Your workspace can be billed by event class. Typical unit costs:

* click events
* fraud checks (higher unit cost than clicks)
* conversion events

Always validate event mix in the Billable Events panel before finance close.

## Auto top-up behavior

Auto top-up is designed to prevent traffic interruption from low balance.

Typical controls:

* enable/disable auto top-up
* threshold amount (trigger when balance drops below this)
* recharge amount (how much to add on trigger)

Operational constraints typically include minimum threshold and minimum recharge amount.

Best practices:

* keep auto top-up enabled in production
* use a threshold above your normal hourly burn
* validate payment method availability

## Upgrades, downgrades, and gates

When plan changes occur:

* feature access changes immediately or at billing transition
* locked features become read-only or unavailable
* limits are re-evaluated against current usage

Downgrade readiness checklist:

* verify which modules will be hidden or restricted
* verify custom domains and integrations that exceed target plan policy
* verify retention policy shift implications for reports and exports
* verify role-based access behavior after gate changes

Typical downgrade side effects to pre-check:

* custom domain behavior on lower plans
* API key and webhook access changes
* advanced routing or analytics feature lockouts
* operational access for team members near new plan limits

## Stripe and billing outcomes

Monitor and handle:

* payment success/failure events
* card update requirements
* subscription state changes
* invoice and retry outcomes

Recommended Stripe sandbox validation before launch:

1. initial subscription success
2. payment failure and retry path
3. card replacement and recovery
4. cancellation and downgrade transition
5. webhook reliability and duplicate delivery handling

## Subscription lifecycle states

Common subscription states include:

* active and renewing
* canceled but active until cycle end
* reactivated before cycle-end downgrade

When canceled, workspace often remains functional until the end-of-cycle date.

## Operational runbooks

### Runbook: Low credit risk

1. Check current balance and burn rate.
2. Confirm auto top-up status and payment method.
3. Buy add-on credits if top-up is disabled or failing.
4. Verify billable event mix anomalies (click/fraud/conversion spikes).

### Runbook: Plan migration review

1. Compare current usage against target plan limits.
2. Identify modules that will be hidden/limited.
3. Confirm data retention impact.
4. Validate post-migration access for key operators.

## Best-practice billing operations

* enable auto-recharge with safe thresholds
* review ledger and usage weekly
* test downgrade behavior before production plan migrations

Related:

* `/user-guides/manual/monetization/currencies-cost-models-and-fx`
* `/user-guides/manual/monetization/plan-gate-validation-playbook`
* `/user-guides/manual/data/data-retention-and-lifecycle`