Adjust a Blocks App to Different Pricing Plans

When you publish your Blocks app in the Wix App Market, you can choose to provide different app behaviors for site-creators with different pricing. For example, people who download a free version of your app may get several services, while those who pay for it, get more. This requires creating and managing a system that identifies the user, determines their pricing plan and impacts the app's behavior.

Before you begin adjusting your app to different pricing plans, define your business model in your App Dashboard.

Configuring the pricing settings in the App Dashboard is only a first step. Now, you need to adjust your app to handle these pricing plans with your own logic and user interface (UI). This includes two main steps:

1. Create a different UI for the different plans
2. Code how your app behaves with the different plans

More optional steps can include:

3. Make some configuration adjustments
4. Customize your panels
5. Change the installation settings

Example application

Here is an example application that uses pricing plans. You can click Build in Blocks, to create your own copy of this application.

This example application gives you:

• The widgets design and code
• The panels and configuration settings

The template does not give you the following (define them on your own):  

• Pricing settings in the App Dashboard
• Installations settings

Step 1 | Creating a user interface (UI) for the different plans

Since your app needs to behave differently to users according to their different pricing plans, the first thing you should understand is what the different users see. You can do this through a multi-state box, which gives you different user interface with no code at all. Alternatively, you can delete and restore elements with the delete() and restore() functions.

Step 2 | Code

Use the following in your widget code to impact your widget's behavior. 

Your app's JWT

When your Blocks app is installed on a site, it generates a JSON Web Token (JWT) for that app instance. The JWT has two fields that are important for this process: 

• appDefId: Your app's ID
• vendorProductId: The ID of the pricing plan in use, as you configured in the App Dashboard. If there is no plan, this ID is null.

getDecodedAppInstance()

This function is part of the wix-application module and is used for parsing your app's JWT.

First, import the wix-application module in order to process this information. 

Then, use getDecodedAppInstance() to save the vendorProductId and use it in your app's logic:

wix-application-backend

You can also import wix-application-backend in your app's backend files. To do this, use the following syntax:

Step 3 | Handle plan cancelation

Your app logic should also handle the case where users cancled the plan after they upgraded. When handling this, think about the site builder and the site visitor who is the end user of their app.

If plan is canceled: site builder experience

If users cancel their plan at any point, you'll want to stop the app or some of its features from working. In this case:

• Display a notification in a central, visible place in the app, and prevent the app (or premium features features) from working. Note the difference between a premium app, which does not work at all unless it's paid for, and a freemium app, where you should block only the premium features. 
• Provide entry points to upgrade your app. This can be done in the widget's action bar, settings panel, or in the app Dashboard.

If plan is canceled: site visitor experience

Your direct user is the site builder who installed your app. However, you should also think about the user of your user, the site visitor. 

If users cancel their plan at any point, lock the app (or its premium features) from working. If it's a premium only app, we recommend to collapse (delete) it, so it's not seen on the site. If you cannot collapse it, present an indication, such as: "This app / feature is currently unavailable, contact the site owner for details". This is also true for Dashboard apps - collapse the app or present a proper message. 

Here is a code example for collapsing the widget after the cancelation: 

Step 4 | Configuration

Now, you might want to make some changes in the Configuration tab in Blocks. 

You can define certain elements of your widget, such as a flexbox that helped you layout the elements, as non-selectable. You can also change display names. Make sure to think about all your pricing plans when making these changes. 

Learn more about configuring widget and element display names and behavior.

Once you define a pricing plan for your app, your widget automatically gets an Upgrade button in its action bar. Learn more about configuring action bars

Step 5 | Customize your panels

You can get the vendorProductId of the app and show or hide panel elements according to the plan, just as you did in the widget code. This is done in the code section of your panel in the Panels tab.

You can also add a button or link in your panel to upgrade your app. Learn more about entry points to upgrade your app.

Step 6 | App and widget installation settings

Your app installation settings allow you to control what widgets are seen in a site's Add Elements panel, and more options. Make sure to think about all your pricing plans when you go over your installation settings.

Learn more about app and widget installation settings.