Welcome to the changelog section of Freemius, here you'll find our weekly technical update notes. You can subscribe to all posts via Newsletter or follow us on Twitter to stay updated.
We noticed a bug where creating a new SaaS from the Developer Dashboard would incorrectly show the business model option, asking whether to create a Free plan.
In this deployment, we removed the choice, since it was not intended.
Following up on last week’s announcement, today we are marking the checkout phase2 as production-ready.
The deployment comes with a few improvements too.
While the new checkout is production-ready, we have not yet made it the default. The old checkout will still show up unless you have specifically opted into the new system with checkout_style: 'phase2' JS parameter. For more information, please read our announcement post here.
We noticed a bug in the old checkout where the form could not handle some errors in rare cases. We have deployed a fix for the same.
It has been a couple of weeks since we pushed updates to the new phase2 checkout and this week, we are starting to push it for production. Like before, we will do it gradually, without breaking any custom CSS you might be using. Please read below to learn more.
We first released the phase2 checkout on May 20, 2024. Since then there have been a few iterations and improvements.
Today with a few more bug fixes we are finally marking the checkout as release-candidate and preparing for the production switch.
phase2 checkout the default in production. However, if you have a custom checkout CSS for the phase1 checkout but not for the phase2 checkout, we will keep on showing the phase1 checkout for you. Only when you clear the Custom CSS from the legacy section, the new Checkout will show up by default.checkout_style=legacy to force load the phase1 checkout.phase1 checkout.Until the rollout
checkout_style=phase2 in the URL parameter or JS snippet. More on it later in.phase2 checkout.Starting today, you will notice that your existing checkout CSS style (if any) has been moved to the “(Legacy) Custom Checkout CSS file” under the plans page of the Developer Dashboard. The first input field is now empty.
To migrate your CSS for the new version, simply put the stylesheet URL in the first input field and you are good to go. Please read our documentation to learn about CSS customization.
Remember to clear out the (Legacy) Custom Checkout CSS file after you’ve migrated to have the new checkout show up by default.
We would be glad to get your help to test the new checkout out in the wild.
Kindly go to the plans page and toggle the new configuration to get URLs and JS snippets to load the new checkout.
Alternatively, you can just add checkout_style=phase2 or checkout_style: 'phase2' in the URL or JS snippet to see it live. Here are some live demos:
If you find any issues please get in touch with our support.
We will make another announcement in July when we believe the checkout is ready to go into production. Until then, please stay tuned.
We are bringing a few small enhancements and bug fixes to the phase2 checkout (beta).
We are also getting ready to rollout the new checkout in production. Please read our announcement post here.
We are rolling out various SaaS-related improvements and tweaks to our Developer Dashboard and marketing automation system. Please find the details below.
Our Developer Dashboard is heavily tuned for WordPress.org products (plugins, themes, add-ons, etc). It has many pages, such as Deployment, Integration, etc., that are only relevant to a WP product. It also shows several notices and pop-ups for the SDK integration.
All these features have no meaning for a SaaS product and can create confusion. So we have improved the system by scoping those features only for a WordPress product and keeping the SaaS interface clean.
We introduced the option to create a SaaS product from the Developer Dashboard a while back. But we didn’t allow changing an existing product to SaaS yet. A few of our partners have already been using our platform to facilitate their SaaS products. We have been asking our partners to use the “Plugin” type for SaaS products while we manually adjusted the platform to their specific needs. This gave us enough time to learn the specific necessities for SaaS and improve our system accordingly.
Now that we have rolled out many platform improvements, we are opening up the settings to change your product type to SaaS. Simply navigate to the Settings page of your product from the Developer Dashboard and you can change the type from there.
We have made some more improvements to our marketing automation system to use the right terminology and phrases when dealing with a SaaS product.
From the User Dashboard, we offer a way for the buyers to upgrade their subscriptions. One would simply need to navigate to a subscription from the “Renewals & Billing” page.
Previously the list was showing different options ordered by the quota of the licenses. This resulted in items with heavy pricing showing up on the top of the list, which could discourage the buyer from exploring other cheaper options. This issue was reported to us by a partner.
To fix this, we are now ordering the items showing the cheapest plan and pricing first and then gradually moving towards more expensive options.
With this week’s deployment, we are bringing some small yet meaningful enhancements to the Developer Dashboard. Please read below.
We’ve been showing a small notice under the store page to mention the list of products the data is relevant for.
This notice can become overwhelming for stores with many products, taking up much real estate. Our partners suggested that we introduce an option to remove the notice. In this update, we did just that. Now you can click the close icon to make the notice disappear and it will not appear again under the same browser.
We’ve been offering migration services to partners coming from different platforms like EDD, CodeCanyon, ThemeForest, etc. We not only offer the first-time migration of payments, subscriptions, licenses, etc, but we also do ongoing sync for incoming payments from the subscription of the previous platforms. We do this to give a seamless licensing experience to the buyers.
As an advantage, partners can see the existing subscriptions and associated payments in the Developer Dashboard. But we understand the list can become confusing when there is a mixture of Freemius-sourced entities and migrated entities.
To solve this, we have introduced a new icon in the columns, which will indicate whether the entity came from Freemius or the old platform. Please note the icons will show up when there are any migrated entities to save real estate.
We have pushed various updates to the beta checkout. Just like before, to try it out, use checkout_style=phase2 in the URL parameter or checkout_style: 'phase2' in the JavaScript integration. If you’ve missed the various updates to the phase2 beta checkout, you can find it here and here.
We have three kinds of discounts we show in the checkout before the subtotal.
The reason we show all these discounts is to encourage the purchase of a higher billing cycle, licenses, or bundles.
But over the year we received feedback from our partners asking us to give the flexibility to determine which discounts are to be shown. There are cases where a huge discount can discourage a buyer. For example, if a seller is providing 100-site pricing, then it can often result in an undiscounted price of $10,000, whereas the amount to pay could be less than $500.
So in this update, we are not only giving the ability to turn off discounts through configuration but also remade our discounting system from the ground up, making it smarter. Please find below the three newly introduced configuration parameters and their different values.
| Property | Description | Accepted values | Default value |
|---|---|---|---|
annual_discount |
Determines whether the annual discount will be shown in the checkout. | true | false |
true |
multisite_discount |
Determines whether the multi-site discount will be shown. When the value is auto, the discount will only be shown if the single license pricing difference does not exceed 10 times more than the current pricing.
For example, say you have single-license pricing at |
true | false | 'auto' |
'auto' |
bundle_discount |
Determines whether the bundle discount will be shown. The bundle discount itself depends on the compound price of its children. By default with maximize, we try to take the compound price from the lowest billing cycle and license. But with the value of true, we take it from the closest billing cycle and licenses.
While introducing this parameter, we also deprecated the old |
true | false | 'maximize' |
'maximize |
Please do give the new discounting system a try. The new system is meant to be backward compatible. The only exception is that the multi-site discount can be turned off depending on the pricing. You can always set a hard value of true to enable it back.
Here are some examples and live demos you can check. Feel free to modify the URL parameters.
We have also introduced three new UI parameters to give more flexibility.
always_show_renewals_amount (true | false, default false)
When set to true, a small line mentioning the total renewal price per billing cycle will shown below the total. By default, it only shows up when there is a renewal discount involved. We introduced this option because it can help provide more context with different discounts already shown in the UI. For example, one can see that there is a 30% annual discount and wonder if the discount is only for the first payment. There could also be a coupon that is applicable for the first payment only. With a clear line mentioning the renewal amount, the confusion goes away.
show_inline_currency_selector (true | false, default true)
We recently introduced an inline currency selector in the total line. Now you can hide it if you want by setting the value to false. We gave this option, because in some cases, the seller may not want to show an UI to change currencies for various reasons.
refund_policy_position (below_form | below_breakdown | dynamic, default dynamic)
Many partners asked us to give the option to specify where to place the refund policy badge. For some partners, there were no reviews, so placing it below the breakdown instead of the form was the natural choice. For some products, the breakdown area can be slim (without discounts or upsells). So by placing the UI below the breakdown optimizes the real-estate.
We realized we cannot decide the best positioning because it depends. So we are giving full control over where you want to place the refund policy UI in the horizontal dual-column layout. Depending on your preference you can place it below the form or the breakdown. We recommend using the default value dynamic. Depending on the width and height of the page the UI will be placed optimally either below the form or below the breakdown.
Please note when there are no reviews, the badge will always be positioned below the breakdown. Also this settings has no effect for mobile or single column view.
We are super stoked to announce that we have kickstarted the LiteSDK project. The LiteSDK is meant to be a lightweight alternative to our classic WordPress SDK. It will have minimal features, for example, license activation, software updates, etc. We aim to make the project as modular as possible, to gradually add features that can optionally be included in a WordPress product.
To ease the communication layer of the LiteSDK, we have introduced two new endpoints in our API.
/v1/plugins/:plugin_id/activate.json (public)
Use this endpoint to activate a license on a new or existing site. It expects the following required parameters:
license_key – The license keyuid – A unique identifier of the siteUID: The generation of the UID must be done by the client. More on it later.
Optionally it also accepts the following parameters:
url – The URL of the sitetitle – The title of the siteversion – The version of the WordPress plugin/theme.install_id – The ID of an existing install/site (must belong to the same user and must have the same UID when it was created).On a POST request, with the above parameters the endpoint can
first_name, last_name and user_email parameters.Upon success, it returns the id, public_key and secret_key of the user and the install entities.
/v1/plugins/:plugin_id/deactivate.json (public)
Use this endpoint to deactivate the previously activated licenses on an installation. It expects the following required parameters:
uid – The same UID used when activating the licenseinstall_id – The ID of the install from where you want to deactivate the licenselicense_key – The key of the license you want to deactivateOn a POST request, the endpoint will deactivate the license from the install entity. It will return the properties of the install entity on success.
We have created a POC (Proof-of-Concept) of a WordPress project demonstrating the new endpoints. This POC is still under heavy development and we are yet to write documentation. But if you want to take a look, you can visit our GitHub project.
The project has the following features at the moment:
uid parameter.Over time, we aim to turn it into a proper LiteSDK that can be used in production. At this stage, please help us identify more use cases by trying out the POC in your projects. We are always listening to understand how we can make our products better. If you need help trying out the POC, please get in touch with our support. You can also “watch” the project under GitHub to subscribe to updates.
We are rolling out several enhancements and bug fixes for our beta checkout (internally code named as phase2). If you’ve missed the changelog/announcement post, you can find it here.
To give it a try, simply add checkout_style=phase2 in the URL parameter or checkout_style: 'phase2' in the JavaScript integration.
Now let’s see what are the new changes.
From the Freemius Developers Dashboard, you can create coupons with several configurations. For example, you can generate a coupon applicable only for a particular billing cycle or a specific number of licenses.
Previously while such coupons were active, changing the billing cycle or the licenses would not invalidate the coupon UI, keeping the old code in place.
We have fixed this UI regression. Now the coupon code line will disappear if the coupon is not applicable anymore. Instead, the user will have the option to re-enter a new coupon code. Changing the billing cycle or licenses back to the original value will show the applicable coupon again.
Previously we calculated the price difference in license and billing cycle upsells based on the “subtotal” price. We realized it could be misleading because there can be coupon discounts, taxes, pro-rated discounts, etc.
The upsell price difference will be calculated based on Today’s total amount now.
With the new ability to feature a review right within the checkout, we’ve been auto-selecting a “featured” review with a 5-star rating. While this behavior will still be the default, you can now pass a new parameter review_id to specifically select the review you want to show.
To know the ID of a review, kindly look at the ID column inside the Developer Dashboard.
We were incorrectly showing a percentage value in the renewals discount line, even if a fixed value was configured.
We have now fixed it to follow the configuration you’ve set from the Developer Dashboard.
We are now trimming large reviews to keep the UI consistent.
The review will be shown in full when it is hovered on.
We’ve always had a page mode for the checkout, to support standalone checkout URLs.
For example you could open the checkout with https://checkout.freemius.com/mode/page/plugin/:plugin_id/[/plan/:plan_id/]... etc.
But it was never really “feature complete”.
In this iteration, we are finally making it complete. The mode/page is an optional and backward-compatible parameter. It is applicable only when the checkout is opened directly (not from the SDK or JS integration). A page mode of the checkout means
layout to vertical.To make it more user-friendly, we are showing the page view even when the checkout is opened with mode/dialog but not embedded in an iFrame. In time, you can even drop the mode/dialog or mode/page from the URL and it will load the correct mode automatically.
We have a new feature for the page mode, called the “cancel URL”, which can take the user back in case they want to cancel the purchase.
Referer header (if present).cancel_url using which you can modify the URL.cancel_icon URL.https.hostname (subdomain + domain) of the cancel URL will be shown in the button.Please note they will not show up for the regular JS-based integration where the checkout opens in a popup/modal.
While introducing the upsell concept, we intentionally removed the billing cycle UI and the ability to switch to lower billing cycles in the checkout. For example, when the checkout is loaded in the “Annual” billing cycle, the user cannot go to the “Monthly” billing cycle.
But following partners feedback, we have introduced a parameter show_monthly_switch which will bring back the toggle as shown above. Set show_monthly_switch=true in the URL parameter or show_monthly_switch: true in the JS-integration.
We noticed that when the checkout is loaded with JS-integration/buy button API, clicking the “No Thanks” button of the exit intent popup would not close the checkout.
We have fixed this.
This was a great feature suggestion from our partners.
If you support multiple currencies, then apart from showing the currency selector in the footer, we are also showing it right alongside the “Today’s total” line. This brings more visibility to it.
title parameter not being respected.titleparamerer.subtitle support. You can modify the title parameter to tweak it to your liking.As part of our data liberation project, we have significantly improved the experience while downloading users from the Developer Dashboard. To download users, go to the “Users” page under your Developer Dashboard and find the Download button on the top right of the screen.
Previously you could only download the first 10,000 users and it also took some time to process the download. We have significantly improved the download time, making it at least 10x faster. The download limit has also been increased to 250,000.
You can click the “All Users” button to download all users in a CSV. If you want to download just the users visible in the UI, you can click the “Table users” button.
The download works with any filtering you have active. Please note, the download limit is capped to 250,000 for now. This should be sufficient for most product owners. We do have plans for the future to remove this limit. Meanwhile, you can always contact our support if you need more data to be downloaded.
Soon we will add download capabilities to other areas in the Developer Dashboard, for example, Sites, Payments, Subscriptions etc.
Not so long ago, we introduced general UX improvements to the analytics charts available in the Freemius Developer Dashboard. We noticed the “Area Chart” rendering was not up to the mark, especially if different categories had closer values. It also had a bug where the minimum value of the y-axis was wrongly calculated and there was no way to reset it.
In this deployment, we fixed the bug and improved the default rendering.
You will also get the option to set “Full Size” Y-Axis by clicking the “Customize” button.
We are glad to announce the immediate availability of a new feature our partners have requested. If you have buyers from the US with sales tax exemption, you can now issue a full tax refund to the buyer from your Developer Dashboard.
Go to the “Payments” page of the Developer Dashboard and click the Refund button next to the payment.
Select the “Tax refund of $..” option and provide a valid Tax exemption certificate number. Please ask your buyer to give this number to you. Then click the “Yes – Refund” button after accepting the disclaimer and you will be all set.
Like VAT refunds, two fresh invoices will be created, one as a full refund for the original transaction and another without the tax, containing the tax certificate number. Similarly, if the payment is associated with a subscription, the subscription will be automatically adjusted not to charge sales tax for future renewals.
Continuing our work from the last deployment, we’ve further improved some of the error UI shown in the checkout for PayPal, especially when the checkout is loaded from the SDK.
For every other PayPal-related error, we are now including a “retry link” in the message, so that the user can quickly retry without manually refreshing the page.
This can happen for a PayPal account with insufficient balance or credit source. Apart from the inline link in the error UI, the primary button will also reload the checkout so the user can retry with a different PayPal account or a card.
In some rare edge cases, it can happen that the billing agreement was already created in PayPal, yet it failed to process the payment. Since we know retrying with the same PayPal billing agreement would not work, we now show a clear message, and the buttons would reload the checkout so that the user can try again with a different payment method.
Please note that these improvements were rolled out to the beta or the phase2 version of the checkout. The behavior of the current checkout has not changed from the last deployment, apart from the improved error messages.