Selling online in regulated industries comes with its own rules, and not only the ones set by the state. Companies operating fully legally, but in categories treated as "sensitive," regularly discover that their biggest obstacle is not a regulator or a law, but the eCommerce platform they chose. In this article, we look at where this mechanism comes from in the SaaS model and how the open source approach differs from it. We also examine where that advantage actually reaches its limit, using the Sylius framework as an example.
A legal business, a blocked account
A store sells something fully legal: hookahs, sporting ammunition, supplements, adult accessories, or tobacco products. It holds the right licenses, pays its taxes, and follows the rules. Yet one day it gets an email: account suspended, funds frozen, product catalog in violation of the platform's terms.
This is not a hypothetical scenario. It is one of the most common ways legal but "inconvenient" industries collide with the reality of selling on SaaS platforms. The problem is not that the store broke the law. It is that the store did not fit the risk profile the platform defined for itself, often with no right of appeal and no warning in advance.
Why does this happen, and can a different technology architecture help avoid it? Let’s start with the following question:
Why do SaaS platforms restrict sales in the first place?
It is worth separating two things that are easy to conflate. The eCommerce platform itself (the store engine in a SaaS model) has its own policy on allowed content and products. In practice, though, the payment processor or the bank handling settlement very often plays the decisive role in what can actually be sold. Even if the platform technically does not ban a given product category, the bank or card network behind the processor can refuse to handle the transaction, which has exactly the same effect for the seller: no way to accept payments.
A SaaS platform is therefore not just software. It is an entire ecosystem of responsibility. The company behind it answers to its banks, card processors, regulators, and the public for everything happening on its infrastructure, across thousands of stores at once. That gives rise to a few recurring mechanisms, regardless of which SaaS provider a business chooses:
- Reputational risk is centralized. One controversial store becomes a PR problem for the entire platform brand, so it is easier to ban a whole category upfront than to evaluate each case individually.
- Financial risk is centralized. SaaS platforms very often require or strongly push their own integrated payment processor. That processor, in turn, has agreements with banks and card networks that refuse to handle entire industries such as tobacco, firearms, gambling, CBD, or supplements with a high chargeback risk.
- Scale forces automation. Instead of manually reviewing thousands of stores, platforms rely on rigid, black-and-white lists of banned or restricted categories, enforced by automated catalog scanners and changed without warning to sellers.
- Unilateral rule changes are the norm. This is the provider's infrastructure, not the seller's. Terms can change overnight, and funds can be frozen for weeks, in some cases even months, before a case is resolved.
The result? Even a fully legal business can be removed from a platform, not for breaking the law but for not fitting the risk profile the platform set for itself. Importantly, this pattern applies to many large SaaS eCommerce platforms and popular payment processors operating at mass, automated scale. It is not a flaw of one specific provider but a structural feature of this business model.
What makes the open-source approach different
The key difference is structural, not cosmetic. Open source software is only the store engine layer, which the seller hosts independently. There is no third-party lending infrastructure and, along with it, taking on responsibility (and the authority to decide what can be sold) for someone else's product catalog.
In other words, open source does not eliminate the risks associated with legal regulation or banking policy. It removes the additional, private layer of restrictions that the software vendor itself adds on top of what the law and the payments market already require.
Sylius as an example of a "Clean" approach
Among open source solutions, there is a clear spectrum of flexibility, from ready-made store plugins, through full enterprise platforms, all the way to raw developer frameworks. Sylius sits at the far, most "clean" end of that spectrum.
- A framework, not a finished product: Sylius is a headless, open-source eCommerce framework built on Symfony that gives development teams full control over every layer of a commerce application: the data model, the business logic, the checkout, and the frontend. The project's documentation explicitly contrasts this with SaaS platforms and hosted solutions: in Sylius, the seller owns the infrastructure and every customization. Nothing is hardcoded, and every piece can be replaced.
- MIT license: Sylius is completely free and released under the MIT license, which places no restrictions on the type of products sold through software built on it.
- No product gatekeeping: Because there is no "platform" in the sense of a hosted service, there is no policy from the framework's creators defining an allowed product catalog. The only real limits are the ones a seller chooses through payment integration, and Sylius offers ready, official plugins for popular gateways such as Stripe, PayPal, Mollie, and Adyen. This is the same mechanism found in other open source solutions: the seller picks a payment provider suited to their industry, instead of being locked into a single, imposed processor.
- Scale of use cases: Sylius has been developed for over a decade by a team based in Poland and works well for B2C, B2B, omnichannel, multistore, and marketplace models, which is exactly where regulated industries most often need non-standard business logic.
- The price of flexibility: This is a framework built for development teams, not for sellers looking for a turnkey solution. It requires real engineering investment: knowledge of Symfony and PHP, building a custom frontend, and independently deploying and maintaining infrastructure. A hosted store builder will be faster for sellers who do not need custom commerce logic. Sylius is among the most flexible open source frameworks available, but that comes at the cost of the largest implementation effort.
Where the open-source advantage ends
This flexibility has its limits, and it is worth stating that clearly so as not to give a false impression of regulatory workarounds.
- Legal regulation applies regardless of the store engine. Whether a store runs on SaaS or on its own self-hosted framework, the obligation to hold the right licenses, verify a buyer's age, and correctly handle taxes and excise duties still sits with the seller. Software does not change that.
- The compliance burden shifts to the seller. Without a ready-made platform that at least partly shares this responsibility, the seller has to independently secure a suitable payment gateway and put in place the documentation and procedures required for their industry.
- It requires real technical resources. Self-hosting and maintaining a store built on a framework like Sylius means having a team with the right technical skills, a cost that SaaS platforms largely help sellers avoid.
- Payment processors keep their own rules regardless of the store engine. A payment gateway connected to a fully self-hosted, open-source store still applies its own rules about which product categories it will support. The advantage of open source lies in the ability to choose a provider suited to the industry, not in bypassing those rules altogether.
Open source removes only the extra layer of restrictions coming from the software vendor's own policy. Legal regulations, payment operators' policies, and, in certain cases, hosting or infrastructure providers' rules still apply.
Watch the podcast episode: SaaS or Framework? The decision that dfefines B2B eCommerce development
Summary
SaaS platforms optimize for convenience and scale in mainstream commerce, at the cost of flexibility in niche or regulated industries. Open source solutions, from simpler ones to raw seller's side, but without centrally defined product catalog restrictions imposed by software frameworks like Sylius, optimize in the opposite direction: more implementation work on the vendor.
The difference is not that open source "allows more" than the law permits. It is that open source does not add its own private layer of bans on top of what the law and the payments market already require. For a company operating in a heavily regulated but fully legal industry, whether that is tobacco, adult accessories, supplements, sporting equipment, or alcohol, this flexibility can be the deciding factor in whether the business can operate stably online at all.
Sylius, as one of the rawer eCommerce frameworks on the market today, represents the extreme version of this approach: the most freedom in shaping the catalog, the business logic, and the choice of payment providers, paired with the greatest engineering responsibility on the implementing team's side.
If your industry regularly runs into SaaS platform restrictions, or you are planning a B2B, marketplace, or omnichannel store with non-standard sales logic, it is worth checking whether a Sylius-based architecture can solve that problem at the root.
<div class="rtb-text-box is-blue-50">The BitBag team, as a co-creator and one of the core contributors to the Sylius project, can help assess whether this approach fits your specific business case. Get in touch to discuss it.</div>
