Most ecommerce builds begin with a design brief. In regulated categories they begin somewhere less glamorous: finding out what your payment processor will and will not accept.
That sequencing matters more than founders expect. Payment processing is not a feature bolted on at the end of a build. It is a constraint that shapes platform choice, checkout architecture, data handling and even the copy on your landing pages. Getting it wrong means rebuilding, and in some categories it means losing the ability to take money at all while you do.
Here is how the stack actually assembles, and why the order is fixed.
Layer one: whether you can be underwritten
Every payment provider maintains a list of prohibited and restricted business types. The prohibited list is straightforward. The restricted list is where regulated ecommerce lives, and the distinction is that restricted businesses can be onboarded, but only with additional underwriting.
For a prize competition operator, a subscription box in a regulated category, or a marketplace handling third-party funds, underwriting typically asks for evidence of legal standing, a description of the transaction flow, and sometimes a legal opinion confirming the model sits outside the activity that would require a licence.
The practical consequence is that you need this answered before you choose a platform. An operator who builds first and applies for processing second can find the model they have built is not one their provider will support.
Layer two: who holds the funds
In a straightforward retail transaction, money moves from the customer to the merchant. Introduce a delay between payment and fulfilment, a third-party seller, or a pooled pot paid out later, and the picture changes.
Holding customer money ahead of delivery raises questions about safeguarding and, depending on structure, may touch on regulated payment activity. The Financial Conduct Authority sets out when handling funds on behalf of others constitutes a regulated activity, and the answer turns on specifics rather than on how the business describes itself.
Most operators resolve this by ensuring funds never rest in a way that triggers the question — using a processor’s own escrow or split-payment facilities rather than routing money through their own account. That decision has direct architectural consequences for how orders, payouts and refunds are modelled.
Layer three: what the platform asks you to prove
Advertising platforms run their own approval processes, separate from and often stricter than the legal position.
A business can be entirely lawful and still find its advertising account restricted because it cannot evidence that position in the format the platform expects. Meta, for example, requires specific documentation for certain categories before it will permit ads, and the absence of that documentation is treated as a failure regardless of whether the underlying business is compliant.
For UK operators this is frequently where the real cost sits. The legal work is finite; the advertising restriction is ongoing revenue. Agencies working in this space routinely find that the compliance documentation a client needs for their ad account is more urgent than anything on the development roadmap.
Layer four: data, consent and retention
Regulated categories attract more scrutiny on data handling, and the requirements compound. You are likely holding identity information for verification, transaction records for audit, and marketing consent that must be demonstrably separate from the purchase.
The Information Commissioner’s Office guidance on lawful basis is the reference point, and the common failure is conflating consent for marketing with the contractual necessity of processing an order. They are different bases with different rules, and treating them as one is a frequent finding in enforcement.
Retention is the other recurring gap. Audit requirements may oblige you to keep transaction records for years; data minimisation obliges you to delete what you no longer need. Both are true simultaneously, and resolving them requires a documented schedule rather than a default.
Layer five: the audit trail
In categories where outcomes matter to customers — allocations, draws, selections, limited releases — you need to be able to demonstrate after the fact that the process ran as described.
That means immutable logging of the events that determine the outcome, timestamps that cannot be amended, and a record that survives a database migration. It is unglamorous engineering and it is almost always retrofitted, usually after the first dispute.
Building it in from the start costs little. Adding it later means reconstructing history you did not keep.
Why the order cannot be changed
Each layer constrains the one below it. Underwriting determines whether the model works at all. Fund flow determines the order architecture. Platform approval determines whether you can acquire customers. Data requirements determine what you collect and how long you keep it. The audit trail determines what you can prove.
A build that starts with design and arrives at compliance has made commitments at every stage that may need undoing. A build that starts with underwriting makes fewer decisions, but makes them in an order that holds.
UK specialists in this area, Nera Marketing among them, generally describe the same sequencing, which suggests it is a property of the problem rather than a house style.
The takeaway
Regulated ecommerce is not standard ecommerce with extra paperwork. The compliance position determines the technical architecture, and the technical architecture determines what the business can do commercially.
Founders entering these categories are usually advised to get legal advice early. The less common advice, and arguably the more useful one, is to get the payment conversation started before the first line of code.