Applying changes to pricing and packaging is an absolute must as your product evolves.

Luckily, Stigg makes the rollout of such changes easy - they immediately take effect in new subscriptions, and you have the choice between grandfathering existing subscriptions or applying the changes to them too.

When applied to existing subscriptions, a migration process ensures that the changes are reflected in customers’ accounts. For companies with tens of millions of subscribers, this can take a long time.

We've completely redesigned the subscription migration pipeline from the ground up. The new pipeline boasts a massive 100X improvement from the previous implementation - up from 200K subscriptions to 20M subscriptions per hour!

We’ve invested a lot of thought and hard work to ensure that our platform sustains vendors with a HUGE customer base. Click here to learn more.

In the common use-case, Stigg only syncs customers with paid subscriptions to billing solutions that are integrated with Stigg.

There are cases where you'd like to explicitly sync customers to the billing solution, and we've recently made this possible by specifying billing information when updating customers. 

Syncing of entities between Stigg and third-party solutions usually takes place asynchronously. 

We've now made it possible to wait until the sync operation is complete. To do so, simply pass the shouldWaitSync parameter when updating customers. If successful, the response will include the ID of the customer in the billing solution.

The new functionality is supported by the Stigg Node.js SDK v2.31.0, Stigg Python SDK v0.577.0, Stigg Ruby SDK v0.577.0, Stigg Go SDK v0.577.0 or later, as well as the Stigg GraphQL API.

We've updated the Stigg Go SDK to automatically retry requests that fail due to network errors.

The improved error handling is available in the Stigg Go SDK v0.570 or later.

We've made significant improvements to how subscription payment errors are reflected in the Stigg platform. In addition to ensuring that customers will only have access to entitlements that they successfully pay for, Stigg now:

1. Provides visibility for payment errors - when payment for a subscription fails, the subscription will appear with a "Payment error" status, as well as with a description of the error that was encountered. You can also filter the customer list according to the "Payment error" status to easily identify customers with payment errors.

2. Provides a payment link (when applicable) that you can copy and send to the relevant customer, or open directly from the Stigg app to complete the payment for the subscription. The payment link is also returned by the Stigg SDKs when provisioning or updating subscriptions fails.

The new changes are supported by the Stigg Node.js SDK v2.24, Stigg Python SDK v0.541, Stigg Ruby SDK v0.541, Stigg JavaScript SDK v2.16, Stigg React SDK v4.2.0, Stigg Vue.js SDK v3.3.0 and Stigg Embed SDK v4.3.0 or later.

More details about how payment errors are handled in the Stigg platform can be found here.

We've made the indication in the product details screen for entitlements with custom display text more subtle.

Entitlements with custom display text will now have a dedicated icon that represents this state. Hovering on the icon will provide visibility for the default text.

The improved indication makes it easier to understand how the entitlement will be communicated to customers.

We've made it easier than ever to model your usage-based pricing in Stigg by allowing you to seamlessly create metered features as part of the price definition experience.

Usage-based pricing models require usage to be reported on metered features. During the price definition of usage-based charges, you'll be asked to select the metered feature that will be leveraged to bill customers.

If you already created the feature, search for it and select it from the list.

If the relevant feature still doesn't exist, simply enter its name and click on the link in the drop-down menu to create it. 

After it's created, it will be automatically pre-selected, and you can continue to set the price amount of each unit.

The created feature will also be accessible under the Features section of the Stigg app.

More details about how to model usage-based pricing can be found here.

The basic building blocks of the Stigg platform are features, which represent configurable functionality in your application that can be monetized.

We've simplified the flow for defining features and made the distinction between boolean, configuration and metered features more clear.

As part of this change, the "fluctuating" and "incremental" meter types have been unified, and Stigg can now automatically reset the measured usage of any metered feature. 

More details about Features in Stigg can be found here.

We've made it easier than ever to analyze feature usage patterns using the Feature Inspector, by adding an ability to search for the feature that will undergo analysis.

The new user experience is especially helpful when the usage of many features is metered by Stigg.

The experience for provisioning and updating subscriptions has been completely revamped, including:

- Grouping the subscription configuration under a dedicated "Subscription content" section

- Separating the plan and billing period selection into different steps

- Added icons that distinguish between free, paid and custom plans

- Prevent mouse scrolls from affecting the entered inputs

- Made it clearer when subscription payment is managed by Stigg

- When a credit card is used for paying for the subscription, it's now possible to see the last 4 digits of the card and its expiration date

We've made the currently selected environment persistent. The new improvement allows you to pick up your work when logging in again from the same browser.