# Subscription plans

**Plans, subscriptions, customers, pricing models, and billing cycles - the building blocks of Billing & subscriptions.**

Billing & subscriptions is built on a small set of objects: a plan defines what customers pay, a subscription attaches a customer to the plan, and Revolut collects each payment on schedule. This page explains how those objects fit together and how pricing models, subscription states, and billing cycles work. By the end, you'll be ready to pick the right pricing model and create your first plan.

## Core concepts

Billing & subscriptions is built around the following core objects:

| Concept | What it is | Example |
|---------|------------|---------|
| Plan | The terms customers are billed under - pricing model, billing interval, currency, and optional phases such as trials | "Pro Monthly": £29/month with a 14-day free trial |
| Subscription | A customer's attachment to a plan, tracking its billing cycle, payment schedule, and state | Alice's subscription to "Pro Monthly", active and billed monthly |
| Customer | The person or business subscribing to a plan, with a saved payment method | A customer with two subscriptions on different plans |

One plan can power many subscriptions for multiple customers. Each subscription tracks its own state independently - cancelling one customer's subscription doesn't affect other customers on the same plan:

```file-tree
"Pro Monthly" (£29/month, 14-day trial)
├── Alice → active, trial ended, paying £29/month
├── Bob → pending, awaiting first payment
└── Charlie → cancelled, no longer billed

"Pro Annual" (£290/year, 14-day trial)
├── Dave → active, paying £290/year
└── Erin → active, trial in progress

"Enterprise Monthly" (£200/month, no trial)
├── Acme Ltd → active, paying £200/month
└── Bluth Ltd → overdue, failed payment being resolved

"Enterprise Annual" (£2,400/year, no trial)
├── Contoso Ltd → active, paying £2,400/year
└── Dharma Ltd → pending, awaiting first payment
```

:::tip[Plan variants]
Pro Monthly and Pro Annual could also be modelled as two variations of a single plan - see [Plans](#plans).
:::

### Plans [!details]

A **plan** defines the terms under which customers are billed. A plan specifies the pricing model, billing interval (for example, monthly or annual), currency, and any optional phases such as free trials or promotional pricing. You create plans once and attach multiple customers to the same plan.

For example, you might create a plan called "Pro Monthly" that charges £29/month with a 14-day free trial. Every customer who subscribes to that plan inherits those terms.

A plan can also offer multiple pricing options - for example, monthly and annual variations of the same product - where each variation runs as its own billing schedule and can consist of sequential phases, such as a trial phase followed by standard billing.

[//]: # "RESOLVED (customer-specific plans), per PO on the PR (2026-09-07): custom pricing is handled by creating a plan on the fly when a customer needs it - plans are not tied to a customer_id, so no customer-specific plan concept exists or is needed. The concept stays removed per the PO's suggestion that it may be confusing; do not restore without a product decision. Evidence kept: the API's SubscriptionPlanCreateRequest accepts name, trial_duration, and variations only, with no customer field (verified against the mall codebase and the OpenAPI plan schemas)."

### Subscriptions [!details]

A **subscription** connects a customer to a plan. When a customer signs up, Revolut creates a subscription that tracks the billing cycle, payment schedule, and current state. Revolut automatically collects payments according to the plan's schedule - you don't need to trigger each payment manually.

A subscription can run indefinitely (until cancelled) or for a pre-defined number of billing cycles, depending on how you configure the plan.

### Customers [!details]

A **customer** is the person or business subscribing to a plan. Customers provide their payment method when they sign up. Revolut saves the payment method securely and uses it for all subsequent automatic charges in that subscription.

A customer can have multiple subscriptions, each on a different plan. For example, a customer might have one subscription for a monthly software licence and another for a usage-based API plan.

## How it works

Every subscription is shaped by what its plan charges (pricing models), what happens to the subscription over time (subscription states), and when it charges (billing cycles).

### Pricing models

Plans can use any of the following pricing models, individually or in combination:

| Pricing model | How it works | Example | Dashboard | API |
|---------------|--------------|---------|-----------|-----|
| Fixed / flat-rate recurring | A fixed amount charged at each billing interval. | £9.99/month for a basic plan. | Yes | Yes |
| Per-seat / per-unit | A per-unit amount multiplied by the number of seats or units the customer subscribes to. | £5/user/month for 10 users = £50/month. | Yes | Yes |
| Usage-based (metered) | Charges based on actual usage you report during the billing period, priced per unit or in volume tiers. | £0.10 per API call; customer made 1,000 calls = £100. | No | API only |
| Free trials | A trial period before the first payment is collected. | 14 days free, then billing begins automatically. | Yes | Yes |
| Introductory & promotional phases | Discounted or custom pricing for a limited number of billing cycles. | 50% off for the first 3 months, then standard price. | Yes | Yes |
| Instalments | A larger charge split into multiple recurring payments over a set period. | £600 total split into 6 monthly payments of £100. | Yes | Yes |
| Multi-currency | Plan prices defined in multiple currencies for different regions. | £19/month in GBP, $24/month in USD. | Yes | Yes |
| Package / bundle | A single price for a predefined set of features or services. | £29/month for the "Pro" package including 5 features. | Interim* | Interim* |

\* *An interim approach is available - see the relevant section below for details.*

:::tip[Combine pricing models]
You can combine multiple pricing models within a single plan - all combined charges are collected at the same time, in the same billing cycle. For example, a plan can charge a fixed base rate of £10/month plus £3 per seat, with a 14-day free trial.
:::

[//]: # "PO QUESTION (removed configuration details): this section previously contained per-model 'How to configure' blocks and field tables. Those fields do not exist in the Merchant API - the real model is plan → variations → phases (ISO 8601 cycle_duration, cycle_count, amount + currency) → subscription items of type flat or usage, with per-unit amount OR tiers, quantity, and package_size (verified against openapi/merchant-api/ schemas and the mall codebase: SubscriptionPlanCreateRequest.java, SubscriptionItemRequest.java). The removed content was either drafted from a product vision that diverges from the shipped API, or never API-verified. Configuration guidance will be written from the real spec into the child pages. If the vision is correct and the API lags behind it, reconcile with the API team before restoring anything."

#### Fixed / flat-rate recurring [!details]

The simplest pricing model. You charge a fixed amount at a regular interval - for example, £29/month or £290/year.

**When to use:**
- Single-tier SaaS plans
- Membership services with one membership level
- Subscription boxes with a fixed monthly price

:::tip[Annual discounts]
Annual plans with a discount compared to the monthly equivalent are a common way to improve retention and cash flow. For example, Pro Annual costs £290/year instead of paying £29/month for 12 months (£348) - a saving of £58.
:::

#### Per-seat / per-unit [!details]

You charge based on the number of units or "seats" a customer uses. The total amount is calculated as the per-unit price multiplied by the customer's quantity.

**When to use:**
- Team-based SaaS where pricing scales with team size
- Per-device or per-licence software
- Services priced per user (for example, £12/user/month)

:::note[Changing seats during a billing cycle]
If you bill seats as usage - reporting the seat count via the API during the billing period - you can add or remove seats throughout the cycle, and the final charge reflects the usage you report. See [Adjust seat count](/docs/guides/merchant/billing-subscriptions/api/per-seat#adjust-seat-count).
:::

[//]: # "RESOLVED (mid-cycle seat changes), per PO on the PR (2026-09-07): for usage-based seat plans (for example, £12/user/month), the merchant reports seat counts as usage - during the cycle or at its end - so seats are added or removed by updating the reported usage; the final charge reflects the last reported count. Documented in the note above. Still true: the subscription update API has no quantity parameter (SubscriptionUpdateRequest carries payment_method_id and external_reference only; SubscriptionChangePlanRequest only switches variation, optionally scheduled at_cycle_end) and there is no proration in mall - so the future manage/change-subscription page must describe seat changes via usage reporting, not a quantity update, and its roadmap card's 'adjust seats' promise should point to usage reporting for usage-based seat plans."

#### Usage-based (metered) [!details]

You bill customers based on their actual usage of a service - for example, API calls, gigabytes stored, or messages sent. Revolut bills the customer for the usage you report at the end of each billing cycle.

**When to use:**
- Cloud infrastructure (storage, compute, bandwidth)
- API platforms with per-call pricing
- Pay-as-you-go services with a recurring base fee

**Tiered per-unit pricing.** A usage item is priced either with a flat per-unit rate or with graduated tiers - different per-unit rates at volume thresholds. For example: £0.10 per call for the first 1,000 calls, £0.08 per call for the next 4,000, and £0.05 per call beyond that. Tiers are defined on the usage item itself, as an alternative to the flat per-unit price - not as a separate pricing model.

:::info[API only]
Usage reporting is available via the API only. The dashboard displays usage-based subscriptions and their charges, but you cannot report usage from the dashboard. See [Build a usage-based subscription](/docs/guides/merchant/billing-subscriptions/api/usage-based) for the usage-reporting workflow.
:::

#### Free trials [!details]

Offer a free period at the start of a subscription before the first charge. A free trial lets customers evaluate your product risk-free before committing.

**When to use:**
- New customer acquisition for SaaS products
- Reducing signup friction for high-value plans
- Letting customers evaluate features before paying

:::note[Payment method required at sign-up]
Revolut requires a valid payment method at sign-up, even for free trials.
:::

:::note[Cancelling during trial]
If a customer cancels during the trial period, no charge is made. The subscription ends immediately and no further billing occurs.
:::

#### Introductory & promotional phases [!details]

Offer a discounted rate for a limited time at the start of a subscription, then transition to the standard price. For example, "50% off for the first 3 months, then £19/month".

**When to use:**
- Launch promotions for new products
- Seasonal campaigns (for example, January sale)
- Competitive switching incentives
- Rewarding early adopters

:::info[Combining promotions with trials]
Promotional pricing can be combined with free trials. For example, offer a 14-day free trial followed by 3 months at a discounted rate, then the standard price.
:::

#### Instalments [!details]

Allow customers to pay for a product in fixed instalments over a set period. For example, "£100/month for 6 months" for a £600 product. The subscription automatically ends after the final instalment.

**When to use:**
- High-ticket products sold on payment plans
- Financing options for physical goods
- Course or certification fees spread over time

:::note[Instalments vs open-ended subscriptions]
Instalment plans are distinct from open-ended subscriptions - they have a defined end date, and the subscription moves to `finished` after the final instalment.
:::

:::note[Early cancellation]
Cancelling an instalment subscription early doesn't trigger an automatic or pro-rata refund of the remaining amount - you need to initiate the refund yourself.
:::

[//]: # "RESOLVED (early cancellation), per PO on the PR (2026-09-07): no pro-rata or automatic refunds when cancelling a subscription before the end of a cycle - the merchant initiates any refund themselves. Restored as the note above; the future manage/cancel-subscription page should carry the same guidance for all subscription types."

#### Multi-currency [!details]

Bill customers in their local currency to reduce friction and improve conversion. Each plan is created with a specific currency, so to offer the same plan in multiple currencies you create one plan per currency (for example, a £19/month plan in GBP and a $24/month plan in USD).

**When to use:**
- International customer bases
- Reducing declined payments from currency mismatch
- Displaying prices in the customer's local currency at checkout

:::tip[Local pricing, not fixed rates]
Create matching plans in each currency with locally appropriate pricing rather than converting at a fixed rate. This lets you account for regional purchasing power and local pricing conventions.
:::

#### Package / bundle [!details]

[//]: # "PO QUESTION (package pricing) - updated with API evidence, the BE dev's PR comment (2026-09-04), and the PO's PR comment (2026-09-07): tiered is RESOLVED - graduated tiers are supported on usage items (Subscription-Item-Tier: upper_quantity_threshold + per-unit amount, mutually exclusive with the flat per-unit price; confirmed in the mall codebase, SubscriptionItemRequest.java:77), so tiered was folded into the Usage-based section above and the standalone model row/section removed. REMAINING QUESTION: 'Package / bundle' has no distinct API mechanism - package_size is unit-grouping for sub-minimum pricing (for example, 1000 tokens for £0.10), not feature bundling, and a feature bundle is just a flat-priced item - decide whether the model stays listed at all, on this page, in the table above, and in introduction.md's pricing table and key feature card. NOTE: the PO's answer ('you can created multiple tiers and do usage base packages with our plans') hints that bundles may be modelled as usage/flat items - but he couldn't see the question itself (it was inside this invisible comment), so ask visibly on the PR before acting."

Combine multiple products or services into a single subscription at a bundled price. For example, "Basic + Add-on module for £25/month" instead of purchasing each separately.

**When to use:**
- Multi-product bundles
- Feature packages at a single price point

:::info[Support status: Bundle pricing]
**Support status:** Bundle pricing as a single plan with multiple components is under consideration. As an interim approach, create a single plan that represents the bundle price, or use the API to create multiple subscriptions for the same customer and manage them as a group.
:::

### Subscription states

[//]: # "STATE MODEL (resolved 2026-09-03, future features tracked): the table below reflects the confirmed model - five states: pending, active, overdue, cancelled, finished. Confirmed by BE, the decision on PR #129, and the PO's confirmation on the PR (2026-09-07): (1) no 'paused' state for now - the feature is not yet available, despite being in the Subscription-State.yaml enum (spec/code mismatch to raise with the API team), so the row was removed; (2) no 'expired' state - a never-activated pending subscription ends as 'cancelled' with internal state reason 'EXPIRED' (expiration is the pending→cancelled transition in subscription-lifecycle.md); (3) state reasons (NOT_PAYED, CUSTOMER_REQUEST, MERCHANT_REQUEST, EXPIRED, SYSTEM_REQUEST, CUSTOMER_DELETED) are internal-only today - not exposed in the public API, read only by the Revolut Business FE. FUTURE WORK, together with subscription-lifecycle.md's TODO comment: add 'paused' back with its semantics when the feature ships; document state reasons if/when they go public; then remove this comment."

Every subscription is always in exactly one state - no transitory states exist for subscription. Here is a quick overview about each state:

| State | Description |
|-------|-------------|
| `pending` | Subscription created, not yet activated - awaiting the first payment or, for trial plans, the customer's payment method |
| `active` | Billing running on schedule |
| `overdue` | Subscription has a failed payment attempt |
| `cancelled` | Subscription ended - no further billing |
| `finished` | All billing cycles of a fixed-cycle subscription completed - no further billing |

Final states (`cancelled`, `finished`) are terminal - a subscription cannot be reactivated. To resume billing, create a new subscription for the customer.

:::info[Subscription lifecycle]
For the full lifecycle — every state transition, its trigger, and how to handle it in your integration — see [Subscription lifecycle](/docs/guides/merchant/billing-subscriptions/subscription-lifecycle).
:::

### Billing cycles

A **billing cycle** is the period between two scheduled payments. The cycle length is determined by the plan's billing interval - for example, a monthly plan bills once per calendar month, and an annual plan once per year.

**First payment.** When a customer signs up for a plan without a free trial, they must make the first payment to activate the subscription. Until the first payment is received, the subscription stays in `pending` state. Once the customer pays, Revolut saves their payment method and all subsequent charges are collected automatically.

If the plan includes a free trial, the subscription is created in `pending` and moves to `active` once the customer provides a payment method. The first payment is collected at the end of the trial period.

At the end of each billing cycle, Revolut automatically charges the customer's saved payment method. If the payment succeeds, the subscription stays `active` and continues to the next cycle. If the payment fails, the subscription moves to `overdue`.

**Fixed-cycle subscriptions.** Some plans have a pre-defined number of billing cycles - an instalment plan, for example, might run for 6 monthly payments. Once all cycles are completed successfully, the subscription moves to `finished` state - no further payments are collected.

## What's next

- [:Workflow: Subscription lifecycle](/docs/guides/merchant/billing-subscriptions/subscription-lifecycle 'Detailed explanation of states, transitions, and handling')
- [:AddProduct: Create a plan in the dashboard](https://business.revolut.com/merchant/subscriptions 'Start building your first plan')
- [:CodeRepository: Explore the API path](/docs/guides/merchant/billing-subscriptions/api/introduction 'Learn more about how to intagrate subscriptions via the Merchant API')