Thanks for adding all the fixes

Sounds good! We all like surprise feature releases :) Thanks for fixing the Paddle email notification compliance issue. Does that mean that we can now disable invoices/receipts sent by FluentCart, as this should be done by Paddle, not by FluentCart?

Wow! That’s great to hear. You and your team always surprise us with such valuable features in FluentCart. Thank you for your continuous efforts. We hope you will also release the next update for the Divi Theme Builder—we are eagerly waiting for it. Thanks again!

Hope you will work on it and bring the Divi feature soon. Great work—keep it up!

Shahjahan Jewel just tested the PDF invoice template, but STILL NO VAT number available in from and in bill to.
This is crucial for invoices.
Invoices usually are for B2B, B2C a receipt is usually sufficient, but for an invoice VAT numbers for both seller and customer are needed.
Also, for compliance, tax should be labled: 21% over amount (or other percentage) Also, splitted when there are more than one tax percentage in an order.

I really love the PDF template builder, but for invoices it is still useless 😭

Shahjahan Jewel thanks for addressing the license expiration issue so quickly!

Follow-up: License zero-date root cause still present in FluentCart 1.3.18

Thanks for the fast response with 1.3.18 — the new fixZeroDateLicenses() method in LicenseSchedulerHandler.php does work as intended and keeps the user-facing symptom from persisting. The hourly cleanup runs, zero-dates get nulled, licenses come back to active. Verified on our production environment.

However, the underlying save pipeline is still writing zero-date instead of NULL. The new cleanup is a mop, not a patch on the leak.

What we verified (FluentCart 1.3.18)

Environment: MySQL 8.0.45 on Ubuntu 22.04 with default (permissive) sql_mode — no STRICT_TRANS_TABLES, no NO_ZERO_DATE. Same environment where the original bug reproduced.

Test 1 — save pipeline:

Starting state:  id=5, expiration_date = '2029-04-01 00:00:00'
Action:          $license->extendValidity('lifetime')
                 // internally: $this->expiration_date = null; $this->save();
Result:          id=5, expiration_date = '0000-00-00 00:00:00'   ← still zero-date, not NULL

The model's intent is clear ($this->expiration_date = null; $this->save();), but the null-to-empty-string coercion in the WPFluent save path still happens, and non-strict MySQL silently lands it as zero-date.

Test 2 — cleanup cron (your new fix):

Starting state:  id=5, expiration_date = '0000-00-00 00:00:00'  (from test 1)
Action:          do_action('fluent_cart/scheduler/hourly_tasks')
Result:          id=5, expiration_date = NULL                   ← janitor works

Why a root-cause fix still matters

With 1.3.18, the customer-visible symptom is resolved within the hourly tick. But a few risks remain:

1. 0–60 minute window between purchase and cleanup — during that time, any code path that reads raw DB (integrations, custom reports, third-party tools, REST API calls that bypass the License accessor) sees the inconsistent zero-date state.
2. Depends on WP cron running — on low-traffic sites or sites with misconfigured cron, the cleanup can delay indefinitely. If it does, expireOldLicenses() can still flip zero-dates to expired because its whereNotNull guard doesn't catch zero-date values.
3. New code paths that write zero-date won't be caught by the cleanup unless they also target the licenses table — the current scan is licenses-only. If other models gain similar patterns, each needs its own janitor.

Suggested root-cause fixes (reference only — full code in the original report)

Fix A (preferred): add a setExpirationDateAttribute mutator on the License model that normalizes null / empty string / zero-date → SQL NULL before save. Pairs symmetrically with the existing getExpirationDateAttribute accessor. Environment-independent, works on both strict and non-strict MySQL.

Fix B (defense in depth): add ->where('expiration_date', '!=', '0000-00-00 00:00:00') to LicenseSchedulerHandler::expireOldLicenses(). Makes the expire query itself robust even if the cleanup doesn't run first.

Either alone resolves the risks above. Both together give defense in depth.