Restricted and Prohibited Products on a Marketplace: The 3 Gates

Restricted products on a marketplace are goods somebody may sell only with a permit, only with certain data, or only to certain places, and those three conditions are independent of one another.

You are responsible for whatever can be bought on your platform. Not the seller who posted it, and not the sheet that was supposed to keep it out.

And a sheet of "what we do not accept" ages faster than you can update it.

This article breaks down:

• Why is a list of prohibited products always out of date?
• Which 3 gates replace that list?
• What happens when a seller's permit expires?
• When should you verify a buyer's age?

Key insights

• A list of banned products is out of date the week you write it.
• Ask three questions instead. May this seller sell it? May this product be listed? May it go to that country?
• A permit is a document with a scope and an expiry date. A tick-box saying "I hold the required permits" proves nothing to anyone.
• Most blocked offers in a regulated category are not forbidden. They are missing a field.
• When a permit expires, only the offers it covered should stop. Switch off the whole account and your team turns the gate off within a week.

Why is a list of prohibited products always out of date?

Every operator starts the same way, with a sheet of the categories we do not accept: weapons, alcohol, medicines, chemicals, adult content. And everyone discovers after a few months that the market adds new things faster than the sheet grows.

The list fails for a structural reason. "Prohibited" is not a property of a product.

It is the result of three things colliding: who is selling, what exactly they are selling, and where it is going. The same name in the category tree covers goods that move freely and goods that need a permit, because the deciding parameter is not in the name.

A cosmetic in an aerosol and the same cosmetic in a tube fall into two different transport regimes. The list asks about the label, and the answer sits in an attribute.

So replace "is this product prohibited" with three questions that have different answers and arrive at different moments:

1. Does this seller have the right to sell it? A question about a document somebody issued, for something specific, for a period of time.
2. May this product be listed? A question about a property of the goods and the completeness of the data that property demands.
3. May it be delivered there? A question about the country, the mode of transport, and the moment the goods change hands.

The gates are independent. A product can clear the second and fail on the third, and a seller can hold a permit and list goods under it that it does not cover.

The list requires that somebody foresee everything in advance. Three gates require only that the system know what it does not know.

Gate 1: which permit data must a marketplace hold?

A permit to sell in a regulated category is always a document, and a document has an issuer, a scope, and an expiry date. If onboarding covers it with a field reading "I declare that I hold the required permits", you do not have a gate.

You have a declaration that, in an inspection, lands on you together with the seller.

The permit record has to hold six things: type, issuing authority, number, scope (what exactly it covers), expiry date, and who verified it and when. The scope matters most and gets skipped most often, because a permit is often tied to a specific point of sale, range of goods, or country.

A seller authorized for one location and one group of goods is not an "authorized" seller.

Verify in a register. For some regulated categories, public lists of entities cleared to sell exist.

In the trade in medicines, European rules require legally operating shops to carry a common mark and let anyone check them against a national register. A scanned PDF confirms the seller has a file.

The register confirms they have the permit. Regulations on the traceability of businesses expect exactly that: data checked against official sources available to you.

Seller identity, beneficial owners, and sanctions are a separate layer and "Marketplace Seller Verification: KYC, Beneficial Owners, and Sanctions". One thing is at stake here: whether an entity you have already verified may enter this category.

Gate 2: why does the rule belong on the attribute?

The second gate stands where an offer gets published, and what it produces is counterintuitive. Most blocked offers in a regulated category are not prohibited: they are incomplete.

The EU rules on product safety require platforms to hold offers back until the seller supplies the required information about the product and about who answers for it in the Union, and that information has to be visible with the offer. In practice, that is a handful of new mandatory fields.

It is also the mechanism by which "prohibited product" means "product without a required field."

Three design rules follow. Gate on the attribute: the rule "in this category the responsible-entity field is mandatory" works, while "we do not accept chemicals" does not, because chemicals are not a category.

Do not rely on a list of banned phrases in the description. It catches the obvious cases and lets through anything somebody named differently.

Validate that the category matches the product, because a seller listing under the wrong category walks past your rules without even looking for them. In implementations we know of, that validator got bolted on outside the platform, after products from a different shelf entirely turned up in the catalog.

The category tree and the approval workflow are separate chapters. Only one thing counts here: a regulatory gate is a rule on an attribute.

And what about the offers already live when you switch the gate on? A rule created today does not by default touch yesterday's catalog.

That is a separate problem, described in "Marketplace Compliance: Adding a Required Attribute to a Million Offers".

Gate 3: what does delivery add to a restricted product?

The third gate asks about delivery, and nobody thinks about it before the first return from a courier. The offer can be legal and the shipment not.

Carrying dangerous goods runs under a regime of its own. The goods have to be classified, packed, labeled, and described in a transport document, and the people handling them have to be trained.

What decides whether goods fall inside it is a product parameter. For a lithium battery, what counts is the capacity and whether it travels alone or inside a device, and classification is the sender's responsibility.

Two geographic layers sit on top. Countries can restrict the carriage of particular goods across their territory, and the air channel has its own, stricter exclusions.

Three pieces of data follow: a hazard class on the product, a list of countries excluded for the offer, and a flag that strips from checkout the delivery methods this item may not travel by. Without the third, the first two are decoration: the buyer picks a parcel locker, the seller cannot ship there, and the conflict gets settled at your support team's cost.

What happens to offers when a seller's permit expires?

This is the most overlooked element of this layer and the best test of a vendor. An offer goes on living after the document behind it has expired.

The offer sits in the catalog, and the expiry date sits in an attachment nobody reads twice.

A realistic scale: a seller with three regulated categories, 4,200 offers, and one permit covering 900 of them. The day after it expires, those 900 are still selling, and the other 3,300 have nothing to do with it.

The system has to do four things:

• Warn more than once. Three reminders instead of one, for example, at 60, 30, and 7 days before. That is your parameter, so set it to how long a renewal takes in that category.
• Act within the scope of the document. What drops out of sale are the offers covered by that permit. A gate that kills a whole account over one expired piece of paper gets switched off in its first week.
• Take off the shelf, do not delete. The offer moves into a state where it cannot be bought, with the reason recorded, so a new document brings it back in one move.
• Do not break commitments already made. Orders placed earlier have to be fulfilled. The gate works on selling, and fulfillment carries on.

How should a marketplace handle brand and counterfeit reports?

A permit to sell a brand looks like a gate-one permit and behaves differently, because it cannot be verified up front at the scale of a catalog. There is no public register of authorized sellers for every brand, and a piece of paper from the seller confirms an agreement with some distributor.

That is why the law does not demand omniscience from you. It demands a working reporting path and a fast reaction: a channel where anyone can report an unlawful offer, and the rights holder above all, together with prompt removal of the content once you learn of it.

Regulations on platform liability also provide a sanction for repetition. An account that keeps posting manifestly unlawful content can be suspended, but only after a warning and with the reason given.

So reacting has a basis, and it has a price. You need a "report" object carrying a due date, a decision, a justification, and a counter per seller.

Without the counter, you cannot tell a first mistaken listing from a tenth, and that is the only information on which suspension is allowed. Practice adds two things.

A human outside the platform decides on reinstatement, and a restored account needs a probation period, so the same thresholds do not close it again over events already settled.

Two warnings that will save you a quarter. Whitelists of sellers per individual product are technically possible and operationally unworkable.

With a large catalog, nobody keeps them current. Selective distribution makes sense as a category policy or a brand policy.

And brand exclusivity is politically slippery, because a brand lives in several categories at once, so exclusivity granted in one does not close off the rest.

When should a marketplace verify a buyer's age?

If you sell anything with an age limit, the question is not "whether" but which of three moments. Each carries a different price.

1. In the cart or on the product page

The cheapest and the weakest. Ticking a box is not verification, and data protection authorities say so plainly: a user's own statement about their age is not enough, and a check against a payment card is unreliable both ways.

It does add friction in the funnel.

2. At checkout

You already hold identity and payment, so real verification is feasible, but asking for a document takes you into sensitive data. Data protection regulators recommend an arrangement with an independent party confirming age, where you learn only that the condition is met and never see the document.

It sounds like a complication and costs less than storing scans.

3. At handover of the goods

The courier or the pickup point verifies. The strongest and the most expensive: you need delivery methods that support it, and a policy for a refused handover, meaning a return at the cost of somebody agreed in advance.

The law sets the age limit and which categories it covers, and that differs between countries. What you decide is not the limit.

It is the moment. That is a product decision.

How do the 3 gates compare?

What do the 3 gates change about your seller onboarding?

1. Seller onboarding stops being linear

Letting somebody into the platform and letting them into a category are two decisions, at two moments, on different evidence. A seller active in three categories and permitted in two is a normal state.

2. A request from a seller becomes an object

A request about a brand, a category, or a reinstatement travels by email at many operators today, with a spreadsheet and a decision taken outside the system. Until it is a record with an owner and a due date, you cannot measure how long it takes.

3. Product safety is a gate of its own

Recalls and post-sale incidents are "GPSR for Marketplaces: Product Safety, Traceability, and Recalls", environmental fees and liability for the content of an unlawful offer are separate chapters again.

How do you roll out the 3 gates, and in what order?

The rollout order runs from the hardest gate to the most expensive, and not everything goes in at the start:

1. Close the categories you do not want in the tree itself. With no node to list under, there is nothing to ban. The only gate that works without data.
2. Turn on a permit with an expiry date in the categories you open deliberately. Verify by hand if you must. Date and scope in the record matter more than automation.
3. Add attribute rules: mandatory fields and validation that the category matches the product.
4. Age and transport last, because they need changes in checkout and carrier contracts.

Four questions for the platform vendor:

1. Show me a seller permitted in one category and not in another, and point in the data to the scope of that permit.
2. Show me what happens on the day it expires: do the offers in scope go dark, or the whole account?
3. Show me the rule that blocks publication on a missing mandatory field, and say what it does with offers already published.
4. Show me an infringement report as an object with a due date, a decision, and a counter.

Which mistakes do operators make about restricted products?

1. A declaration instead of a document

A checkbox saying "I hold the required permits" is not a gate: in an inspection, you have no proof you checked anything, and they ask you first.

2. A permit with no expiry date and no scope

The most expensive mistake here, because it surfaces a year later and covers offers that sold normally throughout that year.

3. A whitelist of sellers per product

It looks like precision and cannot be maintained on a large catalog: half a year of building, then a quiet decision to drop it.

4. Age verification put off "to the second phase"

It touches checkout, delivery methods, and carrier contracts at once, so either it is a launch requirement, or you do not sell the category.

5. Infringement reports handled over email

Without a record carrying a due date and a counter, you cannot prove you react fast, or that you suspend for repetition.

What do you still have to settle yourself about restricted products?

This guide is a map of mechanisms and data, and it deliberately carries no names of legal acts, no thresholds, and no deadlines. Those change faster than this document.

Confirm four families of regulation with a lawyer before you open your first regulated category:

• The EU rules on product safety, known in practice as GPSR: which fields you have to hold on the product page and who the responsible person in the EU is for your assortment.
• The rules on platform liability for content and on the traceability of businesses, known in practice as the DSA: what the reporting path has to look like, how fast you react and on what basis a seller may be suspended.
• The sector rules for your own categories: alcohol, medicines and medical devices, supplements, chemicals, food, weapons, digital content, and adult products. Each has a different authority, a different register, and a different kind of permit.
• The transport rules for dangerous goods and data protection in age verification: both enter the project through logistics and checkout.

There is one thing neither a lawyer nor we can settle for you: the line beyond which you deliberately do not enter a category. Part of the assortment is legal, feasible, and unprofitable once you count the cost of your own gate.

Summary: What replaces a list of banned products?

A sheet that ages faster than you can update it. In its place: a permit record with a scope and an expiry date, attribute rules that hold an incomplete offer back, and delivery data that reaches checkout.

Roll them out hardest first — close the categories you do not want in the tree, then permits, then attributes, and leave age and transport for last, because they touch carrier contracts.

Ask your platform what happens on the day a permit expires: do the offers in its scope go dark, or does the whole account? Building a marketplace that needs all three gates on its regulated categories? Talk to us about the build.

Frequently asked questions on restricted products

How does a marketplace control restricted products?

With three independent gates rather than one list. Whether the seller holds a permit covering these goods, whether the product carries the attributes its category demands, and whether it may be delivered to that country by that method.

An offer can clear two and fail the third.

What happens when a seller's permit expires on a marketplace?

The offers it covered should stop selling, and nothing else should change. Warn several times before the date, act within the scope of the document rather than on the whole account, move the offers to a state that records why, and fulfil orders already placed.

A gate that kills an account over one expired document gets switched off in its first week.

When should a marketplace verify a buyer's age?

The law sets the limit and the categories; you decide the moment, and there are three. A tick-box in the cart is the cheapest and is not verification.

Checkout is feasible but takes you into sensitive data, so regulators point toward an independent party confirming age. Handover is the strongest and needs delivery methods that support it.