Selling a heavily regulated product online: what actually stops you

Every guide to selling a regulated product online opens by telling you to “check the regulations.” Thank you. The regulations are not the hard part. The hard part is that a dozen systems you do not control have quietly decided your legal business is fraud-adjacent, and each of them can switch you off on a Tuesday without warning you first.

We build and run stores in this space. Three of our clients sell kratom and botanicals, a category that is legal at federal level in the United States, banned outright in eight states, and regulated under consumer-protection statutes in more than thirty others. That combination — legal, but conditionally, and differently in every jurisdiction — is the actual engineering problem. It is also why the usual ecommerce advice is close to useless here.

This is what we have learned building for it.

Get the legal position right, because most write-ups do not

Take kratom as the worked example, because it is the category we know best and because almost everything written about it online is wrong in one direction or the other.

As of July 2026: kratom is not a federally scheduled substance in the United States. It is legal to sell federally. Eight states prohibit it outright — Alabama, Arkansas, Connecticut, Indiana, Louisiana, Tennessee, Vermont and Wisconsin — with Tennessee’s ban the most recent, effective 1 July 2026. More than thirty states regulate it under Kratom Consumer Protection Act frameworks, which typically impose a minimum purchase age of 21, mandatory labelling of alkaloid content, third-party testing for contaminants, and caps on 7-hydroxymitragynine concentration.

Separately, in July 2025 the FDA recommended that concentrated 7-OH products be scheduled — targeting tablets, gummies, drink mixes and shots with elevated concentrations, not whole-leaf kratom. That recommendation was still working through DEA rulemaking as of mid-2026.

Three things follow from this, and they generalise to any regulated category.

The map changes underneath you. A state flipped in July. Another will flip next year. Any compliance logic you hard-code into a theme file becomes wrong without anybody noticing, because nothing errors — the store just quietly ships into a state where that is now a crime.

“Legal” and “sellable” are different questions. Federal legality does not oblige a payment processor, a marketplace, an ad platform or a courier to carry you. Each has its own policy, and those policies are stricter than the law.

Nothing in this article is legal advice, and nothing in yours should be either. We build systems that let a client execute a compliance decision quickly. We do not make the decision. Your regulatory counsel does, and the build should assume their answer will change.

The payment processor is the business risk, not the website

Ask any operator in a regulated category what keeps them up and it will not be conversion rate.

Mainstream processors decline the category outright. Shopify Payments will not underwrite it. Stripe’s standard terms exclude it. What you get instead is a high-risk merchant account, and the terms are materially worse: higher rates, a rolling reserve holding a percentage of revenue for months, tighter chargeback thresholds, and a contract that lets them terminate with very little notice.

The failure mode that actually hurts is not the rate. It is waking up to an email saying your account is under review and settlements are paused. If that is your only processor, you are not trading today, and possibly not this month.

So the architectural requirement is redundancy, and it has to be real rather than theoretical.

• Two live processors, not one live and one intended. A backup you have never processed a transaction through is not a backup. Run a small share of live volume through the second one continuously so you know it works and it has settlement history.
• A switch you can throw without a developer. If failing over means editing a config file and deploying, it will not happen at 2am on a Saturday. It should be a setting.
• Your customer and order data has to be portable. Subscription tokens are the trap here, exactly as in any replatforming project — they belong to the gateway, not to you. Losing a processor can mean losing every recurring payment method at the same time.
• Chargeback discipline as a standing process. In a high-risk account the threshold that triggers review is lower and the consequence is worse. Clear billing descriptors, obvious cancellation, fast refunds and responsive support are not customer-service niceties here. They are how you keep the account.

This is also why the platform decision goes differently in this category. On Shopify you are on a third-party gateway with the fee stack that implies, and you accept a degree of platform risk. On WooCommerce you own the stack and can wire in whichever processors will have you — which is why several of the regulated stores we run are on Woo, including GRH Kratom, where the direction of travel and the trade-offs are set out properly.

Build compliance into the checkout, not the shipping settings

The most common mistake we see is treating state restrictions as a shipping problem. Someone disables a state in the shipping zones and considers it done.

That fails in a specific and expensive way: the customer builds a basket, enters payment details, and only then discovers they cannot order. You have paid for the click, taken the intent, and produced a furious support ticket. Worse, plenty of setups only check the shipping address, so a customer in a prohibited state who enters an out-of-state billing address sails straight through.

Restriction belongs at three points.

1. On arrival. A geo-IP hint on first visit, softly. Not a hard block — geo-IP is wrong often enough that a hard block will turn away real customers — but enough to say “we cannot ship to Indiana” before anyone falls in love with a product.
2. At the product level. If some SKUs are restricted in a state and others are not, the product page has to know. This is a data-model decision: restrictions are a property of the product, held as structured data, not a note in the description.
3. At checkout, on the shipping address, as a hard block with a clear message. This is the one that must never fail. It should be a server-side validation, not a client-side script that a stale cache can skip.

Age verification sits in the same category. Where the applicable framework sets 21, a checkbox is not compliance — but a full identity check will cost you a large share of your conversions. The proportionate answer for most operators is a date-of-birth gate plus recorded acceptance at checkout, escalating to a verification service only where the rules or your counsel require it. Whatever you choose, log it. If somebody asks how you enforce age, “we have a checkbox” is a weaker answer than a timestamped record.

The content problem: what you cannot say

This is where regulated categories differ most from ordinary ecommerce, and where the biggest legal exposure usually sits — not in the checkout, in the copy.

For anything ingestible, claims that a product diagnoses, treats, cures or prevents a condition move it, in the regulator’s eyes, into a different product class entirely. FDA warning letters in this space are overwhelmingly about marketing language rather than the product itself. The letters are public. Read a few before writing product copy; they are the clearest possible specification of what not to say.

The practical consequences for a store build:

• Product descriptions need a review step, and the person merchandising needs to know where the line is. This is a training and process problem more than a technical one.
• Customer reviews are user-generated claims. A five-star review saying a product cured someone’s condition is on your website, published by you. Review moderation is a compliance function here, not a brand-tone one.
• Blog and email copy carry the same constraints, and are usually written by someone further from the compliance conversation.
• Lab reports do a lot of work. Certificates of analysis, per batch, linked from the product page, are the strongest trust signal available in a category where customers are rightly suspicious. They are also structured data: batch, date, analyte, result, lab. Build them as data, not as a folder of PDFs nobody can search.

There is an odd upside here. Because you cannot make efficacy claims, you have to compete on sourcing, testing, transparency and consistency — which is exactly what an informed buyer in this category is actually shopping for.

You will not be able to buy traffic

Google Ads and Meta both prohibit the category. Amazon will not list it. Several major email platforms have terms that exclude it, and some payment-adjacent tools quietly do the same.

So the acquisition mix inverts. Paid search, the default first move for most ecommerce, is unavailable. What is left is organic search, email and SMS to a list you own, retention and repeat purchase, and community and word of mouth.

Which makes three things unusually valuable.

Organic search becomes the primary channel rather than a supporting one. That justifies a level of investment in content and technical SEO that would be over-engineering for a store that can simply buy clicks.

Your email list is an asset with no substitute. There is no way to replace it with spend if it is lost. Own it, export it regularly, and do not let it live only inside one vendor.

Retention economics dominate. With acquisition capped, lifetime value is where the growth is. Subscriptions, replenishment reminders and genuinely good post-purchase experience are not optimisations here, they are the business model. This is also why conversion work pays back faster in a restricted category than almost anywhere else: you cannot pour more traffic in the top, so the only lever is what happens to the traffic you already have.

What we would build first

If you are starting or rebuilding in a regulated category, the order that has served our clients best:

1. Get the compliance position documented by someone qualified, in writing, with the date on it. Everything downstream is an implementation of that document.
2. Secure two payment processors before you build the storefront. This determines platform choice, so doing it second means rework.
3. Model restrictions as data from the first line of code. Product-level, state-level, editable by a non-developer, with an audit trail.
4. Build the checkout block server-side and test it against every prohibited state before launch. Automate that test so it runs on every deploy.
5. Then build the nice storefront.
6. Set a calendar reminder to re-check the regulatory map quarterly. Not a note in someone’s head.

Most agencies will build you step five and hand you an invoice. The first four are where the business actually lives.

The honest summary

Selling a heavily regulated product online is not primarily a legal problem or a technical problem. It is an operational one. The law says you may trade; a dozen private companies each get their own vote on whether you can, and any of them can change their mind without notice.

The stores that survive in this category are the ones built on the assumption that something will be withdrawn — a processor, a platform policy, a state’s legal status — and that when it happens the response needs to take hours rather than weeks. That assumption changes the architecture. It is the difference between a store that has a bad week and one that has a bad quarter.

The couriers get a vote too

Payment is the risk everybody talks about. Shipping is the one that surprises people.

Carriers publish their own prohibited and restricted item lists, and those lists are not the law either — they are commercial policy, they differ between carriers, and they differ again between a carrier’s domestic and international services. A category that ships fine domestically may be refused across a border by the same company.

The operational consequences are worth designing for rather than discovering.

• Your rates depend on which carriers will take you, so shipping economics in a regulated category are usually worse and less flexible than the benchmarks you will read.
• A carrier can reclassify a category with about as much notice as a processor can. Same failure mode, same answer: more than one account, and a way to switch that does not need a deploy.
• Packaging and labelling requirements may be carrier requirements rather than legal ones, and they change.
• International orders need per-destination rules, not a single global on/off. This is the same restriction data model as the state logic, extended by country — which is the argument for building it generically the first time rather than hard-coding fifty states and rewriting it a year later.

The pattern is now familiar and it is the whole thesis of this article: every intermediary between you and your customer has a policy, that policy is stricter than the law, and it can change without asking you.

If you are selling from or into India

Most writing about regulated ecommerce assumes a United States operator. The structure of the problem is the same in India, but the specific gatekeepers differ, and a few things are meaningfully harder.

Ingestible and wellness products generally fall under FSSAI rules, which govern licensing, labelling and permitted claims. Advertising is additionally policed by ASCI’s codes, which have their own position on health and wellness claims and which platforms increasingly enforce directly. If you are selling into India from abroad, import rules and customs classification become a live part of the product decision rather than an afterthought.

The commercial mechanics differ too, in ways that hit the build.

Cash on delivery changes the risk calculation. In a category with elevated return and refusal rates, COD moves the loss from chargebacks to undelivered stock and reverse logistics. Whether you offer it, and on which SKUs and pincodes, is a data-model question exactly like state restriction.

Payment gateways apply category rules of their own, and the domestic processors have their own high-risk lists. The redundancy argument holds without modification.

Marketplace policy is stricter than marketplace practice. Categories that are formally restricted on the large Indian marketplaces are frequently visible on them anyway. Building a business on that gap is a decision to be one enforcement sweep away from zero revenue — which is precisely the argument for owning the direct channel, and the reason MindPanda moved off marketplace dependence.

The through-line for both markets: know which gatekeepers apply to you, assume each will change its mind at least once, and build so that responding takes an afternoon.