Bug: Digital Products & Cash On Delivery
If a customer buys a digital download product and pays with cash on delivery they can download the file from the purchase history page before they've paid.
Hello Mathew!
Not really a bug I guess!
COD is meant for physical goods, where the courier collects the money on delivery. If you enable it for digital downloads, the system can’t “hold” the file, so access is granted before payment. It’s by design, not an error.
Other softwares work exactly the same with COD (that’s the expected behavior).
But, they usually have “add other payment method”, in which you can customize this kind of rules for delivery (eg.: manual payment).
Example: you can create a Manual payment option, and until you do not mark the order as paid the file is not delivered :)
.
Jorge de los Reyes Respectfully, I disagree - this is a bug.
After buying a digital product and before paying for it, the product is not available to download in the downloads tab of the customer account (the expected behaviour), but it is available to download via the purchase history tab.
So the feature is partially implemented at the moment.
I get your perspective.
But legally, that’s the point: cash on delivery was conceived exclusively for physical goods, where the courier conditions the handover on payment.
For digital products there’s no courier, no physical handover - and in most jurisdictions, consumer law treats digital content as delivered once it becomes technically accessible, not when a future cash payment might occur.
What seems like a “bug” is in fact a structural mismatch: COD logic simply doesn’t map to digital workflows.
That FluentCart supports both physical and digital products doesn’t mean every payment method should be used interchangeably.
COD behaves consistently with its legal and operational origin - physical delivery - but cannot enforce the same control once the product is intangible.
Using COD for digital goods is like forcing a square peg into a round hole - you can try, but don’t call it a bug when it doesn’t fit.
__
Also a note: What you’re seeing is that the Downloads tab correctly restricts access until payment, while the Purchase History tab is simply displaying the record of the order. It wasn’t designed to enforce download restrictions, which is why the behaviour looks inconsistent in the case of digital products with COD enabled.
That being said, of course you can raise it as a feature request or even log it as a bug. But it doesn’t change the fact that you’re trying to apply a payment method designed for physical goods to a digital product - which not only doesn’t fit, but could also complicate the logic and workflows for physical products just to accommodate an improper method for digital ones.
Jorge de los Reyes I'm not considering this from a legal perspective, or from a definition of cash on delivery.
From a practical perspective there is an inconsistency in the functioning of the software. It appears from the behaviour of the downloads tab that it is intended that digital products should not be available for download until they have been paid for. This works as expected. But, the product can be downloaded via the purchase history tab. This is inconsistent and not logical behaviour.
At the moment, the only way to receive payment without using one of the built-in payment methods is to choose cash on delivery and accept payment outside of FluentCart. There are many situations and locales where this will be necessary.
This is a bug that could lead to store owners having their digital products downloaded without them receiving payment.
Matthew Hawthorn Hello Matthew!
I see your point, and I understand it. But that’s exactly why I suggested treating this not as a COD bug, but as a missing feature.
COD has its own internal logic, tied to physical delivery and courier collection - it’s not broken, it’s just behaving as intended in that context.
What’s really needed here is a proper way to set up manual/offline payment methods for digital products (not COD).
That would avoid forcing digital sales into COD workflows, and give store owners a safe way to handle payments outside the built-in gateways.
From a legal perspective (whether we like it or not, store owners ultimately must), COD is straightforward: cash is handed over upon delivery. With digital goods, “delivery” is immediate - so access is, by definition, instant.
So the request shouldn’t be “fix COD,” but rather “add manual payments logic for digital.” If you frame it that way, I’ll gladly upvote - it’s sensible, and many other platforms already offer it.
That said, “Cash on Delivery” is not the way. And if you list it as such in your checkout without clarifying it in your terms, you can expect claims - because the button itself sets the expectation of instant access. Doing so would also put many merchants at risk of breaching consumer protection regulations.
Jorge de los Reyes Call it a bug. Call it a missing feature. Whatever. Let's just agree this needs to be fixed.
I hope the FluentCart devs read this and find the solution. I also hope they fix this bug. Right now, this exposes store owners to potential financial risk.
Jorge de los Reyes you can fix it disabling COD for digital products
Tindaro Battaglia if you follow the thread, you’ll see that’s what I was trying to share with Matthew :)
But there’s, indeed, a point, on the missing feature of custom payment methods that allow manual payments for digital products out from COD rules 🫡