FluentCart currently creates a refund_notice, but it reuses the original order’s invoice_no. If the Order Receipt is intended to act as the customer’s official invoice, refunds should be able to generate a proper credit note/corrective invoice.

Ideally, this would include:

• A separate configurable numbering series and prefix.
• A new sequential number for every credit note.
• A link to the original invoice.
• Support for full and partial refunds.
• Correct tax/base adjustments.
• Its own PDF template, email attachment and customer-dashboard download.
• Hooks/API support for country-specific invoicing integrations.

The prefix and terminology could remain configurable, but the underlying document should be separate from the original invoice and from a simple refund confirmation.

Is this planned?

Shahjahan Jewel asked for reviews on Wordpress, so I went. Wondered why someone left a 1-star review some 9 months ago, where he complained about FluentCart not connecting to ShipStation. And then things took a different course. A couple of hours later....

ShipStation ↔ FluentCart: free bridge plugin, looking for testers

FluentCart has no ShipStation integration and none on the roadmap, a recurring pain point for anyone shipping physical products. My own store only sells digital products, but I built a bridge for the community using ShipStation's standard "Custom Store" connector. No ShipStation API plan needed.

What it does:

• Paid physical orders import into ShipStation: address, items, SKUs, weights, requested shipping method, package info
• Unpaid offline orders wait under Awaiting Payment; refunds and cancellations drop out
• Mark shipped or print a label in ShipStation → the tracking number goes back to FluentCart and the order switches to Shipped through FluentCart's own status route, so its emails and automations fire
• FluentCart's shipped email gets a tracking box with a "Track parcel" button: built-in links for DHL, UPS, FedEx, USPS, GLS, DPD, Hermes and more, plus 17TRACK for everything else
• Settings page with a request log, export preview and an order inspector for troubleshooting

Tested: end to end on a FluentCart store with a ShipStation trial account: import, status mapping, tracking write-back, shipped email.
Not yet tested: real purchased labels with a connected carrier. On a trial without a carrier, ShipStation left weight and dimensions empty on imported orders, although the plugin sends them.

Looking for testers who ship with ShipStation and a connected carrier (US, UK or EU). Download: [link]. Please report back with the plugin's request log.

Not yet decided upon: Free, GPL, community project, support on a best-effort basis.

Happy days,

Helmar

PS: Tried to upload screenshots, but got error message that upload to S3 failed. More upon request.

Three i18n findings from translating FluentCart into German, all measured
against 1.7.0 and unchanged since 1.6.4. They are code-level rather than
release-specific, which is why they sit in their own post.

Related: the msgctxt added to the state names in 1.6.6 solved exactly this
class of problem for the geo data. Point 8 is the same case, still open.

7. A licence notice assembled from fragments, with a hardcoded date

app/Services/PluginManager/FluentLicensing.php:237 builds the expiry notice
by concatenating two translatable fragments with untranslatable English text:

'<p>Your ' . $plugin_title . ' ' . __('license has been', …)
. ' <b>' . __('expired at', …) . ' ' . gmdate('d M Y', …) . '</b>, Please '

Two things follow from that:

• Your and Please are outside the catalogue, so the sentence stays half
  English in every language. German word order also cannot be reached from
  two fragments pinned in place, so the best a translator can do is a hybrid.
• The date uses gmdate('d M Y', …), so it is both a hardcoded pattern and
  rendered in GMT rather than the store timezone. East of UTC an evening
  expiry shows the previous day.

One __() call with placeholders would fix both, for example:

__('Your %1$s license expired at %2$s.', 'fluent-cart-pro')

with the date formatted the way DateFormatter does it everywhere else.

8. on %s carries two meanings and has no msgctxt

The same msgid is used for two different things:

• app/Helpers/Helper.php lines 1430 and 1455: the schedule anchor, "on
  Friday", "on Aug 19"
• app/Models/Order.php line 643: the tax base, "19 % on 69,00"

German needs a different word for each, am Freitag but auf 69,00, so one
translation is always wrong in one of the two places. _x() with a context
would solve it without touching the English text, the same fix as for Apply
and More.

9. Two spellings of "colour" in the storefront colour module

A small one, noticed while translating the storefront colours.
app/Services/Theme/ThemePalette.php uses British spelling in two strings,
line 1111 and the plural entry at line 1118:

The active theme does not publish a colour palette, …
%1$s provides %2$d palette colour. / … palette colours.

The other 53 strings of the same feature use American spelling, including
ColorPalette.php and api/StoreSettings.php, which render on the same
screen. Nothing breaks, and translations are unaffected, but the English UI
shows both spellings side by side.

Hey guys, thanks for the update - Usually I would give 5 stars for FluentCart, however, there are still a few things missing, so only 2 stars. PLEASE implement them, otherwise I am not following German/EU law and I cannot use FluentCart

1. By law, I need to add a second checkbox for digital downloads, if a customers accepts the "waives the right of withdrawal" - It is NOT possible to add the text to Terms checkbox. It MUST be 2 separate checkboxes by EU law. The support sent me some code, but this is way too confusing unfortunately

2. By law, I need to add several PDFs for Terms, Withdraw and so on. A link is NOT sufficient, the PDFs must be added to the email - Here I could get a workaround through Wordpress, but a native version in Fluentcart would be better

I am very confused, you add a lot of things because of EU law (like ZUGFeRD invoice), but the absolute basics (2 checkboxes!!!) is still not in Fluentcart

Please add this, everyone in the EU has the same problem. Thank you very much

We are considering migrating an existing European store to FluentCart, but first we need to understand the current invoicing model.

As we understand it:

• order_receipt is the PDF customers download after a paid purchase.
• proforma_invoice is the template labelled “Invoice”, apparently used for pending/offline orders.
• receipt_number is the sequential number generated when an order is paid.
• invoice_no is the prefix combined with that receipt_number.

Could you please confirm whether this is correct? Should European stores therefore treat order_receipt as the final tax invoice and invoice_no as its official invoice number, while treating proforma_invoice only as a proforma?

We also need confirmation that test and live purchases can use separate sequences, so testing does not affect the official invoice numbering. Currently, this appears not to be possible, so a clarification on future ideas of improvement will be needed.

Related Receipt vs Invoice discussion:
https://community.wpmanageninja.com/portal/space/fluent-cart/post/receipt-vs-invoice-is-confusing-please

Can we safely begin migrating now, knowing that this model will be clarified or improved soon?

The new releases are fantastic, but the coming months are critical for EU merchants (this last quarter, basically) and we need certainty around these invoicing fundamentals.

Otherwise, I guess, many EU merchants may have to postpone their FluentCart migration for another year 😅 (not because the product lacks great features, but because software and integration decisions for the coming regulatory changes are being made now).

Our inbox is already on fire with compliance-related messages, to be honest.

Connecting a store to accounting and invoicing systems requires considerable work. Without a clear invoicing model or roadmap, it becomes difficult to justify choosing a flexible native solution like FluentCart (that we definitely love) over a SaaS that is already prepared for requirements such as VERI*FACTU and electronic invoicing in the EU. 😅

This is one of the biggest FluentCart releases so far (version 1.7.0), and I'm super excited about it.

We just shipped Product Reviews, and I honestly think it's the most complete reviews module in any WordPress eCommerce plugin. You don't need an extra plugin or a third-party service. Just turn it on and it works.

Until now, if you wanted good-looking reviews on a WordPress store, you had to buy one add-on for photo reviews, another one for layouts, and then fight with styling that didn't match your store. We wanted to make this simple.

What you get:

• Star ratings and reviews linked to real purchases, with a Verified Purchase badge
• Reviews show which variation the customer actually bought
• A "My Reviews" section in the customer dashboard, showing what they've reviewed and what's still waiting
• A "Review Your Order" link, so customers can leave a review in one click
• A moderation screen where you can approve, reject and reply
• Email notifications for new reviews, approvals and replies
• Star ratings on product cards across your shop
• 6 review blocks: Product Reviews, Review List, Review Summary, Review Form, Write a Review Button and Product Rating
• JSON-LD schema, so Google can show your stars in search results

With Pro, you also get:

• Photo reviews
• Helpful votes and a "Most Helpful" sort
• Threaded replies between you and your customers
• Ready-made layouts: Minimal List, Card Grid, Carousel, Testimonials and photo-focused styles, each one click to apply
• Grid, masonry and slider views

Everything uses your store palette, so it looks like part of your store from day one.

We also fixed a few things in checkout, subscriptions and the storefront. Full details here: https://fluentcart.com/blog/fluentcart-1-7-0/

Please share your thoughts in the comments. Our goal is simple: make your life a bit easier, one step at a time.

A humble request: since we're talking about reviews 😊, if you have a minute, please leave one for FluentCart here: https://wordpress.org/support/plugin/fluent-cart/reviews/ It really helps more people find us.

An example: Shipping to USA.

I have a poster that I want to ship in a tube, for which I will charge $5.

I also have a sticker that I will ship in an envelope for which I will charge $2.

Right now, any product shipping to the USA zone, even if they are alone in the cart, will show both shipping options. Every single U.S.A. shipping option shows no matter the product, and yet, I don't want a large box to be a selection option when shipping a small item, or for an envelope to be an option when shipping a bigger product.

Using classes is not an option either. The Classes work great as a shipping supplement. e.g. Heavy and bulky, let's add $10. It does not offer a choice.

Thoughts? Anyone?

While testing FluentCart in Spanish, I noticed terminology that is not only unnatural but potentially misleading in an ecommerce and tax context.

Also, incomplete for many strings.

For example, the checkout tax breakdown translates “Tax” or “Tax rate” as “Tasa.” In Spanish:

• Tax should normally be “Impuesto.”
• Tax rate should be “Tipo impositivo.”
• Tasa has a different legal and fiscal meaning and may also be understood as a fee.

This makes me wonder whether similar issues may exist in other translations..., particularly if they have been translated literally or without review by native speakers familiar with ecommerce terminology.

This is especially important in:

• Checkouts and tax breakdowns
• Receipts and invoices
• Payment and refund statuses
• Customer account areas
• Legal and VAT-related fields

I think FluentCart would benefit from a review of every localization by native speakers, ideally using a shared glossary for tax, invoicing and ecommerce terminology.

These may appear to be small wording issues, but unclear translations in financial documents and checkout flows can confuse both customers and store owners (and may create avoidable compliance concerns).

Hope this feedback helps.

Does this auto-login feature work only for the first purchase made with a specific customer/email (good), or does it work after every purchase made using that customer's email address (potentially dangerous)?

The first case seems perfectly fine: when the customer account is initially created, automatically logging them in provides a smooth onboarding experience.

However, if auto-login happens after every purchase, there could be a security risk. For example, a malicious user could place a fraudulent order using someone else's email address to get access to all their purchases, change pass, etc. If FluentCart then automatically logs that browser into the existing customer's account simply because the checkout email matches, the attacker could potentially gain access to that customer's account.

So ideally, auto-login should only happen when the account is first created, not whenever an existing customer's email is used for a new purchase.

Can someone confirm this?

Thank you!

Hi FluentCart team,

While configuring FluentCart on a real staging store, I found the current receipt/invoice workflow confusing.

From the Orders screen, the action labelled “View Receipt” does not open a receipt or PDF. It opens the public order-confirmation page (/confirmation/?order_hash=...). From there, the customer can download a “Receipt”, but that download uses the Fluent PDF “Order Receipt” template.

At the same time, Fluent PDF provides a separate “Invoice” template described as the formal invoice for business transactions. We customised that Invoice template expecting it to be the document customers would receive or download. However, the normal post-purchase and customer-dashboard flow downloads the Order Receipt template instead, so changes made to the Invoice template do not appear there.

The documentation adds to the ambiguity by describing “Download Receipt” as a PDF version of the official invoice. If the receipt is the official invoice, why are there separate Order Receipt and Invoice templates? If they are different documents, where is the Invoice template actually used and how can store owners or customers access it?

I do not think a receipt is necessarily less complete in every jurisdiction, so the core issue is not simply the amount of data. It is the absence of a clear distinction and a predictable workflow.

Suggested improvements:

1. Rename the current admin action to “View order confirmation”, because that is the page it opens.
2. Add direct “View/Download Invoice” and, if relevant, “View/Download Receipt” actions in the order admin.
3. Let store owners choose which PDF template is the official document customers download after purchase and from My Account.
4. Make the customer-facing label configurable: “Download invoice” or “Download receipt”.
5. Show clearly where each Fluent PDF template is used: email, confirmation page, customer dashboard, admin, renewals, etc.
6. If Order Receipt and Invoice are intended to be the same official document, consider merging them into a single template/source of truth. If they are intentionally different, document the legal and functional distinction and expose both consistently.

For many store owners, the primary document they look for from an order is the invoice. Requiring an extra confirmation-page step, while a separately customised Invoice template is not used by the normal download flow, is confusing and impractical.

Could the team clarify the intended workflow and consider simplifying this?

cc: Shahjahan Jewel Rasel Siddiqe