Skip to main content
Limited Release
A pricing plan connects the following entities:
  • Metrics that define what you charge for based on usage.
  • Pricing models that define how you calculate charges for metric usage.
  • Features through entitlements that define what capabilities customers can access.
How metrics, pricing models, features, entitlements, and plans work together
  • Your metric measures usage. For example, you create an API calls metric that counts the number of requests.
  • The pricing model determines how to charge for that usage. For example, you charge $0.10 per API call using the standard model.
  • Your features define capabilities. For example, you create an API access feature with a rate_limit privilege that controls the number of requests.
  • Entitlements assign specific values to feature privileges for each plan. For example, you set the rate_limit privilege to 1,000 requests per day in your Basic plan, and 100,000 requests per day in your Premium plan.
  • The pricing plan combines metrics with their pricing models, features with their entitlements, and any fixed recurring fees.

Prerequisites

  • Create metrics that define what you charge for based on usage.
  • Create features that define what customers can access through entitlements.

1. Understand pricing models

Pricing models determine how you charge customers for their metric usage. Each metric in your plan can use a different pricing model based on your business needs. PayPal offers five pricing models:

2. Decide your plan structure

Define the following components for your pricing plan before you create it. Then, you can make a POST call to the Create plan endpoint to send this information to PayPal. Plan identification
  • Name: Choose a human-readable identifier that describes your plan to customers.
  • Code: Create a unique alphanumeric identifier you use in API calls. Ensure this code is unique across all plans in your account.
Billing structure
  • Billing cycle: Set how often you charge recurring fees. Choose from WEEKLY, MONTHLY, QUARTERLY, or YEARLY. You cannot change this after customers subscribe to the plan.
  • Fixed recurring fee: Define the fixed recurring fee you charge each billing period.
  • Currency: Select a three-letter ISO currency code (for example, USD, EUR). See supported currencies. You cannot change this after you create the plan.
  • Payment timing: Decide whether you collect recurring charges in advance or at the end of the billing period.
  • Trial period: Set an optional free trial period in days. You do not charge customers the fixed recurring fee during this period, but usage-based charges may still apply.
Usage-based charges
  • Metric references: Link to your existing metrics by their metric IDs. You need to create metrics before you reference them in plans.
  • Charge models: Choose the pricing model to apply to each metric. Select from standard, graduated, volume, package, or percentage models.
  • Model properties: Configure pricing settings specific to each model. The structure varies based on the charge model you select.
  • Minimum amounts: Set minimum charges per metric. If usage-based charges are less than this amount, you charge the minimum instead.
Minimum commitment Plan-level minimum: Set an optimal minimum amount that customers pay each billing period. Customers pay this amount even if their actual usage costs less. This gives you a guaranteed baseline revenue for your plan. When usage-based charges are less than the minimum commitment, PayPal adds an extra fee to bring the total to the minimum committed value. You can also set a custom invoice display name to choose how this extra fee appears on customer invoices.

3. Create pricing plan

Use a valid access token and make a POST call to the /v1/commerce/billing/plans endpoint. Include the following parameters: For information on all parameters, see API reference. The structure of your request depends on which pricing model you want to implement. The basic plan structure remains the same, but the usage_based_charges[].properties object varies based on your selected charge model.

Standard charge model example

This example shows the fundamental structure of a plan creation request using the standard charge model with an optional minimum commitment:

Charge model variations

Each pricing model requires different properties within the usage_based_charges[].properties object. The following examples show how to configure each model:

Graduated charge model

Use the graduated model when you want to incentivize higher usage by offering lower unit prices as customers use more. Unlike the standard model’s fixed per-unit rate, graduated pricing applies different rates to different usage tiers - you charge customers the tier-specific rate for each range of usage.

Volume charge model

Choose the volume model for bulk pricing where the total usage volume determines the rate you apply to all units. This model differs from graduated pricing by applying a single rate to the entire usage amount rather than different rates per tier.

Package charge model

Implement the package model when you sell usage in predetermined bundles or blocks. Instead of charging per individual unit like the standard model, this approach groups units into packages with a fixed price per package, and can include free units as an allowance.

Percentage charge model

Apply the percentage model when you want charges proportional to transaction values rather than usage volume. This model calculates fees as a percentage of the measured value, making it ideal for commission-based or value-based billing scenarios.
A successful call returns a 201 Created response. The response includes the following parameter: For information on all parameters, see API reference.

4. Create plan entitlements

Entitlements control the features and capabilities customers receive with their pricing plans. You can configure feature access, usage limits, and permissions through entitlements. Each entitlement consists of a feature and its associated privileges. Use a valid access token and make a POST call to the /v1/commerce/billing/plans/{plan_code}/entitlements endpoint with the entitlements configuration. Path parameter: plan_code is the code returned when you created the plan. For information on all parameters, see API reference.
This operation replaces all existing entitlements. To retain existing entitlements while adding new ones, use the PATCH method instead.

5. Manage plans

You can modify plan configurations to reflect changing business requirements, but certain limitations ensure billing consistency for existing customers. To review a plan’s current configuration and available management options, make a GET call to the /v1/commerce/billing/plans/ endpoint and review the plan properties. The plan’s modifiable attributes determine which management actions you can perform, ensuring proper plan handling.
When updating a plan, you can use the cascading_updates parameter in your update request to apply changes to subscriptions that have overridden plan values. This ensures that updates to the original plan are reflected in all associated subscriptions, if necessary.