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 some UI regressions in the Freemius Checkout for the French and Italian translations, where the credit card form appeared misaligned.
This issue has now been fixed.
Following our release of Checkout Translation, we have made additional updates to the UI.
We now always display the language selector dropdown in the footer, with the default language set to ‘English.’ If you want to automatically select a supported language based on the buyer’s location, you can pass language: 'auto' to the JavaScript SDK.
const handler = new FS.Checkout({
plugin_id: 'x',
public_key: '...',
language: 'auto',
});
Additionally,
Stay tuned for more product updates.
This week’s deployment includes the following bug fixes:
Great news! The Freemius Checkout now fully supports the following languages out of the box.
Loading the checkout page in a buyer’s native language significantly improves conversion rates. That’s why we’ve prioritized translating the Checkout into the most popular languages.
To display the Checkout in a specific language, you can use the language parameter when configuring the Checkout JavaScript SDK. For example:
const handler = new FS.Checkout({
plugin_id: 'x',
public_key: '...',
language: 'de_DE',
});
The example above will load the Checkout in German. Alternatively, you can use the value 'auto', which automatically determines the buyer’s location and loads the Checkout in their supported language. For more information please see our documentation here.
We have released a new beta version of our JS SDK for our Checkout. This version aims to:
We’ve also open-sourced it under the MIT license to accept contributions from our makers. You can find the repository here on GitHub along with the usage guide.
While we aim to replace the Legacy JS SDK soon, we would like to call for testers to help with this new system. Please read below to get started quickly.
Instead of https://checkout.freemius.com/checkout.min.js, please use the new CDN under https://checkout.freemius.com/js/v1/. Here’s a quick code example:
<select id="licenses">
<option value="1" selected="selected">Single Site License</option>
<option value="2">2-Site License</option>
<option value="unlimited">Unlimited Sites License</option>
</select>
<button id="purchase">Buy Button</button>
<script
type="text/javascript"
src="https://checkout.freemius.com/js/v1/"
></script>
<script type="text/javascript">
const handler = new FS.Checkout({
plugin_id: '9885',
plan_id: '16634',
public_key: 'pk_ccca7be7fa43aec791448b43c6266',
image: 'https://your-plugin-site.com/logo-100x100.png',
});
document.querySelector('#purchase').addEventListener('click', (e) => {
handler.open({
name: 'My Awesome Plugin',
licenses: document.querySelector('#licenses').value,
// You can consume the response for after purchase logic.
purchaseCompleted: function (response) {
// The logic here will be executed immediately after the purchase confirmation.
// alert(response.user.email);
},
success: function (response) {
// The logic here will be executed after the customer closes the checkout, after a successful purchase.
// alert(response.user.email);
},
});
e.preventDefault();
});
</script>
The difference with the Legacy JS SDK is:
FS.Checkout.configure, we now create a new handler with new FS.Checkout and use the instance accordingly.You are free to create any number of instances if you’re selling multiple products from the same page. Cart recovery will also work as soon as you’ve instantiated and will only target the product the instance is responsible for.
To make it easy to migrate without changing much of your code, we have also developed a compatibility layer.
In your code, where you do
<script src="https://code.jquery.com/jquery-1.12.4.min.js"></script>
<script src="https://checkout.freemius.com/checkout.min.js"></script>
<script src="https://checkout.freemius.com/js/v1/legacy/"></script>
Now all your existing code should work as-is.
const handler = FS.Checkout.configure({
plugin_id: '1234',
plan_id: '5678',
public_key: 'pk_ccca7be7fa43aec791448b43c6266',
image: 'https://your-plugin-site.com/logo-100x100.png',
});
document.querySelector('#purchase').addEventListener('click', (e) => {
handler.open({
name: 'My Awesome Plugin',
licenses: document.querySelector('#licenses').value,
// You can consume the response for after purchase logic.
purchaseCompleted: function (response) {
// The logic here will be executed immediately after the purchase confirmation.
// alert(response.user.email);
},
success: function (response) {
// The logic here will be executed after the customer closes the checkout, after a successful purchase.
// alert(response.user.email);
},
});
e.preventDefault();
});
In the future, we will replace the Legacy JS SDK with this compatibility layer to reduce the footprint.
Please note that if you’re getting started or willing to refactor your code a little bit, kindly consider using the regular pattern instead of the legacy singleton pattern.
While working on the new JS SDK, we also looked into improving performance. Here are the results:
We hope you’ll help us test the new JS SDK so that we can get it out in the wild as soon as possible. If you have any questions, please don’t hesitate to write to our support.
In this week’s release, we have fixed the following couple of bugs we discovered in our User Dashboard.
Both of them are related to the contact form we show in the app.
This week’s release brings the following bug fixes and enhancements to the Developer Dashboard.
Following up on the Mailchimp integration improvement – When unlinking a connection, the connection will be deleted from our server if it is not used by any other products.
This helps clean up any leftover connection data that is not in use anymore.
When deleting plans we will now show a notice if there are active licenses associated with the plan. If you want to deprecate some plan, we recommend hiding it instead of deleting it. We will come up with more follow-up updates to ease the deprecation of plans with active usage.
Right now, deleting a plan with active licenses can create issues for existing customers. Hence we have disabled this for the time being.
We added a notice in the “Deployment” page of WordPress products to use a proper semantic version to support composer integration.
Following up on our data liberation project, we are glad to announce the immediate availability of subscription exports from the Developer Dashboard.
Previously we worked on improving the User Export and also introduced the Payment Export.
With this week’s release exporting Subscriptions is now possible. Go to the “Subscription” page under your Developer Dashboard and click the “Download” button to start.
We are not done with the data liberation project yet. Please stay tuned for more updates.
To push Freemius for SaaS products, we have released yet another new feature. Now it is easier to communicate with our API using Bearer Authentication.
Go to “Settings” > “API Token” of any product and you will see the token that you can use as bearer auth. We have also included a few examples to get you started.
Please note that the API Token works only for product-scoped endpoints for now. We are also working on a new API documentation website using OpenAPI schema to ease the consumption of different endpoints. Please stay tuned for more updates.
A maker provided us with some bug reports for the Checkout’s licensing UI.
We noticed we did not show the short label in the “License label” (where it says “Single Site”) when there was only one unit available. It was wrongly showing “Single Site License” causing inconsistency in the UI. We have fixed that.
We also noticed a broken UI in case the error message when entering a license key was long. Previously the “Try again?” button would try to appear in the same line, breaking the flow of the UI. We have improved that as well.
We have various small and medium tweaks to our system to make it more useful for SaaS makers. The changes were made across the Developer Dashboard, the backend, and the User Dashboard. Please find the details below.
We have removed or enhanced many things that do not pertain to SaaS products.
We improved the Plans configuration.
The Customization section was also simplified.
The Settings page also got a revamp.
The setup page also updated some inline documentation.
Recently we pushed a change to allow SaaS products to decide whether to expose licenses to the users.
Following up, we’ve updated the User Dashboard to show or hide any license-related information depending on the configuration.
Freemius sends various payment-related emails to the users. For example
We have been sending the emails to the primary address of the user.
The users can also have a different “Billing Address” defined through the User Dashboard.
To make the user experience better, we are now CCing such emails to the billing email too. For example, if the address of the user is [email protected] and the billing email is set as [email protected], Freemius will now send payment-related emails to both addresses.
We are pushing more enhancements in our system to cater to SaaS. Recently we looked deeply at our API and how SaaS makers can consume our API. In the process, we delivered the following enhancements.
product scope in API endpoint pathsWe’ve been using and documenting our API endpoints as plugin scopes. The endpoint path usually looks like this:
plugins/{plugin_id}/users.jsonplugins/{plugin_id}/carts.jsonWhile it makes sense for WP products, for general software, term product is more appropriate.
Therefore all our product-scoped endpoints can now be accessed with products instead of plugins. For examples:
products/{product_id}/users.jsonproducts/{product_id}/carts.jsonFor backward compatibility purposes, the plugins will keep on working. This is just a small change to make the terminology easier for SaaS makers.
We realized we mistakenly published the license activation and deactivation endpoints under
We fixed it by instead publishing under
The old endpoints are now deprecated and will be removed in the near future. We will also update our LiteSDK.
To ease license validation for software makers, we have introduced a new endpoint.
/v1/products/{product_id}/installs/{install_id}/license.json (public)
It requires the following parameters:
uid – The UID of the install which was used during the license activation.license_key – The license key that was used to activate the install.On a GET request, the endpoint will give back an license entity with details like expiration date, whether it is canceled etc.
You can read the previous changelog to under more about the license activation system. A proper documentation will be published soon.
We realized the endpoints responsible for creating licenses were using a request parameter named is_blocking although the license entity itself has the property is_block_features. This property determines whether all “premium” features of a product should be blocked when the license expires.
To make it consistent we have introduced a backward-compatible change in the API endpoints to accept is_block_features. The following endpoints are affected
The endpoints are particularly useful when creating licenses for migrated products or from SaaS.
Being a Merchant of Record (MoR), we at Freemius handle VAT and Sales tax for you. This includes the complexities of handling the collection and submission of taxes and tracking and updating tax rate changes.
Finland has increased the VAT rate from 24% to 25.5% starting September 2024. In response, we have also updated our system. All existing subscriptions will also be updated accordingly.
The buyers can of course enter their VAT number to get an exemption.
You can read our blog to learn how Freemius handles taxes.
This week’s deployment brings enhancements to the Freemius Checkout.
This is yet another push to make our Freemius platform more friendly for SaaS integrations. For SaaS, we understand most solutions would have their own user system. When loading the Checkout you can already populate the fields with the following parameters.
user_firstname – The first name of the user.user_lastname – The last name of the user.user_email – The email address of the user.
However, the user could still change their information if they wanted to from the checkout. This could make it difficult for SaaS products to consume webhook events and find the right user.
To solve this, we have introduced a new parameter readonly_user.
When set to true the fields will not let the user edit the information anymore. It works for both JS integration as well as standalone mode (when the checkout is opened directly).
We discovered that the ‘support’ email address was mistakenly shown as the sender in the thank you dialog after a purchase. Emails should be sent from the ‘system’ email you’ve configured. This bug has now been fixed.
You can configure the email addresses on the ‘Emails’ page of your product or store.