Examples of plans with included credits

Overview

Credit benefits let you bundle prepaid usage with pricing that is not itself a prepaid credit purchase. This is useful when you want a plan or fee to include an allowance, such as:

• A monthly subscription that includes API credits
• A one-time onboarding package that includes setup usage
• A seat-based plan where each seat gets its own monthly allowance

The examples below focus on how these benefits behave from the customer’s point of view.

One-time fee with included credits

Use this pattern when you sell a one-time bundle of credits without a recurring subscription.

Example:

• One-time credit purchase: $500
• Included benefit: 10,000 API Credits

Customer experience:

• The customer pays once
• Paid grants a 10,000 credit allocation
• Usage spends down that balance until it reaches zero

This is useful when customers want to buy credits in bulk upfront, top up on demand, or purchase a starter pack to try your product.

Recurring platform fee with included credits

Use this pattern when a recurring subscription should include a fresh allowance each billing period.

Example:

• Platform fee: $99/month
• Included benefit: 1,000 API Credits per month

Customer experience:

• The customer is billed monthly for the plan
• At the start of each billing period, Paid grants a new 1,000 credit allocation
• Any rollover rules are applied based on your configuration

This is the most common model for subscription plans with included usage.

Seat-based pricing with organization-level credits

Use this pattern when you sell seats, but want the included credits to be shared across the whole customer account.

Example:

• Seat price: $40 per seat per month
• Included benefit: 500 Messages per seat
• Recipient: organization

If the customer has 10 seats:

• The customer pays for 10 seats
• Paid grants 5,000 shared message credits
• Any user in the account can draw from the same pool

This works well when the customer cares about the total account allowance more than the per-user split.

Seat-based pricing with seat-level credits

Use this pattern when each seat should receive its own allowance rather than sharing one pool.

Example:

• Seat price: $40 per seat per month
• Included benefit: 500 Messages per seat
• Recipient: seat

Customer experience:

• Each seat receives its own credit allocation
• Heavy usage by one seat does not automatically consume another seat’s allowance
• The balance response can distinguish these seat-scoped allowances from organization-wide balances

This works well when usage limits should map directly to licensed users.

One product, multiple credit benefits

You can include more than one credit benefit on the same product when the customer receives different usage allowances together.

Example:

• Platform fee: $499/month
• Included benefits:
  • 10,000 API Credits
  • 2,000 Workflow Credits

Customer experience:

• The customer receives separate balances for each credit currency
• Usage in one currency does not reduce the balance of the other

This is useful when your product has more than one metered resource and customers need separate visibility for each one.

Allocation cadence examples

Credit benefits can be allocated on different cadences inside a billing term.

Upfront allocation

Example:

• Annual plan: $12,000/year
• Included benefit: 120,000 API Credits
• Allocation cadence: upfront

Customer experience:

• The full 120,000 credits are granted at the start of the annual term

Monthly allocation inside a longer term

Example:

• Annual plan: $12,000/year
• Included benefit: 120,000 API Credits
• Allocation cadence: monthly

Customer experience:

• Credits are granted in monthly portions instead of all at once
• A typical outcome would be 10,000 credits becoming available each month during the annual term

This is useful when you want annual contract pricing but do not want the full annual allowance usable on day one.

Grant timing examples

Credit benefits can also become available at different times.

On order activation

Use this when credits should be usable as soon as the order or billing period starts.

On payment

Use this when credits should remain pending until the related invoice is paid.

This is useful when you want credit access to follow payment collection more strictly.

Credit rollover

By default, unused credits expire at the end of each allocation period. Rollover lets you carry a portion of unused credits into the next period so customers are not penalized for uneven usage.

Rollover cap

The rollover cap controls how many unused credits can carry forward. If credits remaining at the end of a period exceed the cap, the excess expires.

Example:

• Platform fee: $99/month
• Included benefit: 1,000 API Credits per month
• Rollover cap: 500

If the customer uses 700 credits in a billing period:

• Remaining: 300
• Rolled over: 300 (under the cap)
• Expired: 0

If the customer uses 200 credits:

• Remaining: 800
• Rolled over: 500 (capped)
• Expired: 300

Rollover expiry

Rolled-over credits do not last forever. By default they expire after one allocation period. You can set a custom expiry window using a duration and unit.

Example with default expiry:

• Platform fee: $99/month
• Included benefit: 1,000 API Credits per month
• Rollover cap: 500
• Rollover expiry: default (one period)

Month 1: customer uses 800 of 1,000 credits. 200 roll over into month 2. In month 2, the customer has 1,200 available (1,000 new plus 200 rolled over). Any of the 200 rolled-over credits still unused at the end of month 2 expire.

Example with custom expiry:

• Rollover expiry: 3 months

Rolled-over credits remain available for three months after the period in which they were earned. This gives customers a longer buffer to use surplus credits.

Multi-period rollover example

This example shows how the cap and expiry interact across several billing periods.

Setup:

• Included benefit: 100 API Credits per month
• Rollover cap: 50

In period 2, 70 credits remain but only 50 roll over because of the cap. The other 20 expire. The same cap applies in period 3.

Consumption priority

When a customer has credits from multiple sources, Paid consumes them in this order:

1. Promotional credits (earliest expiry first)
2. Credits with the earliest period end date
3. Credits with the earliest rollover expiry date
4. Credits created first

This order ensures that credits closest to expiring are used before newer allocations.