Potential Fiscal Compliance Risk: Test Orders Share and Consume the Live Invoice Sequence

Hi FluentCart team,

I would like to raise an important concern regarding how Test Mode interacts with receipt and invoice numbering.

As far as I can see, FluentCart correctly stores the order mode (live or test) and uses sandbox payment credentials in Test Mode. However, test and live orders appear to share the same receipt-number counter and the same invoice prefix.

For example:

• The latest real invoice is FC-003.
• The store is temporarily switched to Test Mode.
• A sandbox purchase is completed.
• The test order receives FC-004.
• After returning to Live Mode, the next real purchase receives FC-005.

The expected behaviour would be:

• Latest real invoice: FC-003
• Test purchase: TEST-001
• Next real invoice: FC-004

Test purchases should never increment, reserve, reuse or otherwise affect the live invoice sequence.

This is not only a matter of convenience. It can create a significant accounting and tax-compliance risk:

• A test purchase may generate an official-looking invoice or receipt within the ordinary fiscal series.
• Deleting the test order may leave a gap in that series.
• If the number is later reused, two different documents may have existed with the same identifier.
• The test document may already have been downloaded, emailed, exported, sent through a webhook or received by an accounting integration.
• Deleting the FluentCart order does not necessarily remove those external records.
• This becomes especially concerning as EU member states, EU and other jurisdictions move towards stricter electronic invoicing, auditability and invoice-traceability requirements.

A separate staging database is a possible workaround, but it should not be the only safe way to test a checkout, payment gateway, product, workflow or customer journey. Store owners may need to perform controlled tests after a site is already in production.

I suggest that FluentCart implement:

1. Completely independent counters for live and test orders.
2. A configurable test prefix, such as TEST-.
3. Test numbering starting from its own value, independently of the live minimum and next receipt number.
4. A prominent TEST — NOT A VALID TAX INVOICE watermark on every test receipt and invoice.
5. A guarantee that deleting test orders can never change, reuse or create gaps in the live sequence.
6. Clear visual identification of test orders throughout the admin, customer dashboard, emails and PDFs.
7. The test flag being passed clearly to webhooks and integrations, so external systems cannot mistake a sandbox order for a real transaction.
8. A warning when enabling Test Mode on a site that already contains live orders.
9. Documentation explaining exactly how test orders affect receipt numbering, exports, workflows and integrations.

Ideally, FluentCart should treat test purchases as a completely separate fiscal namespace, not merely as ordinary orders processed through sandbox gateway credentials.

Could you please confirm whether the current shared numbering behaviour is intentional, and whether isolated test numbering is already planned?

cc: Shahjahan Jewel Rasel Siddiqe 

Thank you!