Changelog

Freemius supports proration out of the box. Proration means offering a discount on license upgrades based on the remaining days of usage. For example, a customer might have purchased an annual license of planA three months ago and now wants to upgrade to planB. In such cases, our Checkout automatically applies a proration discount for the remaining nine months. This acts as a strong incentive for customers to upgrade to higher plans.

For lifetime licenses, proration discounts were previously limited to a 30-day window. The reasoning behind this default is clearly explained in our documentation. However, we noticed that this recommended limit does not work equally well for all makers—especially for products where lifetime licenses are the primary offering and upgrades may happen much later.

To better support these use cases, we have introduced a new option that allows you to configure the proration period for lifetime licenses.

You can now navigate to Plans → Prorated Discount and update the configuration from there.

The proration period can be set to any custom number of days, including Unlimited. For more details, please refer to the updated documentation.

Our webhook mechanism includes an error detection system that notifies you when a webhook fails multiple times consecutively. We also have a safeguard in place where, if a webhook fails more than 100 times, it is automatically disabled to avoid unnecessary load and potential downtime on your server.

However, it came to our attention that we were not properly clearing the failure counter once the webhook endpoint recovered. This meant that even after the server started responding correctly, the accumulated failures could still lead to an automatic disablement.

This week, we’re rolling out an update to make this logic smarter. The failure counter will now correctly reset itself once the webhook endpoint stops returning errors for a sustained period of time.

This week, we’ve opened up the option to customize the Checkout’s confirmation dialog for “App” products.

Until now, this capability was available only for SaaS products. However, we noticed that many app makers have similar post-purchase requirements—for example, sharing a download link or next steps immediately after a successful purchase.

You can now visit Plans → Customization and start configuring the after-purchase dialog for your app products. For more details on the available options, refer to our documentation.

This week we’re releasing a few improvements to the Setup Checklist and related documentation to make the onboarding experience clearer for WordPress makers.

Onboarding Step for Releasing Plans

We have a concept called Releasing Plans, where the paid plans of a product remain hidden to prevent unintended purchases. For new products, this is automatically enabled as soon as a paid plan is added.

However, for existing products or products that were previously using Freemius only for SDK analytics, this flag remains turned off until the maker explicitly enables it. This distinction was not clearly explained before, which led to some confusion.

With this release, we’ve added Releasing Plans as a visible step in the Setup Checklist, making it part of the onboarding flow.

For most new products that intend to sell from the beginning, this step will be automatically completed as soon as the first paid plan is added. For others, the checklist now clearly highlights the required action: visiting the Plans page and enabling the Release Plans toggle.

In addition, we’ve updated our documentation to better explain this behavior.

Improved Explanation for Releasing Add-ons

There is a similar concept for releasing (or listing) add-ons in the WordPress SDK’s Add-on Marketplace. When an add-on is created, it is listed by default. Makers can choose to unlist it while the add-on is still in development. This can be controlled by going to the Settings page of the product and updating the “Show add-on in the WP Admin Add-Ons marketplace” checkbox.

We noticed cases where add-ons were unlisted during development and then unintentionally left unlisted later, which caused confusion when testing the add-on activation flow.

To make the intent of this setting clearer, we’ve improved the inline hint text to better explain its purpose.

Additionally, we’ve refined our documentation to provide clearer guidance around releasing and listing add-ons.

The Freemius Developer Dashboard allows you to manage your subscriptions with ease. From the Subscriptions page, you can view all active subscriptions, drill into detailed information, and cancel subscriptions when needed.

When cancelling a subscription, the system also prompts whether you want to cancel the associated license. While cancelling the license by default makes sense for WordPress products, given how our WP SDK treats cancelled licenses—it is not the ideal recommendation for SaaS & App products. In those cases, usability and entitlement depend on whether the license is active and not expired, rather than whether the subscription itself is cancelled.

To reduce confusion and better align with how SaaS & App licensing works, we have improved the license cancellation dialog, as shown below.

The dialog now clearly explains the implications of each option and recommends Retain the License as the primary action.

Please note that even if the license is retained, it will eventually expire, at which point access to the product will be revoked for the user. You can read more about license lifecycle handling and entitlements in our SaaS and App integration guides.

This week we’re rolling out several improvements and bug fixes to our Checkout. Here’s what’s new.

New Feature to Control Marketing Opt-In UI

Freemius Checkout has several built-in features to make it fully compliant with GDPR and other privacy-related regulations, while providing the best possible UX for your buyers. One such feature is the Marketing Opt-In UI.

Until now, the UI would show up where relevant per regulation, and buyers had to explicitly choose whether they wanted to opt in to marketing or not. There wasn’t a way to configure this behavior.

We’ve now introduced a new configuration parameter, gdpr, to better customize this flow based on your own preferences.

• default – This is the current default behavior, where the UI will show up if the buyer has not previously opted in the past.
• opt_out – Use this to have the UI pre-select the “No” option by default, saving a click before purchase at the expense of fewer marketing opt-ins.
• hidden – Completely hides the UI from the Checkout. Use this if you don’t want Freemius to manage the opt-in consent and already have your own system in place.

You can read more about it in our documentation.

All Dates in the Checkout Are Now Localized

Freemius Checkout supports various languages out of the box.

We’ve now extended this capability to also translate and localize the dynamic dates shown in the UI based on the selected language.

Coupon UI Now Has Better Resilience Against Errors

We noticed a UI glitch in the Checkout when a coupon could not be validated due to network or similar transient issues.

We identified the root cause and made the UI and UX more resilient to such errors, helping keep the checkout experience as smooth as possible.

Better License Upgrade Flow

Last week, we saw a regression in the license upgrade flow where the flow was broken in some cases. We identified and hot-fixed it immediately.

As a follow-up, we also addressed additional edge cases, such as licenses that were manually upgraded to a higher quota by the maker. The Checkout will now always select the correct minimum pricing or quota when upgrading a license, whether the upgrade is within the same plan or across different plans.

Fix in the Review Avatar

Freemius Checkout can show reviews as a social proofing interface to help boost your sales.

We noticed a small UI bug where the fallback avatar was not being generated correctly in some cases. We’ve deployed a fix to ensure avatars are now rendered consistently across all scenarios.

We noticed a bug in our system where we did not send invoices for a subscription’s first payment when the payment value was zero. A zero-value payment can occur for several reasons, such as:

1. License upgrades with a full proration discount.
2. Purchases with a full first-payment discount due to coupons.

However, we understand that it is important to continue sending emails and invoices, as they serve as a record of the action taken by the buyer and help explain future renewal payments for the subscription.

Starting with today’s deployment, our system will now send invoices for zero-value subscription payments via the payment email buyers receive.

Clicking the invoice link will show the exact reason why the invoice amount is zero. For example, an invoice may reflect a zero value due to a 100% proration discount.

The Developer Dashboard will also begin showing these zero-value payments. In an upcoming update, the Dashboard will additionally support generating and downloading invoices for such payments, consistent with the experience for regular payments.

We are rolling out a few quality-of-life improvements to our backend system.

Fixed Long Strings in Invoices

We noticed a few edge cases where long strings in invoices could break the layout and affect readability.

We’ve identified all such areas and ensured that long text now wraps correctly onto the next line, keeping invoices clean and easy to read.

User Emails Now Included in Licenses Export

When exporting licenses from the Developer Dashboard, the CSV will now include an additional user_email column alongside the existing user_id. This makes it easier to analyze exports and better understand and manage your user base when working with the data.

We noticed a UI glitch on the Store Settings page affecting team members who are not the store owner. For security reasons, non-owners are not allowed to update any store configuration. However, the UI did not fully reflect this restriction and displayed the settings in an editable state.

While any interaction with the form was correctly blocked at the API level, the editable UI created confusion for makers and their teams.

To address this, we’ve released an update where non-store owners now see the Store Settings in a read-only state, along with a clear notice explaining why the configuration cannot be updated.

This week we’re rolling out minor UI polishing to the DKIM configuration section of the Emails page.

While enhancing the customization addresses UI last week, we noticed a few leftover UI glitches and legacy elements on this page. With this update, we’re closing that loop by cleaning up and aligning the rest of the UI for a more consistent and polished experience.

We noticed a regression following last week’s deployment of the “Weekly Report Email”. In some email clients, the banner image URL was not rendering correctly.

We have identified the root cause and deployed a fix. Starting next week, you should see the email rendered with the correct layout across supported clients. We apologize for the inconvenience.

We noticed an intermittent issue where querying Sites by version number was returning a 504 server error from the API. This typically surfaced when makers clicked the Downloaded link from the Deployment page.

After investigating, we identified the root cause and deployed a fix. Alongside this, we substantially optimized the underlying API request, resulting in a much faster experience. The Sites page now loads instantly when filtering by version, instead of occasionally timing out.

This week we’re wrapping our email rebranding with a bang. So far, we completed makers’ emails, followed by transactional and customer-facing emails—bringing their default design up to date while preserving all customization options.

However, we left one email for last because we didn’t just want to redesign it; we wanted to rebuild it from the ground up. That email is the weekly reports email.

As you can see above, this email is sent to our makers every week, highlighting the exact number of sales, first-time payments, and renewals across different plans. This gives you quick, reliable insights into which plans, pricing structures, and billing cycles are performing best.

While rebranding this email, we took the opportunity to unify and enrich the entire experience while introducing a clearer, more consistent UI.

• Data now includes a more detailed breakdown per plan and billing cycle, offering deeper visibility into weekly performance.
• The CTA now takes you directly to that specific week’s report in the Developer Dashboard.
• The email is now fully responsive, adapting seamlessly to both mobile and desktop layouts.

For our makers, we hope you’ll enjoy this grand finale to the email rebranding journey.

PS: If you’re not receiving the weekly report emails, please ensure the notification isn’t disabled in your email settings.

This week we’re rolling out a major enhancement to the product types supported in Freemius. As we expanded the platform for SaaS and App makers, we introduced two broad categories — “SaaS” and “App.”

However, after receiving feedback from makers, it became clear that these generic labels weren’t always enough to guide them toward the right setup. For example, creators of Chrome extensions weren’t sure which type to pick, and we noticed cases where products like Figma plugins were accidentally categorized as WordPress plugins — which then required manual corrections.

To address this and make the product creation flow more intuitive, we’ve expanded the new product form and backend to support a richer set of categories and product types.

Starting with a Wider Category

Makers now begin by selecting a broad category — SaaS, Apps, WordPress Products, or Bundles.

Starting with a clear category helps avoid mix-ups, such as confusing WordPress plugins with Figma plugins.

More Fine-Tuned Product Options

Next, when relevant, we ask what specific kind of product you’re building. For example, under “Apps & Software,” you can now choose:

• App (Mobile or Desktop)
• Plugin
• Extension
• Add-on

This lets makers quickly identify the exact product type. For instance, someone integrating a Chrome extension would naturally select “Extension.”

After creation, you’ll be taken directly to the Setup Checklist for onboarding.

With these improvements, we aim to make it clearer how flexible the platform truly is. No matter what kind of software you’re selling, Freemius has you covered.

Following last week’s deployment improving how DKIM-verified emails are handled, this week we’re rolling out additional refinements and addressing a few regressions identified during wider usage.

Better UX While Configuring Emails

As documented, if DKIM is not properly configured for the domain of your sending address, we automatically fall back to our generic [email protected] to prevent deliverability issues.

Otherwise the system first attempts to use your configured sender address, then your developer account email — both checked against DKIM — before ultimately falling back to [email protected].

This ensures that only authenticated domains are used for sending, and helps maintain high inbox placement.

However, the customization UI previously did not communicate this logic clearly, and placeholder text sometimes suggested a different behavior, causing confusion for some makers. This week we’ve improved the UX to clearly show which email will be used and why, including a link to relevant documentation for easy reference.

Other Fixes

• We identified two legacy email address types that were no longer functional. These have now been removed from the Dashboard.
• Fixed a regression where, if DKIM was not set, the reply-to address was occasionally populated incorrectly.
• The “Don’t Reply” email will now correctly fall back to the configured “General System Address” before using the developer’s email.