If you sell something regulated - medicines, veterinary products, anything requiring a licence or a prescription - you will plan for the licensing, the prescriber workflow and the record keeping. The constraint that arrives unannounced is that Visa and Mastercard have independently classified your category, and their rules apply regardless of how compliant you are with everyone else's.
Selling regulated goods puts you under a sector regulator: a medicines authority, a veterinary medicines directorate, a licensing body. That regime governs what you may sell, to whom, under what supervision and with what records.
Separately and independently, the card schemes maintain their own classification of high-risk categories. Pharmaceuticals sit in it. Being fully licensed under your sector regulator does not exempt you: it typically means mandatory registration with the scheme, verification of your licence by the acquirer, additional monitoring and per-merchant fees passed down to you.
These two regimes are not coordinated, they have different timelines, and satisfying one says nothing about the other. Teams routinely discover the second one at the point an acquirer declines them.
If you operate a platform where multiple licensed sellers transact - a group of pharmacies, a network of practices, a buying group - you are combining two things acquirers treat carefully: payment aggregation, and a high-risk category.
Each is manageable alone. Together they are the combination acquirers are penalised most heavily for carrying, which means onboarding is slow, manual, and sometimes declined outright.
The practical consequence: if you move to a platform model, each seller is individually underwritten and individually checked for licensing. A generic marketplace onboards sub-merchants in minutes through an automated flow. Yours will not. Some sellers will be declined, some priced higher, and the whole process needs an operational owner rather than being treated as a background task.
Plan the onboarding pipeline as a product surface with real human effort behind it, not as a form that returns a decision. Assume weeks, assume declines, and design for both.
Licence state is a first-class model. Not a boolean. Licences have numbers, issuers, scopes, expiry dates and renewal states, and expiry must actively disable selling rather than sitting in a report nobody reads. Diary the renewals in the system.
Catalogue restrictions are per seller and per product. What one seller may list depends on their licence scope. That is a matrix, it changes, and it needs to be enforced at write time rather than checked at display time.
Eligibility gates belong before payment, not after. If a purchase requires a prescription, verification, or an age check, resolve it before authorisation. Taking money and then discovering the order cannot be fulfilled produces refunds, and a refund rate is itself a metric acquirers watch.
Fulfilment must be able to refuse. A prescription can be rejected after the order is placed. That is a normal path, not an exception, and it needs a state, a refund route and a customer communication - designed rather than improvised.
Records are the deliverable. Regulated selling is substantially a record-keeping obligation. Who authorised, who dispensed, what was supplied, when, against what evidence. Retention periods are set by the regulator and are usually longer than any other data in your system, which interacts awkwardly with deletion requests. Work that out deliberately rather than at the point someone asks.
An order for a specific medicine reveals a health condition. Under UK and EU data protection that is special category data and it carries heavier obligations than the rest of your customer records.
The awkward part is that it is not confined to a table called
health_records. It is in your order history, your
analytics, your search logs, your email content, your support
tickets, your error reports and your data warehouse. Anywhere a
product name travels alongside a customer identifier, so does the
inference.
Two things follow. Product identifiers should not appear in analytics payloads or third-party tooling by default. And anonymisation for non-production environments has to treat order lines as sensitive rather than as commercial data.
We have built and maintained regulated e-commerce with prescription workflows, licence-scoped catalogues and multi-region operation. If you are moving into a regulated category, the payments conversation should happen early.