Prepaid Components

Prepaid components essentially allow merchants to charge for usage before it is used, as well as handle units recorded past a set limit. There are two main aspects to using this component:

  • Prepaid allocations
  • Prepaid usage

Prepaid allocations are the purchase of a block of units for a customer to use; using up that block of units is referred to as prepaid usage. Generally, a subscriber will purchase an allocation first, then record usage over time. If the usage recorded exceeds the amount allocated, or an allocation was not purchased to begin with, those units of usage will be billed as overage.

One unique aspect about prepaid components is that proration will be neither calculated nor applied when purchasing allocations or recording usage. The full amount due will be charged when buying the allocation. To see how invoices will reflect prepaid usage, please visit our Relationship Invoicing invoice breakdown guide.

Note:  This feature is only available in the Relationship Invoicing Architecture.

This article is related to managing the Components in your Advanced Billing account. Components allow you to introduce additional “line items” to your products that are often expressed as “add-ons”, upsold features, or pay-per-use items. You can learn more about Coupons by checking out this help article: Components Overview.

Prepaid Allocations

Bear in mind that allocations are always additive and cumulative. For example, if a subscriber requests an allocation for 600, and then another for 800, the total allocation will be 1400.

Allocations are used up in a first in, first out fashion. This means that if 50 units are purchased initially, and then another 50 units are bought later, usage will be recorded against the first allocation of 50. This ensures that subscribers will have the maximum amount of time to use their allotted allocation before any expirations (if configured) take place.

While we will typically use the word “purchase” to describe prepaid allocations, it is possible for the allocation to be at no charge, if the component is free, or to be accrued until the next renewal, if the credit card is declined upon allocation.

At this time, allocations may only be reduced or deleted via API request. Any expiration dates per allocation block may also be updated via API.


To prevent overage pricing from taking effect, a customer must first purchase an allocation. Purchasing additional allocations will not wipe out any existing units in overage. These units will be billed for at renewal.

The only way to reduce the units in overage for a given subscription is to record negative usage. When recording negative usage, overage units will be diminished first, followed by recorded usage.

Changing Price Points

Each allocation for a subscriber’s prepaid component inherits settings from the price point that is used at the time of allocation. If the subscriber changes price points, the new price point won’t take effect until a new allocation is purchased. For example, let’s say a subscription purchases 10 units on a default price point that does not allow units to rollover at renewal. Afterwards, the subscriber changes to a new price point that does allow rollover. If the subscriber only records 6 usage before renewing, those other 4 units will not be rolled over to respect the original price point’s configurations.

It may be useful to think in these terms: usage is not recorded against the current price point. It is recorded against the allocation that was made, and follows the configuration set by that allocation’s original price point.

Keep in mind that, unlike product price points, the pricing information of components may be edited once subscribers are using this. If the price point itself has its options changed, then allocations will begin following the new settings of that price point. For this reason we recommend using caution when editing component price points that are actively in use.

For more information on purchasing allocations, recording usage, and changing price points within the Advanced Billing application, please see the article on setting component allocations.

Prepaid Component Settings

Component Details

This section will not be any different than the normal component form. Please review that page for more details.

Component Pricing

Like other components, the pricing scheme for a given price point can be per unit, volume based, tiered, or stairstep.

Configure the pricing for prepaid allocations.

Recurring Allocations

With this setting enabled, the same amount of allocated units for a given subscriber will automatically be purchased again at each renewal. By default, any prepaid allocation that is purchased will not be renewed for the next billing period.

Enable allocated units to recur at renewal. Here, it is disabled.

Note that this feature will not automatically purchase additional allocations mid-period, even if there are few units left remaining.

Rollover of Units

If any units are leftover from the subscription’s current allocations, this option allows those units to be rolled over to the next renewal.

Choose whether leftover units should be available during the subscription's next billing period.

For example, if a subscriber has only used 60/100 total units, those remaining 40 units will be available during the next billing period without incurring overages. The component will display as having 40/40 units remaining within the admin UI.

Expiring Allocated Usage

This feature is a type of rollover, so it can only be used when the rollover option is true. When a prepaid usage component price point is created with an expiration interval and unit, all allocations will have an expiration date based off the component’s expiration params.

When an allocation has an expiration date, its quantity will always be available beyond renewal dates and only the expiration date will be respected. Once the allocation has expired, any additional usage recorded will be charged at overage pricing.

Each individual allocation block made to a subscription can have its own expiration date. This means that if a prepaid usage component is set to expire in 6 months, an allocation made in month 1 and another made in month 4 will have different expiration dates. The expiration comes into effect at exactly the specified days or months after the allocation is created. For example, if an allocation is created at 9:58AM on July 6th and is set to expire in one month, the effective expiration date is August 6th 9:58AM.

Enable allocations to expire after a certain amount of time.

After clicking the toggle button to enable the setting, enter any number and select either “month” or “day” to set the expiration interval.

Overage Usage Pricing Scheme

Another unique facet of prepaid components is the ability to define overage pricing. Let’s say a subscriber has purchased an allocation of 100 units, and has recorded usage for all of them. If 5 more usages are recorded, each of those 5 can be billed at a different cost than the original 100 units had cost.

After the initial block of allocated units is used up, specify the new pricing scheme.

In the example above, once a subscriber has fully depleted their allocated units, they would be billed a flat $0.50 for each additional usage recorded.

Was this article helpful?
0 out of 0 found this helpful