BUILD / RESTRICTED COMMERCE
Vape, CBD, nicotine, adult and other no-ads verticals: a store you own, a working high-risk payment stack, and compliance built into the code.
WHEN ECOMMERCE BECOMES A TRADING-RISK PROBLEM
PAYMENTS / CONTROLS / OWNERSHIPRestricted commerce does not fail because the front end is unattractive. It fails when a payment route, platform policy, age check, duty rule or operational workaround is treated as a minor integration until it interrupts the ability to trade. By then, the business is making high-consequence decisions through support tickets, app settings and emergency releases.
Hollow Point approaches those constraints as commerce architecture. The payment path, eligibility controls, product and market rules, data, release process and operating responsibilities need to fit together. That does not mean we act as a payment processor, law firm or tax adviser. It means the agreed requirements are translated into a system the merchant can understand, test and run.
The UK restricted-commerce market is a proof-rich beachhead because payment continuity, age verification and duty change are immediate operating concerns. It is not an exclusion. Any complex merchant whose platform, checkout, data or compliance model has become a material business constraint can use the same disciplined assessment. Start with an ecommerce migration assessment when the platform decision is still open, or read about Medusa development when owned commerce architecture is already under consideration.
01 / CONSTRAINT
A payment path can become a trading dependency overnight. The question is not which provider sounds best in a proposal; it is how approvals, fallbacks, checkout behaviour, reporting and ownership are designed before that dependency becomes urgent.
02 / CONSTRAINT
Rules that determine eligibility, products, markets or checkout outcomes should be explicit, versioned and testable. A policy that only lives in a spreadsheet, inbox or staff memory is not an operating control.
03 / CONSTRAINT
Age gates and verification journeys need to work with the product, market, payment and customer experience. The right implementation depends on the merchant, jurisdiction and specialist providers involved.
04 / CONSTRAINT
A regulatory change is also a data, pricing, catalogue, checkout, reporting and release problem. It needs a controlled implementation path, not a last-minute banner or an isolated app setting.
THE CONTROL HAS TO EXIST IN THE SYSTEM
PLATFORM-NEUTRAL / CONTROLLED DELIVERYThe platform is an implementation decision, not the offer. A merchant may be able to improve a current platform with correctly scoped integration and operating work. Another may need an owned architecture because the present stack cannot support the checkout, data, compliance or release control the business requires. We assess that distinction before proposing a rebuild.
The same applies to specialist services. A high-risk gateway, an age-verification provider or a tax and duty process may be essential, but none should become a black box around the business. The merchant needs clear data boundaries, a tested customer journey, a recovery path and named ownership when a condition changes. The platform should support that operating model, not obscure it.
PAYMENTS
We map the checkout and payment dependency before making an implementation recommendation: approval conditions, operational failure modes, reconciliation, provider boundaries and the route for changing course. No provider approval or payment outcome is promised before the relevant parties have assessed the merchant.
COMPLIANCE
The work makes the operating rules visible in the system: who can sell what, where, to whom, under which conditions and with which evidence. The legal position belongs with the merchant and its advisers; the engineering work is making agreed requirements operable and reviewable.
VERIFICATION
Age or eligibility checks must be considered alongside product data, market access, privacy, customer friction and the checkout flow. A control that is easy to bypass, impossible to support or detached from the actual journey is not complete.
OWNERSHIP
Platform ownership is not an argument for rebuilding every service. It is a deliberate decision about which systems, data, integrations and commercial rules must remain under the merchant’s control, and how the team will operate them after release.
REGULATORY CHANGE NEEDS A RELEASE PLAN
UK VAPE / OCTOBER 2026A CONCRETE UK DEADLINE
For an affected merchant, this is not only an accounting date. It can touch product data, pricing, catalogues, stock handling, customer messaging, reporting and the controls around a release. The engineering task is to turn the agreed business and adviser-led requirements into a tested operating change with clear owners.
This page is not legal or tax advice. The merchant remains responsible for obtaining the appropriate advice and for the final compliance position. Hollow Point can make the agreed rules, data and operational process work in the commerce system.
01 / DEFINE
Separate the legal, tax, product, market and operational questions so each has a named owner and an agreed source of truth.
02 / IMPLEMENT
Make the relevant product, pricing, eligibility, checkout and reporting rules explicit in the implementation rather than relying on manual memory.
03 / VERIFY
Check the customer and operations paths, controlled exceptions, reporting and release conditions before the change becomes business-critical.
04 / OPERATE
Record the decision, ownership and recovery conditions so the next duty, policy or provider change is not a new emergency project.
WHEN THE PLATFORM REMOVES THE CATEGORY
PLATFORM POLICY / CATEGORY REMOVALPayment risk is the constraint most restricted merchants plan for. Platform risk is the one that tends to arrive without warning, and 2026 has made it concrete: Shopify removed vape products from its platform worldwide, giving merchants roughly two weeks between the notice and the deadline. Legality in the merchant's own market made no difference to the outcome, because the decision was a commercial policy rather than a regulatory one.
We have written the practical detail up separately, including the options that exist at different store sizes and what has to happen before an old store is switched off: the Shopify vape ban and what it actually leaves you. The short version is that the decisions with real deadlines are not the platform choice at all. They are the redirect map, which cannot be reconstructed once the original store is gone, and the payment underwriting, which runs on the acquirer's timetable rather than yours.
The wider point for anyone trading in a restricted category: the mechanism that produced this outcome is not specific to vape. Sustained regulatory pressure produced a platform policy change with a very short notice period. Any category sitting near a regulator's attention can be exposed to the same sequence. Nicotine pouches, CBD and adult products all sit in that space today.
What this changes about how a store should be built is narrow but important. Continuity stops being a question about payment providers alone and becomes a question about the whole trading dependency: which parts of the operation would still function if the platform withdrew, how quickly the catalogue, customer records and URL structure could be re-established elsewhere, and whether anyone has actually tested that rather than assumed it. A store that cannot answer those questions has an unpriced risk, whatever its checkout conversion rate looks like.
None of that argues for rebuilding every system. It argues for knowing, deliberately and in advance, which dependencies are acceptable and which are not.
EVIDENCE WITHOUT A PRODUCTION CLAIM
VAPE RETAIL FLAGSHIP / PRE-LAUNCH VERIFICATIONOur flagship vape-retail build is the relevant implementation reference because the work crosses data, platform ownership, payments, compliance and the operational path after a build. Its status remains deliberately limited: it is in pre-launch verification and production cutover has not been verified.
The figures describe the current verification scope, not a completed-migration claim or a promise of a comparable result. They are a reminder that a restricted-commerce build needs validation across the data and operating model, not only a polished storefront.
For the wider platform decision, explore the ecommerce migration service. For a technically qualified discussion about an owned stack, see Medusa development.
orders included in the flagship vape-retail pre-launch verification.
line items included in the flagship vape-retail pre-launch verification.
customer records included in the flagship vape-retail pre-launch verification.
orphan records observed in the current flagship pre-launch verification.
WHO THIS IS FOR
QUALIFIED CONVERSATIONFIT SIGNAL
The merchant needs a payment setup that is designed around a real approval, continuity and operational ownership process rather than a generic checkout installation.
FIT SIGNAL
Age, eligibility, product, market or regulatory conditions need reliable expression across the customer journey and operating workflow.
FIT SIGNAL
The business needs to assess whether its current platform, apps or checkout path can support its actual commercial and compliance constraints.
FIT SIGNAL
There are named people who can make decisions, involve the appropriate advisers and maintain the operating standard after a build.
FREQUENTLY ASKED QUESTIONS
PLAIN ANSWERS / RESTRICTED COMMERCEIn practice it is any category where acquirers price the risk differently, advertising platforms restrict you, or a hosted platform reserves the right to remove you. Vape and nicotine, CBD, adult products, supplements, knives and firearms accessories all sit here. The label matters less than the consequence: fewer payment options, no paid acquisition, and a platform relationship that can end on notice.
Yes. A platform acceptable use policy is a commercial agreement, not a legal standard, so it can be stricter than the law in your market. Shopify removed vape products worldwide in July 2026 including products that were fully compliant and, in the US, FDA-authorised. Merchants received roughly two weeks between notice and deadline.
Payments, nearly always. High-risk underwriting runs to weeks and is decided by the acquirer, not by you, so it sets the critical path. A finished store that cannot take money is worse than an unfinished one. Payment risk also follows the merchant rather than the platform, so changing platform does not by itself make an acquirer more comfortable with your category.
It solves the deplatforming problem, because nobody can remove a store you host yourself. It does not solve the payments problem, and it moves hosting, security, updates and performance onto you. For smaller catalogues that trade is often worth making. At larger catalogue sizes it needs genuine engineering attention rather than a plugin stack.
That depends almost entirely on whether the redirects are mapped while the original store is still under your control. Old URLs are served by the old platform, so once it is switched off the ability to redirect them goes with it and there is no retrospective fix. Mapped and verified before cutover, the ranking impact can be small. Left until after termination, a decade of URL equity can be lost.
An app can gate a page. The harder parts are keeping verification records when you move platform so returning customers are not asked again, making eligibility rules explicit across product data, market access and checkout, and being able to evidence the control later. Those are build decisions rather than an install.
No. The legal and tax position belongs with the merchant and its advisers, and that includes the UK Vaping Products Duty taking effect on 1 October 2026. Our work is making agreed requirements operable in the commerce system: explicit, versioned, testable and reviewable rather than living in a spreadsheet or one person's memory.