Pricing Management

Prerequisites

Before configuring pricing management, ensure you have completed the following setup steps:

List Page Overview

Good to know

Frontend code: app/[locale]/(protected)/dashboard/(admin)/prices

Backend code: actions/prices

Once you've completed the prerequisites, the admin pricing management page will be populated with initial data. You can:

View the pricing list at /dashboard/prices
Preview how pricing plans appear on the landing page

The landing page displays pricing plans based on the current environment:

Creating, Duplicating, and Editing Pricing Plans

All three operations (create, copy, edit) use the same form component with these key differences:

Create: Opens a blank form for creating a new pricing plan
Duplicate: Creates an identical copy of an existing pricing plan with a new name, ready for modification
Edit: Opens the form with existing data for modifications

Form Component Overview

Core Information

In the Core Information section, you need to select the environment and fill in the pricing plan title and description.

The selected environment must correspond to the environment of the price_id filled in Stripe Integration, and must also match the environment of the environment variables STRIPE_SECRET_KEY and STRIPE_PUBLISHABLE_KEY. This step may seem slightly cumbersome, but it ensures that you won't accidentally set test environment plans to production environment due to incorrect operations, which would cause payment failures.

The Settings on the right can configure the display order and activation status of the current pricing plan. The preview area below uses a WYSIWYG design, with styles identical to what end users will see, allowing you to check if the card displays correctly in different languages before publishing the pricing plan.

Stripe Integration

Simply copy the price_id from Stripe product information and paste it into Stripe Integration, then click Verify & Fetch to automatically populate the pricing information set in Stripe.

Display & Content

This section is used to configure the display information on the card, including:

Displayed price
List of benefits included in the pricing plan
- included indicates whether this item is included; when checked, the preview card will show ✅, otherwise ❌
- bold indicates whether this item should be displayed in bold
Choose whether to highlight the card; generally only one highlighted card is set, which attracts user attention
- If highlighting is selected, you also need to fill in the highlight text
Button text
Button link, supporting two jump behaviors:
- When the button is used to process the Stripe payment flow, no link needs to be filled
- When the button is used for external link jumping, you need to fill in the jump link, supporting https links and email links(mailto:)

Good to know

You can experience the different jump behaviors supported by button links on the Nexty landing page

Multi-language Translations

This section is used to configure multi-language versions of pricing plans, with two ways to complete multi-language configuration:

Click Generate Template to generate a JSON structure based on form information, which you can translate elsewhere and then copy back
If translation-related environment variables are configured in .env or .env.local, the Translate by AI button will be available; clicking it will automatically generate multi-language pricing JSON data based on the form

Once multi-language JSON is generated, the pricing plan card content will be displayed according to that JSON first. If you edit the pricing plan card and modify the content in Display & Content, you should simultaneously update the multi-language JSON.

Benefits

This section is used to customize plan benefits. It has 3 usage methods and scenarios:

If Benefits is left empty or is an empty object, the payment process can still run correctly
- For one-time payments, order information will be generated in the orders table;
- For recurring subscriptions, order information will be generated in the orders table and subscription information in the subscriptions table.
If you want to provide credits for one-time payments and recurring subscriptions, you can directly use the usage table and its built-in one_time_credits_balance and subscription_credits_balance fields
- When creating a one-time payment plan, define one-time payment credits in Benefits JSON through the one_time_credits field, for example:
```
{
  "one_time_credits": 500
}
```
- When creating a recurring subscription plan, define monthly subscription credits in Benefits JSON through the monthly_credits field, for example:
```
  {
    "monthly_credits": 100
  }
```
Using the built-in logic, you don't need to modify code; everything is already prepared for you. After users pay, in addition to generating data in the orders and subscriptions tables, credit balance data will also be generated in the usage table, and credit change records in credit_logs.

Good to know

Starting from v1.1.4, you can test the built-in credit deduction process on the /dashboard/credit-usage-example page. This page can only be opened in the development environment, so there's no need to worry about abuse in production.
If you need to implement more complex benefits, you need to customize benefits in Benefits JSON and re-implement upgradeOneTimeCredits and upgradeSubscriptionCredits in lib/stripe/webhook-handlers.ts. Correspondingly, you also need to extend the fields of the usage table, with two extension methods:
- Modify the table structure, add benefit fields, and assign values to new fields in the re-implemented upgradeOneTimeCredits and upgradeSubscriptionCredits
- In the re-implemented upgradeOneTimeCredits and upgradeSubscriptionCredits, write benefit information to the balance_jsonb of the usage table
Detailed usage and custom implementation of Benefits JSON will be introduced in detail in Payment Flow.

After creating a new pricing plan, you can see the new data in the list.