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

# Overview

> Configure pricing models and payment terms

Prices define how much you charge for each billable metric within a plan.

## Pricing models

### Standard pricing

Fixed cost per unit. Simple and predictable — and the only model you create. Standard covers flat per-unit rates, percentage-style multipliers, and revenue share.

Every unit costs the same amount regardless of volume. If you charge \$0.001 per token, the 1st token costs the same as the 1,000,000th token.

**Use cases:**

* Flat rate per token
* Fixed cost per GB
* Standard hourly rates
* Per-seat licensing
* Percentage / revenue share (see below)

### Percentage and revenue share (standard multiplier)

To charge a percentage of a value, use a **standard** price whose unit price *is* the rate. The monetary value flows in as the metered quantity, so `quantity × unitPrice` produces the percentage charge — no separate "percentage" model needed.

**Example:** To take 10% of transaction value, create a standard price with `unitPrice: "0.1"`. A \$100 transaction bills \$10 (100 × 0.1). For a 2.9% processing fee, use `unitPrice: "0.029"`; for 1% revenue share, `unitPrice: "0.01"`.

**Use cases:**

* Revenue sharing
* Transaction / processing fees
* Commission models
* Marketplace takes

<Note>
  A standard multiplier is uncapped — there is no per-transaction minimum or maximum charge. If you need caps, apply them in your usage pipeline before sending the metered value.
</Note>

### Legacy models *(read-only)*

`dynamic`, `volume`, and `percentage` are **legacy** models. Prices that already use them keep billing exactly as before, but new prices can no longer be created with them and existing prices can't be switched to them. Use `standard` instead — the API rejects these models on create/update, and the platform UI no longer offers them. The old `percentage` model's min/max caps have no `standard` equivalent (see the note above).

## Payment terms

Control when and how customers are charged for usage.

### In advance

Charge at the start of each billing period before usage occurs. The customer is billed upfront for the upcoming period.

**Perfect for:**

* Recurring subscription fees
* Platform access charges
* Per-seat licensing
* Any fixed fee on Standard Billing plans

### In arrears

Accumulate charges throughout a billing period and bill at period end. Customers pay after usage has occurred.

**Perfect for:**

* Metered usage (tokens, API calls, storage)
* Enterprise contracts with NET payment terms
* Large transaction volumes
* Traditional invoicing workflows

### Instant *(legacy billing only)*

Charge in real-time as each usage event occurs. Money moves immediately from customer accounts.

**Perfect for:**

* Pay-as-you-go services
* Prepaid wallet consumption
* Small, frequent transactions
* Real-time risk management

<Info>
  Standard Billing plans cannot include prices with `paymentTerm: instant`. Attempting to add one returns a `422` error. See [Billing Versions](/platform/billing/billing-versions) for payment term constraints by billing model.
</Info>

## Linking a feature

A price can automatically provision an entitlement when a customer subscribes by linking it to an `entitlementTemplate`. This is how you grant access to features — quota limits, reset periods, and rollover behavior — directly through the plan's pricing.

To grant a feature without charging for it, set `unitPrice: "0"` on the price and attach the `entitlementTemplate`. When a customer subscribes to the plan, the entitlement is provisioned automatically.

Key points:

* The `entitlementTemplate` on the price defines the grant: quota amount, reset cadence, and rollover behavior
* Requires Standard Billing (`billingVersion: 1`)
* A single price can carry at most one entitlement template

See [Features and Entitlements](/platform/pricing/features) for the full configuration reference.

## Combining models

Mix different approaches within one plan to optimize for your business.

**Example: AI Platform**

* Base platform access: \$499/month (standard, in advance)
* Token usage: \$0.002/token (standard, in arrears)
* Enterprise support: \$5000/month (standard, in advance)

**Example: Data Warehouse**

* Storage: \$0.02/GB-month (standard, in arrears)
* Queries: \$0.75/query (standard, in arrears)
* Data export: 1% of monthly bill (standard multiplier, `unitPrice: "0.01"`, in arrears)

## Design principles

**Start simple.** Standard pricing covers 90% of use cases. Add complexity only when needed.

**Match customer expectations.** B2C favors instant payment, B2B prefers invoicing.

## Next steps

* [Features and Entitlements](/platform/pricing/features) — Link features to prices for automatic entitlement provisioning
* [Meter Events](/platform/metering/meter-events) — Send usage data for Standard Billing metered prices
* [Billing Versions](/platform/billing/billing-versions) — Payment term constraints by billing model
* [Manage accounts](/platform/payments/accounts) — Payment collection