Payments — no percentage of GMV

How it works

Two arrangements, one rule.

Which one applies depends on whether you use Corevia's clinical networks. Both end at your bank account; they differ in who carries the merchant relationship to get there.

With the networks: Corevia is merchant of recordWhere you use the physician and pharmacy networks, Corevia collects from the patient, settles the clinical and pharmacy costs directly, and remits the balance to your bank on a defined cycle. One counterparty and one reconciliation, instead of a processor, a physician group and thirty compounding pharmacies each invoicing you separately.

EMR only: keep your own processorLicense the EMR and e-prescribing without those networks and you can connect your own Stripe account over OAuth — the platform uses direct charges, so the connected account is the merchant of record, not Corevia. Your underwriting, your bank, your chargebacks, your statement descriptor. Or run an existing high-risk account through a supported gateway: Authorize.Net, NMI or Braintree. If you would rather not run a merchant account at all, you can use ours.

High-risk underwriting becomes our problemGeneralist processors routinely classify telehealth as restricted and compounded therapies as high-risk. Where Corevia is merchant of record, Corevia carries the underwriting, the reserve and the chargeback exposure for that category — so you are not blocked from launching while you try to secure a high-risk merchant account of your own.

An auditable ledger, not a statement you have to trustWhere Corevia collects, the operations console shows every charge, refund, clinical cost, pharmacy cost and remittance — reconciled against the order and the clinical record rather than a spreadsheet kept somewhere else. You can tie any payout back to the encounters that produced it.

No percentage of GMV, either wayCorevia is paid a flat platform fee whichever arrangement applies — for the platform, not for your volume. Your unit economics improve as you scale instead of being taxed by the vendor that processes the transaction. Being merchant of record changes who the processor answers to; it does not change what you pay us.

Three hard constraints

The rules that shape the payment design.

Each of these is a line the platform will not cross, because crossing it would change what kind of company Corevia is — or what a card statement discloses about your patient.

PCI scope stays light — card data never touches Corevia servers

Checkout uses hosted fields and Elements rendered by your processor. The card number is captured inside their frame and exchanged for a token; Corevia sees the token, never the pan. Proxying a raw card number would drag a healthcare platform into full cardholder-data compliance, and that is a different company with a different audit surface. We decline the scope deliberately.

No PHI on the payment rail

Payment processors are not covered entities and most will not sign a Business Associate Agreement — so nothing that could reveal a condition is sent to them. The descriptor and the metadata carry an amount and an opaque order reference, and nothing else: no diagnosis, no medication name, no condition-revealing program name. Say it plainly — a medication name printed on a card statement is a disclosure, and it is read by whoever opens the envelope.

Telehealth merchant certification follows the merchant of record

Certification — LegitScript being the one most processors ask for — attaches to whoever holds the account. Where Corevia is merchant of record, that is Corevia, and it is our workstream to maintain. Where you keep your own processor, it attaches to your entity, which is the honest consequence of owning the account; we then treat it as an onboarding workstream — telling you what the certifier will ask for, supplying the platform-side evidence about clinical workflow, licensure enforcement and prescribing controls, and sequencing it alongside underwriting so it is not the thing that delays your launch.

Still the platform's job

What the platform still does.

Who holds the merchant account changes very little about how billing behaves. The logic lives with the clinical record either way, because refunds, pauses and prescriptions have to agree with each other.

Subscriptions and recurring programs

Monthly and multi-month programs, prepaid terms, titration-linked plan changes and mid-cycle upgrades, executed on whichever account holds the merchant relationship.

Recurring

Multi-party revenue splits

Brand, practice, pharmacy and platform shares modeled per program and applied per order, so the split is a rule rather than a spreadsheet.

Splits

Refunds and pauses, reconciled to the chart

A pause, a refund or a cancellation moves the clinical program with it — no patient left paying for a stopped therapy, and no therapy running on a canceled plan.

Reconciled

Per-brand pricing

Every brand on the platform carries its own catalog, price points, discounts and promotional rules — isolated from every other tenant.

Multi-brand

Failed payments that don't interrupt care badly

Retries, dunning and grace behavior are configured per program, so a declined card triggers outreach rather than an abrupt clinical stop where continuity matters.

Continuity

Reporting per brand

Revenue, retention, refunds and program-level performance reported per brand and roll-up, reconciled against the clinical record rather than against a payout file alone.

Analytics

Payments that don't tax your growth.