Selling Pharmacy and Health Products in the US: Compliance-First E-Commerce with VBWD

The hard part of selling medicine online isn’t the checkout

If you run a US pharmacy or health-product store, the shopping cart is the easy 10%. The other 90% is proving that the right product went to the right person in a state where you are licensed to sell it, and keeping a record you can defend if a board of pharmacy asks. Generic e-commerce software is built to sell as many units as possible to as many people as possible. That default is exactly wrong for regulated health products.

VBWD is a self-hosted, source-available shop platform (Python/Flask, PostgreSQL, Vue 3, Docker) built as an agnostic core with plugins for shop, product types, discounts, invoicing, and payments. It gives you technical controls that support a compliance program. It does not make you compliant, it is not a certification, and nothing here is legal advice.

The US is a patchwork, and most shop software ignores that

There is no single federal “sell drugs online” licence. Pharmacy practice is licensed state by state through each state’s board of pharmacy, and shipping a prescription into a state generally means holding a licence recognized there. Layered on top:

• OTC products — over-the-counter, sold without a prescription, but some carry their own rules.
• Prescription (Rx) products — require a valid prescription and a licensed pharmacist’s involvement.
• DEA-scheduled controlled substances — a much stricter regime governed by DEA rules on top of everything else. Treat these as a separate, harder problem.
• Age-restricted items — for example, products containing pseudoephedrine follow logging and quantity-tracking patterns.
• FDA oversight of the drug products themselves.
• Health-data privacy — HIPAA applies to covered entities and their business associates. It is the operator’s obligation, not a checkbox in a shop engine.

To operate lawfully you need state-by-state pharmacy licensure, a licensed pharmacist, and real legal counsel. What software can do is model these distinctions instead of flattening every SKU into “a product.” That modelling is where VBWD’s agnostic-core-plus-plugins architecture earns its place.

Product types: model OTC, Rx, restricted, and scheduled differently

VBWD’s shop uses a product-type registry where a type is an additive cluster of custom fields and workflow hooks. You are not forced into one schema for every item. You define an otc type, an rx type, a restricted_otc type, and (if you ever go there) a controlled type, each carrying only the fields and steps it needs.

• rx can require a prescription reference, a prescriber identifier, and a pharmacist-verification state before the order can ship.
• restricted_otc can require date-of-birth capture and quantity limits.
• otc stays lightweight so ordinary vitamins and first-aid supplies don’t inherit friction they don’t need.

Because types are additive, adding a compliance field to Rx products never touches the OTC catalogue. The range of shop building blocks is on the plugins page.

Geo-blocking: only ship where you hold a licence

State-level access control lets you restrict which shipping destinations a product or the whole store will accept. If your licensure covers a defined set of states, you configure those as the allowed set and orders to other states are refused before payment, not after. This is a technical guardrail against the most common failure mode: selling into a state where you have no standing. It enforces your list; it does not tell you which states you are licensed in. That comes from your licences and your counsel.

Age and identity gating

For age-restricted products you can gate purchase behind date-of-birth or identity-verification steps tied to the product type, so the check fires for the SKUs that need it and stays out of the way for the ones that don’t. The gate is a workflow step you place in the order path; the strength of the identity check depends on the verification method and provider you connect.

Prescription upload and pharmacist verification

An Rx workflow is a product type plus order data plus messaging. A customer ordering an rx item uploads or references a prescription, the order lands in a pending pharmacist review state, a licensed pharmacist reviews it, and only an explicit approval moves it toward fulfilment. Secure messaging between the operator and customer handles clarifications without email sprawl. VBWD gives you the state machine and the data model; the licensed pharmacist doing the review is a human role you must staff, not software.

Audit trail: the event bus and signed webhooks

Regulated selling lives or dies on records. VBWD’s event bus emits domain events across the order lifecycle, and outbound webhooks are signed so a downstream system can verify authenticity. You can stream purchase and verification events to an append-only log or a compliance system of record — for example, the logging pattern behind restricted-OTC sales. The signed, event-driven design is described under features. You still define what to log and how long to retain it; the platform gives you a tamper-evident pipe to send it through.

Pricing, tax, payments, and disclosures

Unified pricing supports per-jurisdiction tax, which matters when health-product taxability varies by state. Payments run through swappable provider adapters, so you can choose processors that will underwrite pharmacy-adjacent merchants rather than being locked to one. The CMS lets you publish the disclosures regulators and customers expect — pharmacist name and credentials, licence information, and terms — as first-class content next to the store.

Data residency and access control for health data

VBWD is self-hosted. The database runs on infrastructure you control, which is a precondition for handling protected health information under a program you can actually audit. Granular access control limits who inside your organization can see order and health-related fields. To be blunt: this supports a HIPAA program, it does not constitute one. VBWD is not “HIPAA-certified,” and no vendor can hand you compliance. The safeguards, the business-associate agreements, the training, and the accountability are yours.

A worked configuration sketch

Say you are licensed to ship Rx items to three states and OTC nationwide. A configuration might look like this:

product_types:
  otc:
    fields: [dosage, active_ingredient]
    ship_states: ALL
  restricted_otc:
    fields: [dosage, active_ingredient, dob_required, unit_quantity_cap]
    verification: [age_gate]
    audit_events: [purchase.logged]
  rx:
    fields: [prescription_ref, prescriber_id, pharmacist_review_state]
    workflow: [pending_review -> approved -> fulfil]
    ship_states: [CA, NY, TX]     # only where you hold licensure
    verification: [identity_check]
    audit_events: [rx.uploaded, rx.reviewed, rx.approved, order.shipped]

webhooks:
  - event: rx.reviewed
    url: https://compliance.internal/log
    signed: true
  - event: purchase.logged
    url: https://compliance.internal/restricted-otc
    signed: true

tax:
  strategy: per_jurisdiction
payments:
  adapters: [processor_a, processor_b]

The list of ship states is a hard technical boundary. The signed webhooks turn every review and restricted sale into a record you can retain and reconcile. None of this decides whether your licences actually cover CA, NY, and TX — that is a legal fact you supply. Integration details and adapter contracts are in the documentation.

Honest limits

Be clear-eyed about what a shop engine cannot do:

• It does not grant pharmacy licensure or replace a licensed pharmacist.
• It does not make you HIPAA-, FDA-, DEA-, or board-compliant. It provides controls a compliance program can use.
• Controlled substances are materially harder. DEA rules go well beyond the patterns above; do not treat scheduled drugs as “just another product type.”
• Identity and age verification are only as strong as the provider and method you wire in.
• Geo-blocking enforces the state list you give it; correctness of that list is on you and your counsel.

Takeaway

Compliance-first commerce means the software’s defaults push toward restriction, verification, and record-keeping instead of maximum throughput. VBWD gives you the technical building blocks — product types that separate OTC from Rx from restricted, state-level geo-blocking, verification gates, a pharmacist-review workflow, a signed audit trail, per-jurisdiction tax, swappable payments, and self-hosted data you control. It is source-available under BSL 1.1 (free until 6.7 BTC/year of attributable sales, converting to Apache-2.0), so you can inspect and run the whole stack yourself. Pair those controls with your licences, your pharmacist, and your lawyers. The platform handles the technical guardrails; the licence to operate is still yours to earn and hold. You can review commercial terms on the billing page.

Learn more about VBWD

VBWD is a self-hosted, source-available platform for building subscription products, marketplaces, and AI-powered apps. Explore it further:

• 🌐 Website and documentation: vbwd.cc — see the plugins, architecture, and developer docs.
• 💻 Source code and plugins on GitHub: github.com/VBWD-platform
• 🎥 Watch VBWD in action: demo video 1 and demo video 2
• 💼 Follow the project on LinkedIn: linkedin.com/company/vbwd