Hi, I am getting a 404 error when trying to access License Settings on my existing digital products. Looks like the free version is possibly not compiled properly and contains 2.0.0 assets?

Have reported it to support, but wanted to warn people just in case they are about to update 🙏

Has anyone expereinced this? This was just the update not settings or anything

WordPress database error: [Table 'xxxx_wp_xxxx.p5cfW_fct_retention_snapshots' doesn't exist]
DESCRIBE p5cfW_fct_retention_snapshots

WordPress database error: [Table 'xxxxx_wp_xxxxx.p5cfW_fct_retention_snapshots' doesn't exist]
ALTER TABLE p5cfW_fct_retention_snapshots ADD COLUMN currency VARCHAR(10) NOT NULL DEFAULT '' AFTER product_id;

WordPress database error: [Table 'xxxx_wp_xxxx.p5cfW_fct_retention_snapshots' doesn't exist]
SHOW INDEX FROM p5cfW_fct_retention_snapshots WHERE Key_name = 'p5cfW_fct_rs_cohort_period_product_currency_idx'

WordPress database error: [Table 'xxxxx_wp_xxxxx.p5cfW_fct_retention_snapshots' doesn't exist]
ALTER TABLE p5cfW_fct_retention_snapshots ADD UNIQUE INDEX p5cfW_fct_rs_cohort_period_product_currency_idx (cohort, period, product_id, currency);

WordPress database error: [Table 'xxxx_wp_xxxxx.p5cfW_fct_retention_snapshots' doesn't exist]
SHOW COLUMNS FROM p5cfW_fct_retention_snapshots LIKE 'currency'

WordPress database error: [Table 'xxxx_wp_xxxxx.p5cfW_fct_retention_snapshots' doesn't exist]
SHOW COLUMNS FROM p5cfW_fct_retention_snapshots LIKE 'currency'

Hi team, please fix this refund-dialog inconsistency, reproduced on staging with FluentCart Core and Pro 2.0.0, EUR, tax-exclusive pricing and 21% VAT. All payments were Stripe sandbox tests, not live charges.

TL;DR: selecting the purchased item limits the refund to its pre-tax price, even though the selected transaction includes VAT.

Steps to reproduce:

1. Buy one item for €49 + €10.29 VAT = €59.29 using Stripe test mode.
2. Open the paid order and its refund dialog.
3. Select the charge and the purchased item.

Actual result: the transaction shows €59.29 paid, but the maximum refundable amount and refund button show only €49. Entering €59.29 is clamped back to €49 (screenshot attached).

Expected result: a full refund of the selected item should include its associated VAT, up to the remaining refundable transaction amount. Partial refunds should handle the corresponding tax consistently too.

Important workaround: removing the item selection changes the maximum to €59.29. We then refunded the entire €59.29 in ONE operation and verified the full refund in Stripe. So this is not a Stripe limitation, and two refunds are not inherently required. We also reproduced the item-selected limit with an offline test order (€10 + €2.10 VAT).

Please make the item-selected refund calculation and validation consistent with the amount actually paid, including VAT. Otherwise, following the default item-selected flow can leave the customer under-refunded. Thank you!

Site: thehiddencause.com · WordPress 7.1.3 · PHP 8.4 · Base currency USD; GBP, EUR and CAD enabled

1. The exchange-rate provider can’t be changed from Manual in the admin UI
   Settings → Multi-currency: the “Exchange rates from” selector (Manual / European Central Bank) sits inside the “Exchange rates” section. That section only displays when rate_provider is set and isn’t manual. With the provider on Manual, the section and its selector are both hidden, so there’s no way to switch to ECB. We had to change the setting in code; after that the section appeared and works.
   Expected: the selector is visible in Manual mode.

2. Customer::recountStats() throws a database error
   QueryException: Unknown column 'total_order_count' in 'field list'. It runs UPDATE wp_fct_customers SET total_order_count = …, total_order_value = …, but neither column exists in wp_fct_customers on 2.0.0 (the columns are purchase_count, purchase_value, ltv, aov). Customer stats can’t be recounted.

3. Reports quietly show only the base currency
   When the date range includes orders in several currencies, reports default to the base currency. The only way to change it is a “Currency” option inside the filter menu, and there’s no sign that orders in other currencies are being left out. In our case the Products report showed 1 sale where there were 2 (one GBP, one USD).
   Suggestion: a visible currency chip or picker whenever more than one currency is in range, plus a note such as “1 GBP order not shown”.

4. Feature request: manual and API orders in a non-base currency
   OrderController::store() runs unset($data['currency']) (commented “Admin orders in another currency are not released yet”), so admin-created and REST-created orders are always in the base currency. We need to record historical and offline orders in the currency they were actually paid in, with an optional exchange rate and original order date. Supporting currency, rate and created_at on create would cover it.

One year ago today, we pushed FluentCart live. Today, more than 9,000 stores run it. Thank you for trusting it. It means a lot.

Most of what we shipped this year started as your tickets and posts here, like the subscription engine that works with any gateway, proper EU VAT, the Woo and EDD migrators, and built-in reviews.

For the birthday, we decided to ship something new every day this week. Dynamic Pricing went out Monday, on-page checkout on Tuesday, and today is 2.0 with Multi Currency.

What it does:

• Your customers see prices, pay, and get their emails in their own currency.
• You set each exchange rate yourself. Nothing changes until you edit it.
• Every order remembers the rate it was sold at, so renewals and refunds stay correct.
• Reports work per currency or in your base currency, and there’s an accounting export for your VAT records.

2.0 details: https://fluentcart.com/blog/fluentcart-2-0-0/
The full year story: https://fluentcart.com/blog/fluentcart-1-year-anniversary/

One small ask. If FluentCart has been good to your store this year, a quick review on WordPress.org would mean a lot.
https://wordpress.org/support/plugin/fluent-cart/reviews/#new-post

Two more releases are scheduled for our birthday week!

Hello there,

I noticed that after a successful purchase in FluentCart, the customers' addresses don't transferred into their respective FluentCRM profiles (name and email are okay, I turned on the integration in FluentCart).

There is neither a way in FluentCRM automations to copy the customer's addresses from the order into their profile fields.

Did I miss a setting for this or I cannot do this?

One year of innovation, growth, and making eCommerce simpler for WordPress users!

A huge congratulations to the entire FluentCart team for reaching this incredible milestone. Building a product, improving it continuously, listening to users, and pushing WordPress eCommerce forward takes real dedication. 👏

And this is only the beginning! 💙

With the exciting 5 Over 5 updates happening this week, it feels like the perfect way to celebrate one year of FluentCart.

Here's to more innovation, more powerful features, more success stories, and many more birthdays ahead! 🥂

Happy 1st Anniversary, FluentCart!

🥳 Everyone, drop your birthday wishes below! What's your favourite thing about FluentCart so far?

Is there anyone here that is using Australia Post for shipping?

I've been begging the creator of Phox Elements to support Fluent Cart and they finally did it! YAY! Now we get all the goodies that were available for WooCommerce in Breakdance and Oxygen, too!

https://phox-elements.com/phox-fluent-elements/

Hi team! FluentCart’s checkout design is clean and modern, but there are two subtle UI/UX details that could make the form completion experience much more polished:

1. Border Overlap on Grouped Fields (Visual Glitch)

In the grouped input containers (like Billing Address and Contact info), the borders between adjacent inputs stack together. This creates an uneven 2px border seam at the intersections, while the exterior border remains 1px. A slight CSS tweak (e.g., using margin-top: -1px or collapsing sibling top/bottom borders) would ensure a crisp, consistent 1px stroke across the entire grid.

2. Floating Labels for Better Form Usability (UX) Right now, field labels rely solely on the HTML placeholder attribute. When a customer types or uses browser autofill, the placeholder disappears entirely. During final review before placing the order, there is no visible reference to tell which field is City, State, ZIP, or Address line without manually deleting the text.

Adopting Floating Labels (similar to Shopify’s checkout or Stripe Elements) or some other solutions—where the placeholder shrinks and docks to the top of the input once focused or populated—would eliminate guesswork and prevent checkout friction.

Attached are screenshots showing the difference between empty fields and filled fields. Hope this helps in the upcoming polish releases! 🚀