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.
EVIDENCE WITHOUT A PRODUCTION CLAIM
GREY HAZE / PRE-LAUNCH VERIFICATIONGrey Haze 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 Grey Haze pre-launch verification.
line items included in Grey Haze pre-launch verification.
customer records included in Grey Haze pre-launch verification.
orphan records observed in current Grey Haze 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.