SHORT ANSWER
The same review as any storefront, split across two places. On Medusa the product data lives in the backend and the customer-facing copy lives in a separate storefront app, and a reviewer reads both. The payment provider is enabled per region through a module, but the processor’s restricted-business policy applies to what the site says, not to how it is wired.
This material is general educational information as of the “last reviewed” date. It is not legal advice and may not reflect later developments or facts specific to your business. Links are provided so readers can inspect the primary or official sources.
01 / WHY HEADLESS IS DIFFERENT
The claims live in two systems, and both count
On a monolithic platform the product record and the page a buyer sees are one thing. On Medusa they are not. Medusa’s Product Module stores products with options and variants and organizes them with categories, collections, and tags; a separate storefront application renders that data alongside its own copy, images, and layout.
That split matters for review because intended use is read from the whole presentation. A product record can be neutral while the storefront wraps it in a hero headline, a benefits block, or a blog post that describes effects in people. The reverse also happens: a clean storefront template rendering a product description that was written for a different audience. FDA’s warning letters quote the rendered page, which is the combination of both, not either system alone.
The practical consequence is that a Medusa review has two checklists: what is in the backend (admin data), and what the storefront app adds around it (code, CMS content, and any hardcoded copy).
Free-form metadata fields on products and variants often feed page titles, meta descriptions, and structured data in the storefront. FDA has cited website metatags as evidence of intended use in at least two letters in RUO Clear’s corpus. Treat metadata as public copy.
02 / BACKEND DATA
What to review in the Medusa admin
Work through the product data the way a rendered page will expose it. Each item below is a recommended control, not a rule.
- Product titles and handles: an outcome word or brand name in the title becomes the H1 and the URL
- Subtitles and descriptions: the long description is usually rendered verbatim; short descriptions feed cards and search results
- Variant names and option values: “5mg” and “10mg” are dose language when nothing else on the page frames the product as a reagent
- Categories, collections, and tags: names like “Weight Management” or “Recovery” group products by claimed effect
- Inventory kits and bundles: Medusa supports bundled and multi-part products; a kit that pairs a peptide with bacteriostatic water and syringes is an administration signal FDA has cited in 15 letters in RUO Clear’s corpus
- Metadata: any key that the storefront reads into a title, meta description, or schema
- Images and thumbnails: alt text and the image itself, including injection imagery
03 / STOREFRONT APP
What to review in the rendered storefront
The storefront is where most contradictions hide, because it is written by different people at a different time than the catalog. Check the code and any headless CMS it pulls from, not only the admin.
- Hardcoded copy in components: hero headlines, benefit lists, trust bars, footers
- CMS content: landing pages, blog posts, FAQ entries, and “learn” sections rendered by the storefront
- Template blocks that repeat on every product page: a shared “how to use” or “results” section applies to every product at once
- Search and SEO output: page titles, meta descriptions, Open Graph tags, and JSON-LD generated from product data or metadata
- Checkout and cart: the terms step, any attestation checkbox, and the confirmation email template
- Policy pages: research-use terms, refunds, shipping, and a working contact path, which providers look for during review
04 / PAYMENT PROVIDERS
The module wires the processor; the policy still applies
Medusa handles payment through a Payment Module Provider. In Medusa’s own description, the provider integrates a third-party payment service, a payment session is created for it, and the provider handles authorization. The Stripe Module Provider is installed by default and is enabled per region from the admin; its prerequisites are a Stripe account, a secret API key, and a webhook secret for deployed applications.
None of that changes what Stripe will do with the account. The provider module is plumbing. Stripe’s restricted-businesses policy is a contractual rule applied to the business and the site, and Stripe reviews accounts on its own schedule regardless of which storefront framework created the payment session. A Medusa store with a neutral catalog and a storefront that promises fat loss is, to the processor, a store that promises fat loss.
The same holds for any other provider a merchant registers through the Payment Module. Each has its own published policy, and each applies it to the rendered site.
Registering the Stripe provider in a region makes Stripe available at checkout. It does not mean Stripe has reviewed the business or that the account will stay enabled. Those decisions belong to the provider and can change.
05 / THE RUO CLEAR CONNECTOR
What the planned Medusa connector reads
RUO Clear’s Medusa connector is planned and is not yet available for production installation. As described on the connector page, the plugin would bind a Medusa store to one RUO Clear tenant, expose connection health, and coordinate authorized inventory evidence and scan events.
Its data boundary is narrow by design: catalog, product, collection, policy, and storefront configuration may support enabled scans; payment sessions, card data, and unnecessary customer or order records stay out of scope. The public crawl of the rendered storefront runs alongside the structured sync, because the structured data alone cannot show net impression.
06 / CHECKLIST
Before applying anywhere
A short list to work through in order. Record what was found and what changed; that record is what a provider can review.
- Export the catalog (titles, handles, descriptions, variants, categories, collections, tags, metadata) and read it as copy
- Crawl the rendered storefront and read every product page, landing page, and blog post as a buyer would
- Diff the two: find copy that exists only in the storefront app or CMS
- Remove or rewrite outcome language, brand comparisons, dosing and reconstitution instructions, and administration bundles
- Check generated SEO output and structured data for the same language
- Confirm the checkout terms step and the confirmation email match the product pages
- Read the published policy of every payment provider enabled in any region
QUESTIONS
Related questions
Is a headless store treated differently by processors?
Not by policy. Stripe’s restricted-businesses rules and every other provider’s terms describe businesses and sites, not frameworks. A reviewer reads the rendered pages. The only practical difference is that a headless store has more places for copy to hide.
If the Medusa admin data is clean, is the site clean?
Not necessarily. The storefront application and any CMS it reads from add their own copy, and FDA’s letters quote the rendered page. Review both systems and the output they produce together.
Does RUO Clear read my Medusa payment sessions or orders?
No. The planned connector’s data boundary excludes payment sessions, card data, and unnecessary customer or order records. It reads catalog, collection, policy, and storefront configuration for enabled scan modules, alongside a public crawl of the rendered site.
SOURCES
Sources cited
Each source is listed with its class so government authority, agency guidance, enforcement examples, and private policy are never blended into one rule.
Products with options and variants; organization by categories, collections, and tags; bundled and multi-part products via inventory kits. Read September 3, 2026.
The provider integrates a third-party payment service; a payment session is created and the provider handles authorization. Read September 3, 2026.
Installed by default, enabled per region from the admin; requires a Stripe account, secret API key, and webhook secret for deployed applications. Read September 3, 2026.
The contractual category rules Stripe applies to a business and its site, independent of the storefront framework.
Objective intent shown by labeling, advertising, written statements, and circumstances of distribution, which on a headless store spans both the backend and the storefront.