---
url: "https://dfylegitscript.com/blog/platforms-marketplaces-and-white-label-telehealth-certification"
title: "Platforms and marketplaces: whose website is being certified"
description: "A LegitScript certification attaches to a website rather than to a company, so a telehealth platform serving twenty clinics has to answer a question its architecture never asked: whether the patient transacts on the platform's domain or on the clinic's, because that decides who the applicant is."
published: "2026-04-22T13:30:37+00:00"
modified: "2026-05-04T10:00:37+00:00"
---

# Platforms and marketplaces: whose website is being certified

A LegitScript certification attaches to a website rather than to a company, so a telehealth platform serving twenty clinics has to answer a question its architecture never asked: whether the patient transacts on the platform's domain or on the clinic's, because that decides who the applicant is.

## Key takeaways

- Whose domain takes the payment decides who the applicant is, and that is a question most platform architectures were never built to answer.
- Four architectures behave differently under review: a marketplace, a directory, a white label estate and a software enablement model each certify different websites.
- Template copy replicates a defect across every customer at once, so one claim in a supplied theme becomes twenty sites making the same claim.
- The contract term nobody writes is the one saying who fixes a page, by when, and what happens to a customer whose credential lapses.

Platform businesses arrive at certification with an assumption baked into the
product: that they provide software and somebody else provides care. It is a
reasonable commercial position and it is not how the question is decided.

The question is decided by the website a patient uses, what happens on it, and
whose name is on the transaction.

## The determining question

Where does the patient hand over money, and to whom?

If the patient completes intake and pays on your domain, under your brand, that
is your website and your commercial relationship, whatever the contracts say
about who provides care. The certified thing is a website, and this is the
website.

If the patient transacts on the clinic's own domain, using software you supply,
the clinic's site is the one in question and yours is a business-to-business
product.

The uncomfortable middle is the white label: a domain owned by the clinic,
running your product, with your infrastructure, your intake and your fulfilment
relationships behind it. That one has to be answered site by site, and somebody
has to own the answer.

## The four architectures, briefly

**Marketplace.** Patients browse providers or products on your domain and
transact there. You are the merchant the patient sees, and your site is the one
carrying the claims.

**Aggregator or directory.** You list providers and send traffic away without
taking payment. Your exposure is what your listings claim, which is a marketing
question rather than a certification one for the transaction, though the
counterparties who screen on the credential will still ask.

**White label.** Each customer has a domain, and each domain is a separate
certification question. Twenty clinics is potentially twenty applications, and
whether they are yours or theirs is a contract term that most white-label
agreements do not address.

**Enablement.** You supply software, and the clinic runs everything patient
facing. Cleanest position, and the one platforms claim most often and occupy
least often.

## What platforms consistently underestimate

**The intake is yours.** If the assessment logic, the questions and the decline
rules are your product, then the clinical screening a reviewer examines is
something you built. That is a strength if it is documented and a problem if
nobody can explain it, which is the argument
[asynchronous intake](/blog/asynchronous-intake-and-the-clinical-encounter-under-review)
makes for instrumenting it.

**The pharmacy relationship is often yours too.** Where the platform arranges
fulfilment, the dispensing entity, its registration and its state coverage are
part of your model rather than each clinic's.

**The claims are copied.** White-label customers use the templates you supply.
One badly worded product description in a template is that sentence live on
twenty domains, and every one of them is discoverable.

**Your customers inherit your compliance.** A clinic on your platform is buying
your intake, your fulfilment and your copy. If those are sound, you are selling
a genuine advantage. If they are not, you are distributing a defect.

## The contract questions nobody writes down

Settle these before the first customer, because retrofitting them across twenty
signed agreements is a different job.

- Which party holds certification for the customer's domain, and who pays.
- Who owns the claims on the customer's site, and whether template copy may be
  edited.
- What happens when a customer edits it into something non-compliant.
- Who answers a request for information about the shared clinical model.
- What happens to patients if the relationship ends mid-treatment.
- Whether the platform may suspend a customer for a compliance breach, and on
  what notice.

That last one is the clause platforms wish they had. Without it, a single
customer's landing page can put the whole network's reputation with acquirers
and ad platforms in play.

## The domain sprawl a platform creates

Platforms generate domains faster than any other business model in this
industry, and most of them appear without a decision.

A subdomain per customer for their patient portal. A shortlink domain for
messaging. A demo environment that is publicly reachable and indexed. A
marketing site, a documentation site, a status page, and a legacy domain from
the product's first name. Then each customer's own domain on top.

Not all of those need certifying and every one of them needs to be known about,
because an undisclosed reachable property is the cheapest kind of finding to
avoid and one of the more damaging to have found. Pull the list from the DNS
provider rather than from the registrar alone, since a platform's sprawl is
usually in subdomains rather than in registrations.

Then apply the same three buckets everything else in this business uses:
certify, redirect, retire. A demo environment that anybody can reach and that
takes intake is a live telehealth website whatever the internal name for it is.

## The advantage available to platforms

There is a genuinely good version of this. A platform that certifies its own
marketplace domain properly, documents the shared clinical model once, maintains
the pharmacy evidence centrally and supplies customers with a compliant template
and a claims allowlist is selling something valuable, and it is the single
strongest differentiator available in a crowded software category.

It also makes each customer's own application dramatically cheaper, because most
of
[the shared evidence](/blog/certifying-several-domains-without-doing-the-work-five-times)
already exists in a form that can be handed over.

## What to prepare either way

One document describing the shared model: the intake, the screening logic, the
prescriber relationships, the dispensing arrangement, the state coverage, and
which parts a customer can change. One certified domain if you take payment. One
template audited against the claims rules. And a clear internal answer, per
customer, to whose website is whose.

Platforms that cannot answer that last question are usually the ones who find
out during a customer's review, which is the worst moment to be having the
conversation.

## Frequently asked questions

### Does a telehealth platform need its own certification?

It depends on whether patients transact on the platform's domain. If they complete intake and pay on your site under your brand, that is the website in question regardless of who provides the care behind it.

### Who certifies a white-label domain, the platform or the clinic?

Whichever party owns the website, and the answer should be a contract term rather than a discovery made during a review. Twenty white-label customers is potentially twenty separate applications, and somebody has to own each one.

### If my customers use my templates, are their claims my problem?

Commercially, yes. Template copy is replicated across every customer domain, so one badly worded product description becomes that sentence live on every site you power, and each is discoverable independently.

## Disclaimer

LegitScript is a trademark of LegitScript LLC. VeriScripts is an independent application-preparation service. It is not affiliated with, endorsed by, or certified by LegitScript LLC, and claims no sponsorship or partnership with it. We prepare, submit, and manage the application; LegitScript alone decides whether certification is granted. "LegitScript" is used here only to name the certification these applications are for.